Oops, I think I might have broken something over at Cox.
I fired up Phex on my Sun Fire Server (w/ 4 Quad Xeon processors on it). Before attempting this endeavor, I did some reading on reset attacks - pretty grim stuff.

I installed Phex, and immediately starting getting the constant aborts. So, I set the firewall in the router to reject all TCP reset packets. The aborts continued for about 5 minutes after that, then stopped.

I read a white paper on the reset attacks, and therein saw some calculations based on how many packets could actually be killed, based on connection speed. You've gotta figure that if Cox was doing it, they pretty much have unlimited bandwidth to play with. Nevertheless, neither that bandwidth nor the device that's doing the tampering has infinite capacity. Unless they're running a mainframe, I've gotta believe my Sun Fire is about as fast as anything they have. So, I set the program to accept as many incoming requests as possible, rejecting the resets, and within minutes, the attack was over.

I just fired up BS on the XP machine, and it's running fine, humming along with 12 uploads at once, and a full queue.

Honestly, I'm not sure what I did, but I felt the need to try *something* in retaliation. Hopefully, I won't have to do it again, as this sort of escapade is not what the Sun Fire is meant to be used for (it does climate modeling, normally).

It has also occured to me that Cox might not have been the culprit. I know of no way to trace those reset packets, since the originating address is legit. I'm not sure that the reset attack would have to live in the route I'm using. Guess I need to do some more reading.

Anyway, there it is. A solution of sorts, I think, but probably not one that's going to work for many of us. I've no idea how long it will work here, for that matter.

Well, I'm off to fix the Sun Fire, before some people start complaining.

Cheers

Nick