Phant0m`` Posted June 12, 2007 Report Share Posted June 12, 2007 ACK-FIN-RST is an illegal TCP flag combination, using uTorrent I frequently see these incoming TCP packets. It is just too frequent to be human intervention, unless there are many dummy clients spoofing uTorrent application versions? Link to comment Share on other sites More sharing options...
DreadWingKnight Posted June 12, 2007 Report Share Posted June 12, 2007 Can you identify the clients of the peers sending these packets 100% authoratatively as uTorrent? Link to comment Share on other sites More sharing options...
Phant0m`` Posted June 12, 2007 Author Report Share Posted June 12, 2007 With the IP information and uTorrent Peers area, locating the offending IPs shows clients used with versions, while there is different clients shown using this illegal TCP flag combination, uTorrent versions 6x and 7x also shown. Link to comment Share on other sites More sharing options...
Firon Posted June 12, 2007 Report Share Posted June 12, 2007 What are you using that's complaining about this? Link to comment Share on other sites More sharing options...
Phant0m`` Posted June 13, 2007 Author Report Share Posted June 13, 2007 A simple packet-filter, any packet-filter will work that allows controls over the TCP flags, then make an incoming rule to block TCP packets containing this illegal flag combination... Link to comment Share on other sites More sharing options...
DreadWingKnight Posted June 13, 2007 Report Share Posted June 13, 2007 And according to what TCP protocol documentation is that flag combination illegal? Link to comment Share on other sites More sharing options...
Phant0m`` Posted June 13, 2007 Author Report Share Posted June 13, 2007 FIN gracefully end a TCP connection, RST immediately end a TCP connection, do I have to say more? Link to comment Share on other sites More sharing options...
Greg Hazel Posted June 15, 2007 Report Share Posted June 15, 2007 Obviously uTorrent doesn't do anything with TCP that Windows doesn't do.So, this could be an external injection by an ISP-level bandwidth control solution. You should set up a firewall to filter them and see if the connection continues to function after that packet arrives. Link to comment Share on other sites More sharing options...
Phant0m`` Posted June 15, 2007 Author Report Share Posted June 15, 2007 At times I'm hardly using much bandwidth, and I continue to receive these.My ISP doesn't throttles bit torrent traffic, but I use anyway the uTorrent feature 'Protocol Encryption' - Enabled set.These packets are from random IP sources, they all from out-side of my ISP, and blocking these packets doesn't obviously actually kill the download progress of the file but just very odd and annoying...Another interesting experience I encounter when using uTorrent, and can be quite frequent also, Inbound SYN_RECV packets, SYN/ACK the second step in a three-way TCP handshake without the first step being performed. I'm not certain if allowing these packets in, if TCP/IP stack will drop them or an connection would be made from just the two-way TCP handshake.. A firewall with SPI (stateful packet inspection) feature activated will complain of course about this SYN/ACK packets without the first step being performed.As you an developer here, I'm sure you know if there's something special or not with the TCP use. So I guess this likely means many frequent dummy bots which spoofing different clients and sending malicious and unsolicited TCP packets... Ultimately leads to nothing can be done about this, dang! ;P Link to comment Share on other sites More sharing options...
Switeck Posted June 15, 2007 Report Share Posted June 15, 2007 These problems may be due to other BitTorrent clients as well as hostile ISPs...and even hostile internet traffic carrier ISPs using man-in-the-middle tactics. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 19, 2007 Report Share Posted June 19, 2007 @Phantom: Can you provide a little bit more info on the offending IP's? (location, provider, etc).Also, are ISP's even allowed to change TCP-flags or inject TCP-packets? Link to comment Share on other sites More sharing options...
CodeRed Posted June 20, 2007 Report Share Posted June 20, 2007 I'm pretty sure it's caused by setting linger to 0 on a TCP connection and doing an orderly shutdown; on FIN-ACK Windows adds RST to disable TIME_WAIT. It's a little peculiar, but hardly a big deal since any TCP implementation that's even half modern will ignore all other flags if RST is set. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 20, 2007 Report Share Posted June 20, 2007 The problem is that a strict firewall may simply throw away the packet if it is not a legal combination, and thus a TCP stack will never see the FIN-ACK-RST, and the program using the connection will not know the connection had been closed.Makes me wonder if MS actually has a company policy to violate every RFC at least once. Link to comment Share on other sites More sharing options...
funchords Posted June 22, 2007 Report Share Posted June 22, 2007 This could be P2P interference.Comcast (for one example) injects/sets TCP "RST" flag in order to "manage" P2P traffic at its boundaries. The user will notice that it takes a long time to become successfully connected to the number of peers the user set in Options. For example, if there are hundreds of connectable peers in a swarm, and the user has set Options to connect to 50 peers per torrent, a typical user should be connected with at least 25 peers well within the first minute. When the ISP is "managing" P2P, that ISP's customer will likely notice that far less than 25 peers has been connected after that first minute has passed. Typically, TCP spoofing and monitoring an encrypted connection is difficult. However, this man-in-the-middle attack (or "management") succeeds on TCP/IP and RC-4 encryption because the ISP's equipment is actually inline. The TCP sequence numbers and the D-H exchange to make the RC-4 key are, therefore, monitored and used by the ISP. Ellecoya, Sandvine, and Cisco -- perhaps others -- sell equipment with this capability. To determine whether or not this is ISP interference, the user should try using a VPN that moves their interent connection to a point outside of their ISP's network. The RSTs will be greatly reduced. However, because some of the user's peers use ISPs that inject the RST flag (and due to the other more legitimate causes), a small amount will always be preset.Using my ISP (Comcast), most of my P2P connections are interrupted due to RST. Comcast's ability to interfere with encrypted connections seems to be significantly reduced, but not eliminated. I speculate that some of their equipment might be older or not have the RC4 inspection feature completely rolled-out or enabled. When I am using the PPTP VPN, the percentage of RST disconnections falls to nearly zero. The good news, such as it is, is that Comcast injects the RST after "HAVE" and "NOOP" protocol messages. A stream of PIECE DATA (payload) is not interrupted. My assumption is that the ISP will do this in order to reduce loads (and costs) at its gateways. By interrupting a percentage of connections that cross the gateway, P2P clients will seek another peer. If that new peer is "in-network," uses a less congested route out of the network, or happens to roll the lucky random number that always allows some percentage of P2P traffic to exit the network, then the new peer connection will be allowed to continue.My testing shows Comcast using this for BitTorrent, ED2K, and Gnutella. A DC++ user who saw my test results has told me that they are managing that protocol as well. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 22, 2007 Report Share Posted June 22, 2007 Do you happen to know how they send the RST's? E.g. do they send them both ways or just one way? An interesting experiment would be to drop all RST's on a p2p connection.Still puzzled that ISP's are even allowed to do this. Traffic shaping is one thing. Injecting or tampering with packets is something else. Link to comment Share on other sites More sharing options...
Switeck Posted June 22, 2007 Report Share Posted June 22, 2007 Yet another Comcast cable user here:My line will spontaneously die from time-to-time, and I don't even have to be running µTorrent for that to happen...but µTorrent is USUALLY running when it dies. Everything times out, although ironically TeamSpeak (which I think uses multicast packets) seems to die last -- first on the upload side, then on the download side...so I can hear others for a few seconds longer than I can reply back.I never can seem to hold onto MOST ips in µTorrent longer than 5-10 minutes. This is incredibly bad because most people are firewalled in BitTorrent and other file-sharing programs. Quite likely, the reason this occurs is due to Comcast spoofing TCP reply packets to kill the ip-to-ip connection. ...or the ISP on the other end is doing this. ...or the BIG ISP in the middle (AT&T backbones) that is doing this! :mad: Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 22, 2007 Report Share Posted June 22, 2007 @Switeck: Have you ever checked your external IP after a spontaneously die? I've noticed that some US ISP's change IP's of customers several times a day (!). Also, you might want to capture some packet-stream with Wireshark to see what they are doing exactly. Theoretically speaking, spoofed TCP-packets should be recognizable for the most part, though I doubt someone will build a TCP-stack that is resilient to this. But if they use low-tech spoofing, you might be able to catch them with a *nix-firewall. Link to comment Share on other sites More sharing options...
Switeck Posted June 23, 2007 Report Share Posted June 23, 2007 With my router, my internet ip seems to "never" change...it's changed all of 2 or 3 times in about 5 years. Link to comment Share on other sites More sharing options...
jonaf Posted June 23, 2007 Report Share Posted June 23, 2007 funchords, I experience the exact same thing (Comcast as well).(OT) Are there any other ISPs that you know of that are doing this? I really can't tolerate it and am ISP-searching, but the bad thing is if you want cable, you have to go Comcast, and if you want DSL, you have to go AT&T/SBC....there's such a monopoly. Link to comment Share on other sites More sharing options...
funchords Posted June 24, 2007 Report Share Posted June 24, 2007 Do you happen to know how they send the RST's?I strongly suspect that it is both ways. When I use the VPN, I get the RSTs from Comcast users. When I tried filtering RSTs using ipfilter (in linux), the TCP link stopped dropping but the data stopped flowing and the connections ended in timeouts, instead. That makes sense, because when a RST is given, FIN is not sent in either direction.Still puzzled that ISP's are even allowed to do this. Traffic shaping is one thing. Injecting or tampering with packets is something else.They're allowed because there is nobody to stop them. It's their network. And, so far, their gamble is paying off, because the customers are generally not leaving. Even with their interference, I can maintain the 32 KB/s that I have set as an upload limit. It takes a longer while to get there, though. The interference is much more noticable on unencrypted ED2K and Gnutella, and on unencrypted BitTorrent when you're a seeder.Are there any other ISPs that you know of that are doing this?I really haven't looked very hard. Rogers.ca is probably the most overt in their traffic shaping. My advice is to check out the ISP on DSLReports.com. Verizon put FIOS all over my neighborhood - but skipped my street because winter came early last year. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted September 5, 2007 Report Share Posted September 5, 2007 Some more info: http://it.slashdot.org/article.pl?sid=07/09/04/2014236&from=rss Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.