> 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. >
DebianGATechIssue.pcap
Description: application/vnd.tcpdump.pcap
