From mboxrd@z Thu Jan 1 00:00:00 1970 From: Redeeman Subject: Re: preliminary conclusions regarding window size issues Date: Thu, 08 Jul 2004 23:57:04 +0200 Sender: linux-net-owner@vger.kernel.org Message-ID: <1089323824.27085.6.camel@localhost> References: <20040707232757.GA14471@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , Stephen Hemminger , jamie@shareable.org, netdev@oss.sgi.com, linux-net@vger.kernel.org, LKML Mailinglist , ALESSANDRO.SUARDI@ORACLE.COM Return-path: To: bert hubert In-Reply-To: <20040707232757.GA14471@outpost.ds9a.nl> List-Id: netdev.vger.kernel.org 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 > (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 > (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 > (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 > > (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 > (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 > (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 > (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 > (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 > (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 > (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 > (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 > (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 > (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 > (DF) > 00:38:21.410353 213.244.168.210.10000 > 192.168.1.3.33285: . > ack 421 win 6432 > (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/ >