Re: preliminary conclusions regarding window size issues

[Redeeman <lkml@metanurb.dk>]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>