Re: preliminary conclusions regarding window size issues
From: Redeeman
Date: Thu Jul 08 2004 - 16:57:40 EST
hey bert, a little update on things.
for 2 days ago, when we chatted on irc first, i could reach lkml.org,
however, i had played abit with various settings.. i cant get that
working now, neither can i get tcpdump to give me info....
i replaced my ugly speedstream router with a linux box, and speed has
rised, as you predicted :D, it must have been the host mapping that
doing some bad things, thanks for suggesting that :D
theres a new site, which i cant reach either.. with 2.6.7, but 2.6.5
can. its my ipv6 tunnel broker, netgroup, the url is:
http://noodle.ngdc.net/~hroi/tb/
however, when i bring the ipv6 tunnel up, i can reach it, but thats
probably via ipv6.
with ipv6 i cant connect to lkml.org either..
if you help me with the tcpdump paramters i will gladly provide all info
i can..
thanks for all the help you did. it seems very close now :D
On Thu, 2004-07-08 at 01:27 +0200, bert hubert wrote:
> Two things:
>
> 1) packages.gentoo.org is currently unreachable by 2.6.7-recent.
> This has been confirmed from several places, very easy to reproduce. Bug has
> been filed with gentoo to fix their firewall.
>
> 2) What Alessandro Suardi sees is highly similar, except that he has it with
> *all* remotes, except for google.it and a very small number of other
> servers.
>
> This is what Alessandro saw going out. We artificially lowered the MTU
> because of possible tunelling loss:
>
> 01:03:36.323132 192.168.1.3.33992 > 213.244.168.210.10000: S [tcp sum ok] 3497585848:3497585848(0)
> win 5440 <mss 1360,sackOK,timestamp 2311996 0,nop,wscale 7>
> (DF) (ttl 64, id 43908, len 60)
> 01:03:36.396660 213.244.168.210.10000 > 192.168.1.3.33992: S [tcp sum ok] 3030562636:3030562636(0)
> ack 3497585849 win 5792 <mss 1452,sackOK,timestamp 2142457957 2311996,nop,wscale 0>
> (DF) (ttl 53, id 0, len 60)
> 01:03:36.396719 192.168.1.3.33992 > 213.244.168.210.10000: . [tcp sum ok]
> ack 1 win 42 <nop,nop,timestamp 2312084 2142457957>
> (DF) (ttl 64, id 43909, len 52)
>
> Perfect SYN, SYN|ACK, ACK.
>
> 01:03:36.397362 192.168.1.3.33992 > 213.244.168.210.10000: P 1:463(462) ack 1 win 42
> <nop,nop,timestamp 2312085 2142457957>
> (DF) (ttl 64, id 43910, len 514)
>
> The GET request.
>
> 01:03:36.497588 213.244.168.210.10000 > 192.168.1.3.33992: . [tcp sum ok] ack 463
> win 6432 <nop,nop,timestamp 2142457967 2312085>
> (DF) (ttl 53, id 59171, len 52)
>
> And acked by my server. This trace is identical to what I see on the
> receiving end:
>
> 29.84 62.211.168.xx.33992 > 213.244.168.210.10000: S [tcp sum ok] 3497585848:3497585848(0)
> win 5440 <mss 1360,sackOK,timestamp 2311996 0,nop,wscale 7>
> (DF) (ttl 50, id 43908, len 60)
> 29.84 213.244.168.210.10000 > 62.211.168.xx.33992: S [tcp sum ok] 3030562636:3030562636(0)
> ack 3497585849 win 5792 <mss 1460,sackOK,timestamp 2142457957 2311996,nop,wscale 0>
> (DF) (ttl 64, id 0, len 60)
> 29.93 62.211.168.xx.33992 > 213.244.168.210.10000: . [tcp sum ok] 1:1(0)
> ack 1 win 42 <nop,nop,timestamp 2312084 2142457957>
> (DF) (ttl 50, id 43909, len 52)
>
> 29.95 62.211.168.xx.33992 > 213.244.168.210.10000: P [tcp sum ok] 1:463(462)
> ack 1 win 42 <nop,nop,timestamp 2312085 2142457957>
> (DF) (ttl 50, id 43910, len 514)
> 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1(0)
> ack 463 win 6432 <nop,nop,timestamp 2142457967 2312085>
> (DF) (ttl 64, id 59171, len 52)
>
> Except for TTL and NAT, this is identical.
>
> From here, things start to differ. I measure that I send out:
>
> 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1349(1348)
> ack 463 win 6432 <nop,nop,timestamp 2142457967 2312085>
> (DF) (ttl 64, id 59172, len 1400)
> 29.95 213.244.168.210.10000 > 62.211.168.xx.33992: P [tcp sum ok] 1349:2697(1348)
> ack 463 win 6432 <nop,nop,timestamp 2142457967 2312085>
> (DF) (ttl 64, id 59173, len 1400)
>
> This next packet is a repeat, because no ACK:
>
> 30.23 213.244.168.210.10000 > 62.211.168.xx.33992: . [tcp sum ok] 1:1349(1348)
> ack 463 win 6432 <nop,nop,timestamp 2142457996 2312085>
> (DF) (ttl 64, id 59174, len 1400)
>
> ad nauseam. Alessandro never sees these packets! After a while, he
> disconnects, which happens pretty normally. From another trace (NOTE!):
>
> 00:38:21.326397 192.168.1.3.33285 > 213.244.168.210.10000: F 420:420(0)
> ack 1 win 45 <nop,nop,timestamp 796784 2142304361>
> (DF)
> 00:38:21.410353 213.244.168.210.10000 > 192.168.1.3.33285: .
> ack 421 win 6432 <nop,nop,timestamp 2142306461 796784>
> (DF)
>
> We've tried with wscale=0,1,2 and these all work. Things go wrong for
> wscale>=3. My current feeling is that some kind of QoS device is
> interfering, and that the 'wscale gets stuffed' theory is wrong in this
> case.
>
> I recall that 'Packeteer' QoS devices try to mess with windows.
>
> Alessandro has this DSL modem, which crashed once during testing.
> http://www.usr.com/support/product-template.asp?prod=9003
>
> So we're not done debugging.
>
> --
> http://www.PowerDNS.com Open source, database driven DNS Software
> http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html