mallman at icir.org
Mon Feb 14 20:31:32 PST 2005
> 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:
> 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
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.
Mark Allman -- ICIR -- http://www.icir.org/mallman/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 185 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20050214/c4ca72fb/attachment.bin
More information about the freebsd-net