Date: Sun, 12 Jan 1997 10:04:52 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: brian@mpress.com Cc: freebsd-current@freebsd.org Subject: TCP code (was Re: tcp_extenions=NO between to FreeBSD Hosts!?) Message-ID: <199701120904.KAA20383@labinfo.iet.unipi.it> In-Reply-To: <19970112060920.20637.qmail@mpress.com> from "brian@mpress.com" at Jan 11, 97 10:09:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The following two hosts > > FreeBSD top.mediacity.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Sat Jan 11 01:17:49 1997 brian@research.mpress.com:/uss/src/sys-UP/compile/LAPTOP i386 > > FreeBSD garfield.panix.com 2.2-BETA_A FreeBSD 2.2-BETA_A #0: Sat Jan 11 20:33:29 PST 1997 larry@garfield.panix.com:/usr/src/sys/compile/LAPTOP-PCD i386 > > cannot talk tcp between each other unless one of us has issued the command: > > sysctl -w net.inet.tcp.rfc1644=0 > > so is the problem one of us, or a router in between us? Some routers are known to choke on packets with data _and_ TCP options, but that reportedly occurs with RFC1323 as well. As a result if you use tcpdump you should at least see the SYN packets go through. However perhaps a couple of months ago somebody (Karl Denninger perhaps ?) reported problems with TCP apps which would misteriously go away recompiling with gcc2.6.X instead of 2.7.X (don't remember if he recompiled the kernel or just his application). This is probably worth giving a try, if not for yourself (since disabling rfc1644 seems to help) for the FreeBSD community in that it might be a compiler-related bug. A (radical) comment related to this: The tcp code (and specifically, tcp_input.c) is one of the most critical part of the kernel since, for efficiency, it uses one huge function written going against all good principles of sw engineering (many goto's, code is replicated at times to deal with the common cases without branching too much, etc...). I wouldn't be surprised that the compiler's optimizer fails on it. Note that, unlike other complex parts of the system (e.g. the VM code), tcp is pretty much untouchable since it (and some of its bugs) is documented (in the Steven's book) and nobody feels like touching it at the risk of writing something more readable, but less tested and possibly slightly slower [I myself embarked in such a work when I wrote the SACK code, and these reasons -- which I kind of agree with -- came out when I suggested a slight cleanup of that code]. Now the above argument is partly defeated by the fact that we have also T/TCP, which is a major modification of the code, and I believe is little used hence little tested. Maybe it's time to accept the idea that the TCP code is not carved on stone. I for one would be more than willing to work on it. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701120904.KAA20383>