I arrived at the Parental Homestead and found the Verizon DSL self-install kit waiting. Since I'd never really dealt with the newer type of DSL that runs over top of an existing phone line, I decided to investigate a bit further rather than just plug it all up and be done with it. After popping the lid off the wall-phone plate adapter containing a line filter and seeing the circuitry nicely exposed, I realized I had a good opportunity to do a little signals analysis.
The filter circuit board itself. Pretty simple, really, containing a couple of choke transformers and caps. [See its linked bigger picture.] There is a filter circuit per line pair, total two, and the circuit is roughly thus, with cap values given in "multiplier" format as marked:
It's pretty much the opposite of a common-mode choke -- the coil winding polarities are opposed, because in this case we want to squash passage of the *differential* signal above a certain bandwidth but let the DC and low-frequency voice components on top of that through to the phone. 2Wire, by the way, is apparently one of the major players in DSL hardware and standards.
The test setup -- just a simple breakout of the phone line that I could get to with scope probes, on either side of the filter module. The waveforms are each side of the phone line with respect to AC ground at the scope's power plug, thus the heavy 60 Hz hum. That's okay, we just want to see some relative signals. Oh, that little brown thing in the background is indeed a chocolate ... mouse.
Baseline voltage on the two wires of the on-hook phone line, no DSL yet. Not a lot of high-frequency noise visible.
Off-hook, and holding down the "7" key to send a touch-tone pair. The other trace flew off the screen due to voltage drop -- that's okay, we're just looking for an audio amplitude ballpark.
Now, from here on the bottom trace is the unfiltered line and the top trace is post-filter.
Back on-hook, and the DSL modem just got plugged in and is beginning to train up. We see a little bit of high-frequency stuff on the unfiltered side. Evidently when the modem sees the pair voltage, it begins its dance by sending a couple of marker tones for the DSLAM to detect.
Later stages in train-up, and at *much* higher amplitude. Compare this to the touch-tone, which would be loud if someone dialed it into your ear -- this is even louder, in theory, but somewhat attenuated by the hardware of my old Trimline handset based butt-set so it's not painful to listen to. We can see a certain periodicity in that signal; this is a brief burst of sync which sounds like a high-pitched tone in the monitor. Interestingly, we also see a little more of it in the top trace -- perhaps the frequency is close to the filter knee?
Finally the signal goes to pseudorandom modulation, and we're up and running. Here is a short .WAV file of the last sections of negotiation, captured by holding the butt-set monitor up to the camera mic while recording a picture- with-memo. Primitive, but it gives the idea. The post-filter side is very quiet by comparison, so obviously it's doing its job. Connecting a phone across the unfiltered side produces some pretty serious hash, and here we can easily see why the filters must get installed in-line with every other set in the house. So now I understand how the copper pair is dual-purposed for DSL and POTS at the same time, and they've made it all pretty easy with these filters even if running around filtering all the OTHER outlets is sort of klunky. I'd rather do it on a house-wide basis with one filter and a separate line to the DSL box, but the wiring here was absolutely not conducive to doing that. The filters aren't 100% perfect -- I can hear a little bit of hash on a quiet line post-filter, but not enough to be annoying. These days, people are so used to much lower quality than this on their cellphones that they probably wouldn't think twice about a little bit of hiss. When I went to install the wall-phone adapter I found that the screw keyholes didn't match the wall box spacing, so I had to drill extra holes and kludge it together with washers and longer screws. Duh. So I would have had to take the thing apart regardless.
While fooling around at the physical layer was entertaining, what went on at the political level was something of a nightmare. It took, no shit, TWO HOURS on hold at Verizon's business-office number to finally get through to someone, check availability and distance from the CO, and place the original order -- admittedly, not too long after Thanksgiving weekend so things were busier, but still, that's ridiculous. Hire some fucking *staff*, already. Other calls to get various questions answered were the usual offshore swamp-of-cluelessness, but I learned a magic word: if you call Verizon's internet support and land in India or the Phillipines, you can ask for an "american agent" and they'll send you back to someone you can actually understand. There is also a "premium support" department which is a subscription for-pay add-on service, having mostly to do with helping people fix their computers for issues that may be outside Verizon's immediate responsibility, but I had an interesting discussion with one of their supervisors about Actiontec without having to sign up. As shipped, the modem comes with a "walled garden" filtering setup that tries to mostly constrain traffic to Verizon's signup servers and the like. The Actiontec GT740WG is built on a Texas Instruments AR7 processor and running a micro-Linux variant called Busybox. [@stake's security mini-CD boot kits were based on the same thing.] On top of that they're running the web-based management interface, and the routing/nat/firewalling via the Linux kernel and iptables and maybe a proxy daemon or two. The really ironic thing is that you can *telnet* to the box [tcp 23 or 1111] and log into the admin account and get a root mini-shell, and then start poking around. From there, even before our official service turn-up date, it was easy enough to drop in an iptables rule to disable the walled garden and horse around on the net normally -- but there doesn't seem to be any way to save any changed configuration to NVRAM so it survives a reboot. Apparently the service here is DHCP-based instead of PPPoA, and doesn't need a username/password pair for LCP. Much more info is here, although it discusses the similar but not quite identical GT701. The Actiontec people refuse to supply any documentation on this or let me talk to their development staff, blowing me off with "we don't support telnet" -- a lameass excuse, especially when there's no knob to turn it OFF if not needed. Being able to make my own config changes through a simple command-line interface would have really rocked, because of course the web GUI needs all the nonstandard scripting bells-n-whistles turned on in the usual encouraging- risky-behavior complacency that plagues the industry today. What, I asked, if I'm not happy with your default iptables rulesets and want to write my own? SOL, seems to be the answer, which for a box that we BOUGHT and now OWN is completely unacceptable. This particular variant is Verizon-branded and has a little custom configury for their infrastructure, but one could just as easily buy a more generic product from Actiontec and be up against the same stone wall with them. I suppose, in a pinch, I could have cronjob on Mom's laptop just nc a login and a little batch of commands down the router's throat every so often... Next step was to finalize the self-install and get the service up for real, involving some go-rounds with verizon's web site and downloading some little application to drive the process that, from what I could tell, is a bunch of applescript which simply brings up little browser windows to shovel various data back into the website. This stuff is a steaming pile of crap, and is evidently the product of an outfit called Supportsoft that Verizon outsources all their "triple play activation" to. Guess what, it's primarily staffed by Indians -- call 877-493-2778 and wander through their voicejail directory. They're probably brilliant coders, but make far too many assumptions about what people might be running or the security stance that a few of them strive for. It's very clear they have no understanding of what "simplicity" really means. They're probably also a little weaker on the Mac side of things. The app got about halfway through whatever it was doing and died, leaving the modem unconfigured and an email and web account half set up. Another hour on the phone with support yielded the final bit of magic via manual intervention: apparently you just go to http://192.168.1.1/verizon/redirect and that causes the modem to fix itself and from then on, have a "real" ruleset without the walled garden. I could have saved an assload of time if I'd just known that going in.
Not only is the telnet interface undocumented, it's the ONLY way to fix some relatively serious issues in the modem's setup even though it can't be saved in nonvolatile RAM. Turns out that those verizon numbnuts deliberately set things up to leave tcp port 4567 open on the FRONT side of the modem, which in the ipchains ruleset inside it does a direct DNAT to 192.168.1.1:80 -- the main management interface. It works from anywhere, not just from special "firmware download" maintenance networks within Verizon which is the claimed purpose. This is with "allow remote management" turned OFF from the web GUI, of course; it's their little dirty seekrit. I can't BELIEVE that Verizon handed Actiontec a spec that included that and bullied them into writing it in -- the people I talked to at Actiontec *know* it's a bad idea in general even though Verizon claims it's a "secure interface". Bullcrap. It goes right to the same management port I use from inside, and nobody ever said that "thttpd" was a bug-free piece of code especially when you add in CGI. Other minor irritations are the frequent spanning-tree broadcast packets from the "br0" bridge interface when the modem comes up, and the fact that all DNS requests are run through some kind of on-board proxy that keeps an in-memory log of names that inside machines have looked up. That slows things down and violates privacy. With four and a half strikes against it and no palliative help coming from either Verizon or Actiontec, domestic or foreign, here's the fix: this little cronjob runs every hour from Mom's laptop if it's up and not sleeping: #! /bin/sh ## fix the lame stuff in the AP that can't be NV saved CS='admin -censored- brctl stp br0 off kill -9 `cat /var/run/stunnel2.pid` iptables -t nat -D PREROUTING -i nas0 -p tcp --dport 4567 -j DNAT --to-destination 192.168.1.1:80 iptables -D INPUT -i nas0 -p tcp --dport 80 -j ACCEPT iptables -D INPUT -p icmp -j ACCEPT iptables -D INPUT -i br0 -p udp --dport 53 -j QUEUE iptables -D OUTPUT -o br0 -p udp --sport 53 -j QUEUE iptables -D FORWARD -i nas0 -p udp --sport 53 -j QUEUE iptables -D FORWARD -o nas0 -p udp --dport 53 -j QUEUE rm /var/tmp/log_web_activity ; ln -s /dev/null /var/tmp/log_web_activity exit ' date ## 1111 may get wedged every so often, use 23 if needed .. echo "$CS" | x/nc -v -n -i 1 -w 2 192.168.1.1 1111 exit 0 In other words, fuck Verizon and the backdoors they rode in on. This uses iptables' -D "delete" command to specify exact rules, since they may not necessarily always be in a consistent place in the table. If a rule doesn't exist, it's a harmless error and nothing changes. Since this runs frequently and keeps trying to delete rules, trying to use rule numbers wouldn't work. The DNAT for 4567 is removed along with the idiotic "any --> tcp 80" from the *OUTSIDE* via nas0, and UDP 53 is no longer handled specially and sent to userland proxies but rather NATted straight out like it should be in the first place. The attempted domain-lookup logfile in the volatile /var/tmp is relinked to /dev/null for good measure. Why random "stunnel" processes keep starting up I can't imagine, but it appears to be part of the TR-069 spec for remote maintenance stuff [that, I hope, isn't going to work anymore]. All this really required was being able to compile the correct "nc" on the mac, since the "rework" of the one released with Leopard appears to have been severely buggered.