TCP options order changed in FreeBSD 7, incompatible with some routers

Bjoern A. Zeeb bzeeb-lists at lists.zabbadoz.net
Wed Mar 12 07:50:08 PDT 2008


On Tue, 11 Mar 2008, d.s. al coda wrote:

> - FreeBSD 7 has <mss 1412, sackOK, eol> (there is of course an aligning nop
> after the eol, which tcpdump skips)

Which is a bug (the nop after the EOL) that I recently fixed in HEAD.
I am still curious to know if it's only ordering or the invalid padding
or both that keeps clients from connecting. The problem is getting
hands on such a problematic "client".

I still cannot see why someone would drop because of option ordering
but I could see why someone would drop because of the wrong padding
which is violating the TCP RFC.

Of course other exmaples seem to have shown that it was option
ordering that made peers freak out and drop the packet.


> - These options don't appear in this exact configuration when using RFC1323
> options.
>
> I get a hunch that the users with the problem have a router that erroneously
> thinks that these options are invalid, or thinks that the some part of byte
> sequence (e.g. 0204 05b4 0101 0402) is an attack.
>
> Just to try it out, I patched tcp_output.c so that the SACK permitted option
> was aligned on a 4-byte boundary, preventing the "sackOK, eol" pattern from
> ever occuring.  Looking through previous versions, I found where the tcp
> option code had changed, and there used to be a comment about putting SACK
> permitted last, but I can't tell if it's relevant.
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.125;r2=1.126
>
> The one-line patch to tcp_output.c is attached.
>
> Sure enough, it fixed the problem. Afterwards, we collected some information

That of course seems to have dropped the need for padding after a
possible EOL (if there is no EOL anymore) hiding the second problem.

I wonder if you would have the resources to try this patch (on an
unpatched kernel)

http://docs.freebsd.org/cgi/mid.cgi?200803091326.m29DQoCI095152

and find out if one of the formerly not working users can connect
again.

As said before this might not be the case and it might be option
alignment/ordering but that would rule out the padding problem for us.


/bz

-- 
Bjoern A. Zeeb                                 bzeeb at Zabbadoz dot NeT
Software is harder than hardware  so better get it right the first time.


More information about the freebsd-net mailing list