Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!news.arc.nasa.gov!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: Tuning slip on a T2500/NextStation
Message-ID: <1991Jun17.144459.11274@ni.umd.edu>
Date: 17 Jun 91 14:44:59 GMT
References: <456@nic.cerf.net> <1991Jun16.184117.26803@ni.umd.edu> <1742@toaster.SFSU.EDU>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 28
Nntp-Posting-Host: sayshell.umd.edu

In article <1742@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes:
>Please, please, please contribute your work back to BBN/CREN.
>Many people will be much appreciative (and you won't have to
>work so hard tracking releases).

Actually, the compressed slip code just drops right in.  Specifically,
slcompress.h and slcompress.c drop in with two lines of changes to
accomodate the NeXT's idea of 'netbufs' rather than the mbuf
structures that it expects.

Then you make another 10 or 20 lines of changes in the main line SLIP
code, pretty much just stealing the sample code from the TCP header
compression RFC.  I'm surpised that no one has done this yet; or
perhaps, since its not too hard they just haven't made much of a fuss
about it.

The hard part on the NeXT is that the SLIP driver (if_du.c in DailUpIP
or generically, if_sl.c) has been worked over to accomodate the NeXT's
network API which provides an "opaque" interface to the mbufs and
netifs that we all know and love.  That's what make it difficult to
generalize the work that I've done as far as the compressed SLIP goes.
The changes for compressed SLIP are not that extensive, I'm just
starting from something a bit different from the normal SLIP driver.

Of course, I still haven't got it to work quite yet, something weird
going on with IP fragments...

louie