Uploads Aborting
 

I just installed Phex a couple of hours ago. It seemed to go smoothly, with one exception: Every single upload has a status of "aborted". I've been through the forums looking for an answer, and found nothing so far that really hits the mark.

I'm a veteran Limewire and Bearshare user, and both run just fine, utilizing the same port.

System info:

Win XP Pro w/ SP2
1gb Ram
300+ gb free disk space
Phex ver. 3.2.0.102
Listening on port 6348
Connection is Async Cable with 16Mbps/down and 2Mbps/up

This is a dedicated P2P machine. It is outside the firewall, in a DMZ. Ports are also forwarded in the router.

I am running in Ultrapeer set at 32 peers, 30 leaves. TCPIP.SYS is set at 100 connections. Sharing approx 21,000 files.

Thanks in advance for any help anyone can give!

Cheers

Nick

That's those forged TCP reset packets again. It wouldn't help if you blocked them because they
are also sending them to the uploaders as well.

forged TCP packets
 

I sort of get the concept of what they're doing, but could you elaborate a bit? I'm a little foggy on the process, I suppose. It looks like I'm getting valid upload requests (as far as the originating addresses are concerned. Instead, they are bogus, and the end result is that legitimate uploads are being blocked, as BS (and Phex, now) is being swamped. Does that sound about right? Blocking addresses wouldn't work, because they're hijacking legit addresses, right?

The thing is, I do have a considerable amount of computer resources to throw at the problem, which I would love to do, just to counter what they're doing. A better understanding of the latter might give me some idea of what I could do with the former. I'd be interested to see what firing up Phex on a parallel processor Unix machine might accomplish. If nothing else, it might keep them quite busy keeping up with it. :)

Cheers,

Nick

PS (Why is Limewire evidently impervious to these attacks? It just cooks along, with 5 or 10 users getting through consistently.)

Those are valid uploads, but Cox has a Sandvine router that detects attempts to
download from you and creates two forged TCP packets with the RST flag on and
falsified source addresses copied from you and the other person. You won't be
able to pinpoint this illegal abuse of the TCP protocol because the originating
addresses in both packets at both ends are forged.

This will probably be ruled illegal in the ComCast case because they were caught
doing it to bittorrent users and are persistently lying about it to the press and the
authorities, claiming that they were only "delaying" uploads while it is obvious to
all the independant observers who tested it that they were actually stopping all
uploads completely.

Once that is done, Sandvine will probably have to upgrade all their routers to
disable this illegal method of hacking that interferes with net neutrality. If they
don't, the next thing we'll see is millions of users adding filtering to disable
all reset packets, breaking the normal TCP protocol, which will probably get
the big network companies sweating bullets. Even now, Linux users all over the
world are taking advantage of it's flexibility and disabling reset packets with a
simple command to their firewalls.

Phex vs. Cox
 

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

Ah... that fleeting feeling of victory
 

It took someone over at Cox (or wherever) about 2 hours to figure out their program needed to be rebooted. After which time, the reset attacks resumed.

Point of note: Once this began again, I did a hard reset of the cable modem and router, and forced Cox to reissue my IP address. The attacks continue, which leads me to believe that it is a system-wide process aimed at gnutella traffic, versus one that is targeting specific users at whom they're annoyed (I'm sure I fall into that category, by now).

Looks like it's time to figure out how to block reset packets under XP...

Cheers

Nick

That's quite an impressive test you did.

I'm not sure I understand all specifics, but as far as I see it, you managed to avoid their attack by just telling your router to reject it.

If I understand it correctly, this also means, that the utilized TCP implementation of the program is the target.

Does the TCP management happen at the OS level, or at the program level?

If it is at the program level, it might be possible to add some code which detects excess levels of reset packets in the pipe and just ignores them. Maybe that's what LimeWire already does...

TCP Reset Packets
 

From what I understand, the "device" in the pipeline will take packets and essentially clone them, with the exception of setting the RST control bit in the header. There must be some way of identifying Gnutella packets, possibly by the usual ports most P2P software uses. I don't believe they're simply nailing all the packets at a specific address, since most other traffic is getting through (and going out) just fine.

Also, I don't think that whatever they're using is 100% effective, which is probably why my brute force response gave them a little more work than they could handle.
With Limewire (vs. Bearshare or Phex), if the software can handle sufficient incoming requests then *some* valid ones are getting through, hence Limewire's ability to find the good amid all the crap coming in. Of course, that's just a theory, and isn't really based on anything other than observation, which means it could be completely wrong. I don't know enough about Limewire's internals to hazard a real (intelligent) guess.

So, if your question is "are they aiming this at P2P apps?" and not just all TCP packets, I'd say yes, my testing would seem to indicate that it is targeting P2P. Which also would mean that it is indeed Cox, or some other anti-sharing entity, who's behind the attacks.

I'm going to try and think up some more tests, and I may bring another (not quite so fast) Sparc online to do it with, since there's a little more control with TCP than under WinXP. Idea's would be appreciated.

Cheers

Nick

Finding Gnutella packets is quite easy, because, even though they are inflated, they all begin with the same TCP headers, so they can be spotted quite easily, since all deflated message will begin the same:

Handshaking - Gnutella Specification

What my current question is: Does Phex have enough control over TCP to just the RST bit, if it is sent in excess.

Maybe you could try sending a forged Gnutella Connect packet to yourself, and see if the RST herader gets added.