[ale] An unnecessary outage

[Michael B. Trausch]

On 04/13/2011 01:50 PM, Matt Rutherford wrote:
> Lurker cable person here. First, what's hardware version of the SMC? You

It's a pretty heavily locked down SMC D3G, r1.01.  While I have access
to the Web-based UI, it's pretty useless---just enough to see what it's
doing, and configure some basic firewall-type behavior.  That's pretty
much it.  It has the upstream capability to do things like VPN and flash
updates, but I have access to none of those options.

> might check if there are known-fix options for it. Do you have access to
> the GUI on it via it's local gateway IP? I've worked with some of the
> 'business class' SMC modems that cable companies use and there are some
> weird issues with some versions. That said, I've been on the support end
> of the line plenty of times with residential cable modems where a
> problem on the internal network (typically the routers) will actually
> offline a modem entirely or cause serious problems with the network. So
> there is no 100% guarantee that the modem won't be impacted on the
> DOCSIS/RF side of things by a device in the home. Same goes for anything
> throwing enough static sharing the same power strip, though happens less
> often overall.

Joy.

> Do you know what happened to the Linksys? I'm just curious if this was
> an issue where the Linksys and the modem were fighting for control of
> default gateway route, or something more hardware-level. Most modems
> providing NAT or bridge/routing mode still advertise a local address
> (for residential cable modems typically 192.168.100.1) that you can use
> to reach their GUI and check diagnostics. If the Linksys got reset to
> defaults or conflicting settings, I can see that causing problems.
> Hardware level stuff can be much more random-seeming.

The problem started yesterday at just a little after noon (12:06 was
when my alarms started going off).  We were experiencing a lot of high
winds then, so I'm guessing that we probably experienced a slight power
surge.  The Linksys device probably stopped functioning properly at that
time.  It seems to me that they are sensitive to things like certain
types of power spikes.  This is the first time this one has ever done
that and it's been here for seven months or so now.  (That said, it's
malfunction should have affected only its network segment, seriously.)

The tech unplugged the Ethernet cables one-by-one from the SMC box and
when he unplugged the one that goes upstairs to feed the Linksys
wireless router, the cable modem started working correctly.

The other interesting thing to note is that this happened not just with
one SMC box, but two of them (the second one being brand new).  That is
why I have the feeling that this is some sort of result of a design
flaw.  I cannot recall _ever_ having a switch that suffered complete
failure when one device on it was misbehaving.

> Replacing the SMC with your own equipment it depends on how your
> provider has their IP routing set up. I've mostly seen RIPv2 based
> routing for 'business class' or static IP service from cable ISPs. This
> requires your modem to have the static IP configurations in place and
> the (non customer visble/secret) RIP key in place to make these IP's
> route to the modem at the premises. This means that cloning the MAC
> address alone of the device won't set up the modem to route your /28.

Sigh.

Never did I think that AT&T would have a point in its favor, but it'd
seem it does.  The way _they_ do static-address subnetworks is to update
a routing table on their network whenever a PPPoE session is started for
a customer that has it.  I confirmed that when I swapped out my client's
AT&T provided DSL modem with one from Fry's (which I did because AT&T
swapped the modem their modem three times to no avail, and their modems
would stop working every 24 hours, like clockwork).

That said, if the device is using something like RIP or similar, that
means that the device has to have the public key of the target server
(if using encryption) or its own private key (if just signing); there is
no way around that requirement that I can think of.  Which means that
it's likely possible to do, though it would be a veritable pain in the ass.

> Additionally, most residential class/off the shelf modem/router combo's
> won't actually accept a static IP configuration due to the firmware
> imaging. I'll cut short a lot of detailed info but in a nutshell the
> firmware on modems (customer owned or corporate provided) is provided by
> the cable company and if a non-authorized image is detected the modem
> won't be authorized for service. For standard cable modems, the services
> are based on MAC address, but the checks for an authenticated/signed
> firmware image will prevent services thanks to happy cable modem hackers
> - especially in Docsis3. This is typically in the small print of the
> contract/user agreement/policies - even if it's your equipment, the
> cable company can force firmware updates and deny service to
> non-authorized images.

That's... interesting.  I will need to re-read my contract.  I do not
recall such a provision in it.  Though, it is possible that I could have
overlooked it.

> I do not think you will see the DOCSIS side broadcasts from wireshark
> since these go out from a separate interface which performs DOCSIS
> encapsulation between the modem's RF out chip and the CMTS upstream,
> where the traffic is re-encapsulated to head out on the backbone.

Well, right.  I know this much: wireshark knows the DOCSIS protocols.
I'd presume that means it's been used for that purpose before, unless
this was just implemented either to a spec or in order to monitor
emulated hardware or something.

I was hoping that there would be some way to get on the other side of
that interface.  Something like connecting a "tap" on the coax line and
logging/monitoring the traffic going across the physical link.

> Lastly, the mixed luck news: I've not seen a single cable operator that
> will route a static IP block to a modem they don't own because of the
> secret key for whatever routing scheme they use. Making that available
> to end-user controlled modems would be a major security flaw. However
> many operators do have more than one type or provider of the modems they
> use in the market. You may be able to call the cable operator and
> request a modem from a different manufacturer, but that depends heavily
> on the market you're in and what hardware availability is like.

Comcast only seems to have the SMC boxes.

Don't get me wrong here: they're probably great for most people.  You
plug 'em in, and they work.  They handle multiple IP networks on the
bridged segment just fine, pass protocol 41, and (for the most part)
work as they should.

But it comes at the cost of using one of your static IP addresses (I
have a /28; I can't use the first address because it's the network
address, I can't use the last address because it's the broadcast
address, and I can't use the second to the last address because that's
the one that the gateway takes).  AT&T does the same thing with their
own DSL modems, but you get the gateway IP address back if you don't use
their equipment, since it's tied to the PPPoE session; of course that
means that when you have a /29 with them, you actually get an extra
address because the PPPoE session has a dynamic IP which serves as the
gateway address for the /29 that you have.

> With regard to internal cable modems, their unavailability comes from a
> couple directions: Control of hardware, control of software. There's
> some interesting books out there about cable modem hacking and the
> history of cable modems, but from my understanding it boils down to the
> controllers of the DOCSIS spec (CableLabs) having a vested interest in
> keeping end-users from fiddling with and bypassing security and
> authentication measures, including the digital certificates internal to
> the modems. I'm highly doubtful a computer-internal cable modem would
> ever get licensed for DOCSIS or pass DOCSIS certification.

That's sad.  There were DOCSIS 1.0, 1.1, and 2.0 internal cable modems
that I was able to find, but of course those would do me no good.

> In summary, your best bet is to contact your cable provider and ask
> about alternate modem availability to see if another modem doesn't have
> the same kind of problem. It's possible they could also re-configure the
> SMC to a different setup to prevent possible failure of this type in the
> future if there was a known-issue from a tech bulletin/etc.

They do nothing with the firmware, other than "program" it for your
static IP allocation when it is deployed.

Sigh.

The more I have minor little troubles here and there, the more I wish I
had the money to just get a pair of dedicated lines that I could do BGP
announcements on and have an SLA with a high level of service.  For the
price, Comcast is not bad.  But the whole notion that the cable company
cannot proactively monitor its equipment, will not let you provide your
own equipment, and provides only a 24-turnaround time guarantee to
engage you on an issue that you report is getting to be very obnoxious
to me.

Perhaps I need to spend a week on dialup.  That ought to refresh my
perspective and get me to quit my bitching.  Mostly, anyway.

	--- Mike