Thursday, November 08, 2007

Connection resets

At home I've been noticing some persistent connections have been getting resets. A couple of times now I'll be VPNed into work here, and the connection will drop. Other times I've noticed telnet connections to weird ports will get reset sporadically. What's going on?

At home I'm on that network that's gotten some grief about discriminating against BitTorrent users, which I won't name here but you probably know.

Calling in to their Customer Support was pointless as they wanted me to go through fault isolation methods to see where the problems was. My router, their cable-modem, or what? Right, then.

As I no longer have a working 10Mb hub, I can't just drop a laptop in the unprotected segment between the cable-modem and my router and do some sniffing. So I have to get creative. I remembered yesterday that the new desktop gaming system has two ethernet ports on the back. Ahah. A bit of googling brought me to the 'brctl' command in Linux for creating ethernet bridges.

This is exactly what I wanted. Turn the (w-a-y more powerful than this function needs) gaming machine into a simple ethernet bridge, just so I can sniff traffic. I downloaded the latest Knoppix DVD ISO in the hopes that it'd have ethernet drivers for my motherboard. You see, this is a gaming PC that I built for Windows gaming. I did not build it for anything resembling Linux compatibility, so I had real fears that the LAN ports wouldn't be supported. Happily, Knoppix had a module for my ethernet ports and away we go.

ifconfig eth1 0.0.0.0
ifconfig eth2 0.0.0.0
brctl addbr whitehat
brctl addif eth1
brctl addif eth2
ifconfig whitehat up
ifconfig eth1 up
ifconfig eth2 up


In my case, eth0 is the Firewire "lan" port that seems to be on every new machine these days. Once the bridge is up, I can run Wireshark on it with a ring-buffer. Once I see a spurious connection reset, I can stop the sniff and see what exactly happened to the connection. I didn't get any resets last night when I was monitoring, but I may tonight. We'll see where things are going. Did see some RSTs come in, but it wasn't clear if that was normal or not, as it was almost always on HTTP traffic. This machine has 2GB of RAM in it, so the Knoppix RAMDisk is quite large. I don't have to worry about having my ring-buffers starved for space and having the reset fall off the back of the buffer.

If I can prove that the RSTs are coming from the ISP end of the connection and not my router I can go to customer service and tell them so. They'll try and tell me that since the RSTs are coming from the internet IP that the server there must be issuing it. Then I'll tell them that I have multiple internet IPs showing the exact same behavior, and all this started around the same time, and really, I find the possibility that all three (or so) servers got updated to exactly the same buggy TCP stack at the same time to be much less likely than this particular ISP's traffic shaper catching my traffic as collateral damage.

They'll just shrug and say, "oh well," and that'll be that. It won't get fixed. But my call will be logged! My own minuscule vote will be in their tracking system by golly. Maybe it'll be the straw that causes them to tweak their shaper to be less aggressive.

Labels:


Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?