🚀 go-pugleaf

I've left a new version of my SLIP software on SONATA.CC.PURDUE.EDU and
CS.ORST.EDU.  Look for the files:

-rw-r--r--  1 louie       4462 Sep  4 22:27 SLIP_920904.README
-rw-r--r--  1 louie        291 Sep  4 22:27 SLIP_920904.md5
-rw-r--r--  1 louie     532480 Sep  4 22:27 SLIP_920904.tar

This version has been updated to work with NextStep Release 3.0.
There were two prior releases, not widely announced which corresponded
to NextStep 3.0 PR1 and 3.0 PR2.  

There are some minor bug fixes here and there.  The only real new
"feature" is a traceback whenever a TCL error occurs.  This should make
it much easier to debug TCL dialer scripts.

The 920904 version should work with Release 2.1, 2.2, 3.0 PR1, 3.0 PR2
and 3.0.  Note that due to bugs in the serial driver in release 2.0,
you probably shouldn't bother trying to run SLIP (or anything else
that requires the power to the system to be turned on, for that
matter).

The version sensitivity is almost exclusively due to a single bug in
the NeXT Mach kernel that was reported in 2.1, 2.2, 3.0 PR1, and 3.0
PR2.  For some reason unknown to me, the 3 line fix to
netinet/tcp_output.c that I supplied has not been installed.  Because
of this, the SLIP kernel driver has to reach into the code and patch
it.  The location of the patch, of course, varies with every version
of the kernel.  So you see, I have this (ever lengthing) table of
patch locations which is becomine most tiresome to keep updating.

The only time this bugs comes home to roost is if you use an MTU on
the SLIP interface less than 576 bytes, so most folks won't be
affected.  Thus, if you see the warning message:

dialupip: Can't patch tcp_output() MSS option bug: unknown kernel version
dialupip: Note that this is NOT a fatal error.  Don't panic.  See manual
dialupip: for further details about this issue.

Don't worry about it.  If you like, you can call NeXT and ask them why
bug reports: 15949, 16323, 16625, 25449	(3.0 PR1), 29905 (3.0 PR2)
can't seem to be fixed or even given some disposition (like "go away,
we can't be bothered", "fixed in next release" or "we don't understand
your suggested fix").  

For those interested, the body of the actual bug report from 14 Aug
1991 is as follows.  The code noted is from the Berkeley networking
code which had the bug in an earlier version (which NeXT apparently
still uses).  I've been getting real good at reading disassembled
code, a skill I had hope I would not have to develop.

==============================================================================

When a TCP connection is opened, the TCP Maximum Segment Size option is
not always sent.  The existing code in tcp_output.c only sends a MSS option
if the MTU of the interface is larger than the default 536 byte MSS.  If 
the MTU of the interface is smaller (such as 256 bytes for a SLIP interface
using VJ TCP header compression), no MSS option is sent.  This causes the
remote TCP to send "large" packets which are fragmented by the SLIP gatway,
negating the usefulness of the TCP header compression.

You need to change this code in tcp_output.c

        opt = NULL;
        if (flags & TH_SYN && (tp->t_flags & TF_NOOPT) == 0) {
                u_short mss;

                mss = MIN(so->so_rcv.sb_hiwat / 2, tcp_mss(tp));
                if (mss > IP_MSS - sizeof(struct tcpiphdr)) {
                        opt = tcp_initopt;
                        optlen = sizeof (tcp_initopt);
                        *(u_short *)(opt + 2) = htons(mss);
                }
        }

to something like this:

        opt = NULL;
        if (flags & TH_SYN && (tp->t_flags & TF_NOOPT) == 0) {
                u_short mss;

                mss = MIN(so->so_rcv.sb_hiwat / 2, tcp_mss(tp));
                opt = tcp_initopt;
                optlen = sizeof (tcp_initopt);
                *(u_short *)(opt + 2) = htons(mss);
        }

The added "overhead" of always sending an MSS option is minimal since
its only sent in one segment and is only 4 bytes long.

==============================================================================

Note the extent of the fix is to remove two lines (the `if' and the
the closing brace) and to re-indent the body of the if statement
removed.  I'm not sure what futher assistance I can be to NeXT in
getting the problem resolved beyond giving them the actual source code
changes.  Presumably good networking code is not required for "Mission
Critical" applications, though I would have thought it would have been
during the "Interpersonal Computing" marketing era.

At this point, I have given up relying on NeXT to fix the problem and
just hope that it will go away if they decide to use a relatively
modern version of the Berkeley networking code in some future release.

Sigh.  Please note Followup-To: line.

louie