NNSquad - Network Neutrality Squad
NNSquad Home Page
[ NNSquad ] Re: How do I detect connection disruption by my IAP?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <3ECD7F7DDE95BA4FA598E8DDE71F1A5104F40875@nwpsrv08.edj.ad.edw ardjones.com>, Holtz,Robert <Robert.Holtz@edwardjones.com> writes >You would want to zero in on TCP SYN packets immediately followed by a >TCP RST packet, i.e., the handshake would never complete. I think it's unlikely that the RST would be in response to the SYN, and traces such as the one at http://torrentfreak.com/images/comcast-rst1.txt show that it's occurring rather later on in the connection. Several people report seeing multiple RSTs, this may well be because the mechanism is out of band, and it's necessary to create RSTs with correctly matching ACK values -- rather like the system used in China which we described in our 2006 paper http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf One of the things we found was that it was necessary to be extremely careful in the way that we ran the tests because the Chinese system also proactively blocked all future connections to the same destination for many minutes. Also, because of the out-of-band nature of the system packets that were being "reset" also reached the far end and were replied to -- this led to complex interactions that were not always the same from one test to the next. Logging the packets at both ends of the connection is to be recommended for a full understanding! Doubtless many people are looking carefully at the Comcast system to better characterise what it does... Looking at the paper you will see that we found, in the Chinese case, that connections could continue if the forged RSTs were ignored either en masse (which does less harm than you'd naively expect) or if you ignored packets with the "wrong" TTL. However, evading Comcast's particular way of interfering with traffic probably isn't, as I understand it, really the point of this list :( - -- Richard Clayton <richard.clayton @ cl.cam.ac.uk> Computer Laboratory, University of Cambridge, CB3 0FD -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBRzOeVJoAxkTY1oPiEQJ/YQCgy9Gzt60rSkEsT27rsz4SFzVc22UAn0I5 lFyP16VY7cBwCXa1y0xdi9Yg =Yygx -----END PGP SIGNATURE-----