Date: Wed, 04 Apr 2012 01:38:41 +1000 From: Darren Reed <darrenr@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size Message-ID: <4F7B1981.1050009@freebsd.org> In-Reply-To: <4F7AFEEF.60708@freebsd.org> References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/04/2012 11:45 PM, Andre Oppermann wrote: > On 01.04.2012 09:27, Darren Reed wrote: >> Andre, >> >> Your changes bring it closer to working correctly with a >> small change: rather than "tiwin > tp->snd_wnd", it should >> be "tiwin != tp->snd_wnd". In this trace, the remote end >> has set a window scale factor of 5 during connection >> establishment. >> >> The same change should be made in the if() a few lines down. > > Window updates are a tricky thing by that we must not accept > old and outdated segments to update our window. Hence we have > to test for freshness while at the same time be open enough > to handle weird cases like bidirectional data transfers on > lossy links with data waiting in reassembly queues on both > sides. > > There are two clear cut cases we can accept a window update: > > a) the incoming segment ACK'ed new data (moved snd_una). > b) the incoming segment carries new data (moved rcv_nxt). > > The latter gets tricky already with the addition of the > reassembly queue. Here only segments that have a higher SEQ > than highest already present in the reassembly queue are OK. > > And then we have a window probe where we'll get an answer > that neither moves our ACK (zero byte probes) nor carries > any data. Here the window update is vital for the future > progress of the session. Hmmm, what about retransmitted data that fills a response in response to a TCP packet with SACK present? So that would be (b) from above but rcv_nxt does not get moved? So remote sends 4 packets with 1440 data bytes, freebsd82 receives pkts 1, 3 & 4, ACK's 1, uses SACK to repsond to 3 & 4, new data arrives from remote at freebsd82 but with the TCP window set to 0. >> The problem here is that it only tracks the window size as >> it grows, not as it shrinks. Thus the remote end setting its >> window size to 0 is ignored. > > My patch is wrong as the acked count is already integrated > by the time we reach this spot. I'm working on a better > implementation. Ok, I'll look forward to seeing and testing it. > It's the other way around. remote.ssh is sending old data > which freebsd82.62922 has already ack'ed. The sessions seems > to be de-synchronized, perhaps some middle box mucking with > the segments trying to modulate something? I suspect that the ISP is dropping packets and/or applying some other means of throttling the connection. So, yes. Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F7B1981.1050009>