SACK problems

[Mark Allman]

> During some testing on an isolated network we have, I found some
> interesting behaviour from a FreeBSD 5.3 host using TCP SACK.
> 
> I've detailed this problem fully at:
> 
>     http://www.wand.net.nz/~stj2/nsc/emu_freebsd.html
> 
> PCAP traces and some screenshots from tcptrace graphs can be found
> at the above link to show what is happening. It looks to me like
> SACK blocks are being incorrectly generated in this example. I can't
> think of any valid reason why a SACK block would SACK from below the
> current ACK value to above it (which is the problem here).
> 
> Thoughts, anyone? Am I just wrong here and this is valid, expected
> behaviour?

RFC2883 offers a case when this would happen --- in the reporting of
"duplicate SACKs".  I.e., the DSACK extension reports segments that have
arrived more than once.  I don't suppose this is the problem (since it's
freebsd everywhere, right?).  But, while folks are messing about in the
SACK code this RFC might be something to think about including.

allman


--
Mark Allman -- ICIR -- http://www.icir.org/mallman/




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20050214/c4ca72fb/attachment.bin