[nycbug-talk] Proof that road runner sucks?

[Tim A.]

Andy Kosela wrote:
> On Dec 23, 2007 3:00 PM, michael <lists at genoverly.net> wrote:
>   
>> On Sat, 22 Dec 2007 18:19:26 -0500
>> Max Gribov <max at neuropunks.org> wrote:
>>
>>     
>>> So my cable connection is really slow. Calling Road Runner is
>>> pointless, because ive already turned off and on my cable modem.
>>> So i decided to tcpdump on the wire directly from cable modem to my
>>> laptop. Heres some interesting tcpdump..
>>>
>>>       
>> [snip]
>>     
>>> we can see arp requests by rr.com router for someone called
>>> cpe-68-174-122-163.nyc.res.rr.com. OK i can understand that, even if
>>> it makes those requests several times a second making my connection
>>> crap. What i dont understand is how mindspring.com got there.
>>> Obviously, im lacking knowledge of cable networks to comprehend
>>> something this crazy. And more to the point of why rr sucks:
>>>
>>>       
>> [snip]
>>     
>>> look at the times of those arps. Now consider the fact that their
>>> network is doing this all the time, at least today - dozens of arp
>>> requests per second.
>>>
>>> I guess besides complaining about paying for crappy service, can
>>> anyone shed light on why would i see so much arp traffic, and why
>>> would there be mindspring arp traffic?..
>>>
>>> Just venting, really.. happy holidays!
>>>       
>> I noticed the same thing here, when I first got my hookup.  There was
>> a lot of mindspring and earthlink arp traffic.  I just did a quick dump
>> this morning (I dumped with -n to prevent dns traffic) and found around
>> 1000 arp requests in 60 seconds.  A little grep, awk, and sort shows
>> that it is concentrated to only a few sources.
>>
>> I also found (well, google found) that we are not the first ones to
>> notice and it is not specific to our geography.
>>     
>
> Using cable modem means you share a network with all other
> subscribers. In concept it's very similar to LAN network - that's why
> you see all those ARP's.
> Cable modems are transmitting Ethernet broadcast packets to every
> subscriber on the neighborhood - this is definetly a big security
> risk. In LAN's
> the way to prevent those type of broadcast flooding is to employ
> VLAN's logically separating traffic.
>
> The ARP problem will be solved by the next-generation cable modems
> that implement the DOCSIS 1.1 protocol. Instead of broadcasting ARP
> packets over the entire cable segment, DOCSIS 1.1 makes sure that each
> customer will only see the ARP messages intended for his or her
> machine. As an added protection, DOCSIS 1.1 is also capable of
> encrypting all information sent over the cable itself, with a separate
> encryption key for each customer. This security measure prevents an
> attacker from splicing their own cable modem into the backbone, the
> way that some people used to hook up unauthorized cable decoders to
> get free cable TV service.

The CM (Cable Modem) does alot more interesting communications that you 
might not be aware of than this example.

The broadcast traffic is completely normal, even in 1.1. And that is not 
what's effecting the speed issues.
Actually, they're (Time Warner, and everyone else) already up to 1.1, 
and implementing 2.0 in some areas.
The security features are optional and administratively burdensome. So, 
there's still alot of 1.1 deployment that doesn't turn it on.

Max's problem is probably related to Cable Modem or line issues.
You can probably pull diagnostics up on 192.168.100.1 though its not 
going to say much of anything useful to you.
Time Warner had serious issues over the past 2 weeks throughout the 
North East, and specifically in NYC.
If all that happened is it "slowed down" for you, consider yourself lucky.
Mine and many others were out for a week. (Thankfully, I have Optimum at 
the other house, so spent the time there.)
Locally, the most you can do is check the RF power signal and noise 
levels and be certain your layer 1 gear & layout is ok (cable, 
connectors, taps / splitters / amplifiers).

I've always found my Cable Modem fascinating. Mainly, because it's 
shrouded in so much mystery.
The DOCSIS specification itself stipulates that IP and ethernet bridging 
operate transparently to CM/CMTS host communications, and that you and I 
(as the users) are not to have access to the Control or Management 
interfaces. You might get read access through the ethernet interface, 
but you won't get write access.
Read/Write access is only available via the RF and on-board test interfaces.
You may find an on-board TTL interface that with a TTL-to-Serial adapter 
will give CLI access to the (probably) vxworks OS.
There should also be a JTAG port for directly accessing the boards 
components.

All very appealing to the rebel in me. But there's good reason for these 
end user restrictions.
While it's nice to get in there and play around for shits & giggles. I 
wouldn't want every twit out there wrecking havoc on my Cable segment.
While uncapping is not possible in most providers networks anymore 
(Traffic Shaping, duh!), there's still a good bit of trouble you can 
cause if you wanted to.

One interesting project I've not gotten around to yet (still looking for 
the part: DOCSIS PCI card with linux / bsd drivers) is building an NSM 
box with a RF / DOCSIS interface tapped into the coax before the CM.
Then, not only could you monitor the IP and bridged ethernet traffic 
that reaches the eth port, but also the control and management CM/CMTS 
host traffic that's only visible via the RF port.

CM & CMTS:
http://en.wikipedia.org/wiki/Cable_modem
http://en.wikipedia.org/wiki/CMTS

Specifications:
http://www.cablemodem.com/
http://www.cablemodem.com/specifications/specifications11.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20080102/c5355f69/attachment.html>