Hello Tom, Could you please check the behaviour with: * window scaling disabled (/proc/sys/net/ipv4/tcp_window_scaling) or * ECN disabled (/proc/sys/net/ipv4/tcp_ecn) ?
On Fri, Jan 04, 2013 at 08:12:38PM -0600, Tom Noonan wrote: > > That leads me to believe that the problem is being caused by a > > firewall near the source subnet. > I don't believe this is correct. A tcptraceroute gets all the way to > your server: > > root@sandbox3-ldap:/home/tom# traceroute -p 80 -6 -T 2610:148:1f10:3::89 > traceroute to 2610:148:1f10:3::89 (2610:148:1f10:3::89), 30 hops max, > 80 byte packets > 1 2001:4801:7817:72::a (2001:4801:7817:72::a) 3.315 ms 3.285 ms > 3.522 ms > 2 core5-aggr1501a-1.ord1.rackspace.net (2001:4801:800:c5:151a:1::) > 3.902 ms 3.882 ms 3.849 ms > 3 2001:4801:800:cb:c5:: (2001:4801:800:cb:c5::) 3.836 ms 3.803 ms > 2001:4801:800:ca:c5:: (2001:4801:800:ca:c5::) 3.764 ms > 4 edge2.ord1.rackspace.net (2001:4801:800:ca:e2::1) 2.811 ms > edge2-coreb-1.ord1.rackspace.net (2001:4801:800:cb:e2::1) 2.820 ms > edge2-corea-1.ord1.rackspace.net (2001:4801:800:ca:e2::1) 2.793 ms > 5 xe-1-0-7.ar1.ord6.us.nlayer.net (2001:590::451f:6ef1) 4.167 ms > 4.137 ms 4.116 ms > 6 ae5-30g.cr1.ord1.us.nlayer.net (2001:590::451f:6ef9) 3.605 ms > 1.607 ms 1.559 ms > 7 xe-0.equinix.chcgil09.us.bb.gin.ntt.net (2001:504:0:4::2914:1) > 2.178 ms 102.406 ms 102.351 ms > 8 ae-0.r21.chcgil09.us.bb.gin.ntt.net (2001:418:0:2000::36) 2.778 > ms 2.736 ms 2.667 ms > 9 ae-4.r21.dllstx09.us.bb.gin.ntt.net (2001:418:0:2000::81) 30.356 > ms 30.271 ms 30.198 ms > 10 ae-4.r03.atlnga05.us.bb.gin.ntt.net (2001:418:0:2000::37e) 62.160 > ms 66.321 ms 53.996 ms > 11 xe-3-1-920-2.r03.atlnga05.us.ce.gin.ntt.net (2001:418:0:5000::123) > 52.954 ms 51.297 ms 48.535 ms > 12 rich-v6-rtr-to-rich-gw-rtr.gatech.edu (2610:148:fe00:d::2) 38.811 > ms 38.625 ms 33.470 ms > 13 rich-gw-rtr-to-rich-v6-rtr.gatech.edu (2610:148:fe00:d::1) 38.973 > ms 35.315 ms 36.806 ms > 14 2610:148:fe00:dd::2 (2610:148:fe00:dd::2) 42.013 ms 40.520 ms > 37.813 ms > 15 2610:148:1f10:3::89 (2610:148:1f10:3::89) 39.446 ms 36.327 ms > 38.891 ms > > > Also note hops 12-15 appear to be gatech.edu servers. > > Looking at a packet capture I see initial handshake SYN ACK packets > received, and nothing else. I send a SYN, get a SYN ACK, send an > ACK and then send a HTTP GET. The GaTech server never seems to get the > ACK, and keeps sending the SYN ACK in reply to the seq. 0 SYN while I > send HTTP GET retransmissions. > > I've attached the packet capture, though I'm not sure if that's the > preferred method with the Debian email-based bugtracker. Please note > the first packet is superfluous and caused by me killing a hung wget > (Note the source port numbers). It does, however, show that my TCP > stack thinks it has initiated and tries to close the connection. > > This appears to be tarpit behavior. The TCPtraceroute leads me to > believe the tarpit is on the GATech side, not the RackSpace side. Do > you agree? > > On Fri, 4 Jan 2013 20:17:01 -0500 > Paul Royal <p...@gtisc.gatech.edu> wrote: > > > On Fri, Jan 4, 2013 at 7:39 PM, Tom Noonan <t...@tjnii.com> wrote: > > > This doesn't surprise me. As my initial bug report stated, it > > > seems to have something to do with the source subnet. I've > > > personally verified it works from a different subnet, and others > > > have verified it fails from the same source subnet. > > > > That leads me to believe that the problem is being caused by a > > firewall near the source subnet. > > > > > Curious. Let me know if there is anything I can do on my end to > > > help. Beyond the traceroutes already attached I'm not sure what > > > other details to provide. > > > > I am unsure of what else can be done. We do not use a firewall and the > > mirror is accessible from every other subnet that has been tested. -- Simon Paillard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
