DSL signal exploration

Layer 1

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.


Layer 8

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.


Update 071212: fixing the modem
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.


_H* 071213