Date: Mon, 22 Jun 2015 13:07:56 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: Jean-Francois HREN <jean-francois.hren@stormshield.eu> Cc: freebsd-net@freebsd.org, Damien DEVILLE <damien.deville@stormshield.eu>, Fabien Thomas <fabien.thomas@stormshield.eu> Subject: Re: Sequence number handling issue with TCP data and FIN flag with a transient error Message-ID: <20150622200756.GP37728@strugglingcoder.info> In-Reply-To: <20150617183734.GA53336@strugglingcoder.info> References: <1180135344.2814172.1434546351593.JavaMail.zimbra@stormshield.eu> <1176517609.2815392.1434546629748.JavaMail.zimbra@stormshield.eu> <20150617183734.GA53336@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 06/17/15 at 11:37P, hiren panchasara wrote: > On 06/17/15 at 03:10P, Jean-Francois HREN wrote: > > Hello, while investigating a freeze on a modified FreeBSD 9.3 I stumbled upon > > a potential bug in netinet/tcp_output.c > > > > If an error occurs while processing a TCP segment with some data and the FIN flag, > > the back out of the sequence number advance does not take into account > > the increase by 1 due to the FIN flag > > (see https://svnweb.freebsd.org/base/head/sys/netinet/tcp_output.c?view=markup#l1360 > > and https://svnweb.freebsd.org/base/head/sys/netinet/tcp_output.c?view=markup#l1439 ). > > > > In the case of a transient error, this leads to a retransmitted TCP segment with > > a shifted by 1 sequence number and a missing first byte in the TCP payload. > > > > In FreeBSD 9.3, it happens only when an error occurs in netinet/ip_output.c::ip_output() > > or netinet6/ip6_output::ip6_output() but in head, R249372 > > ( https://svnweb.freebsd.org/base?view=revision&revision=249372 ) now allows > > the same behaviour if an ENOBUFS error occurs in netinet/tcp_output.c > > Your analysis looks correct to me. > > > > Tentative solutions would be either to remove the back out of the sequence > > number advance completely and to treat transient error cases like real lost > > packets > > > > --- netinet/tcp_output.c > > +++ netinet/tcp_output.c > > @@ -1435,8 +1435,7 @@ > > tp->sackhint.sack_bytes_rexmit -= len; > > KASSERT(tp->sackhint.sack_bytes_rexmit >= 0, > > ("sackhint bytes rtx >= 0")); > > - } else > > - tp->snd_nxt -= len; > > + } > > } > > SOCKBUF_UNLOCK_ASSERT(&so->so_snd); /* Check gotos. */ > > switch (error) { > > > > or to decrease the sequence number advance by 1 if a FIN flag was sent. > > > > --- netinet/tcp_output.c > > +++ netinet/tcp_output.c > > @@ -1435,8 +1435,11 @@ > > tp->sackhint.sack_bytes_rexmit -= len; > > KASSERT(tp->sackhint.sack_bytes_rexmit >= 0, > > ("sackhint bytes rtx >= 0")); > > - } else > > + } else { > > tp->snd_nxt -= len; > > + if (flags & TH_FIN) > > + tp->snd_nxt--; > > + } > > } > > SOCKBUF_UNLOCK_ASSERT(&so->so_snd); /* Check gotos. */ > > switch (error) { > > I like the second approach better. Does anyone else have any opinion on this? We should commit this to -head soon to get it in for 10.2 time-frame. Cheers, Hiren [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJViGsbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/loNwH/R9nEyiVTcdULkXL3MgmNDdQ DA3roiWDXNrMYN93Q4iAaGluHL0QsGW8zAYOYmpftJO2mDeK6wP1GrocYsqGlY0D 1k9IZFQEcW3tWU5W648/OuhTXyr/4HgQXS0w2omGeSUJhgnqIwym2rLuEfg3iL8w qo+SGRUR26OKb6hF5Cp2GJDCCxtw7iAGbEZ866Sih5gODA80dpn0aOv1sHibf0+q qGL6XgqXPOZp3rJ+ms/Ra0ZV2HLwRT7ltPP4sY/oK3w9SHbgPgYN7YEwqX4ZdWtQ jEzHL94uS/VoJsovg1hh4A4irB08D7lUvNcnXpxVm15k20BcfkFoR6d+k1cjH80= =0nYd -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150622200756.GP37728>