ccruss@pollux (Russ Hobby) (11/08/90)
This is a summary of the latest features of the PPP implementation for
the KA9Q code done by Katie Stevens here at UCDavis. The current
version can be used for both the client environment (a remote PC
connecting to the network) and the server environment (like a terminal
server only doing PPP). Like previous versions this one does Van
Jacobson's compression.
The main new feature of this version is that it does authentication and
based on that authentication can verify or assign IP addresses. The
remote PC can tell the server what address he is and it can be verified
by the server via the authentication. Or the remote PC can ask the
server to tell it what its addresses is. The address can be a fixed
address based on the authentication for those that need a fixed address,
or the server can assign a temporary address from a pool of addresses.
The main advantage of having the server assign the address is that the
same software distribution can be handed out to all users with out
having to worry about the configuration file, they're all the same.
Support for an eight line async board is just about done. This is will
make getting more lines into a server easier. We have also be using this code
as low cost routers to sites with low bandwidth requirements and limited
funds. I know that a 9600 baud link to the Internet doesn't sound like
much, but their other option is nothing at all and the 9600 baud line
helps them demonstrate the need for a more reasonable connection. Katie
is also working on the interface to a PC sync board that will allow use
of 56K or 64K sync lines.
The README file on the the code is below.
Russell Hobby
Data Communications Manager
U. C. Davis
Computing Services INTERNET: rdhobby@ucdavis.edu
Davis Ca 95616 BITNET: RDHOBBY@UCDAVIS
(916) 752-0236 UUCP: ...!ucbvax!ucdavis!rdhobby
-----------------------------------------------------------------------
KA9Q Internet Software Package with Point-to-Point Protocol
===========================================================
Files available via anonymous FTP from ucdavis.ucdavis.edu
dist/ppp directory:
NETPPP.ZIP -- compiled code; KA9Q with PPP, sample startup files
and KA9Q documentation
SRC.ZIP -- source code; unmodified distribution file for
KA9Q Internet Software Package v900828 NOS
PPPSRC.ZIP -- source code; additional files for PPP
-- Katie Stevens
dkstevens@ucdavis.edu
Computing Services
University of California, Daviskarn@envy.bellcore.com (Phil Karn) (11/08/90)
In article <9234@aggie.ucdavis.edu>, ccruss@pollux (Russ Hobby) writes: |> Files available via anonymous FTP from ucdavis.ucdavis.edu |> dist/ppp directory: |> |> NETPPP.ZIP -- compiled code; KA9Q with PPP, sample startup files |> and KA9Q documentation |> SRC.ZIP -- source code; unmodified distribution file for |> KA9Q Internet Software Package v900828 NOS |> PPPSRC.ZIP -- source code; additional files for PPP I should mention that I have recently finished merging Katie's code into my standard "NOS" release of KA9Q. The code is available by anonymous FTP from thumper.bellcore.com in directory /pub/ka9q/nos. The source is in src1107.zip and an executable is in net.exe. There is also asmobj.zip, a collection of .obj files assembled from the .asm files in the package. This will allow you to rebuild the system with just the regular Turbo C package from Borland. Without it you need the "Professional" version of Turbo C in order to get the assembler. Phil
greg@cheers.Bungi.COM (Greg Onufer) (11/11/90)
ccruss@pollux (Russ Hobby) writes: >This is will >make getting more lines into a server easier. We have also be using this code >as low cost routers to sites with low bandwidth requirements and limited >funds. I know that a 9600 baud link to the Internet doesn't sound like >much, but their other option is nothing at all [[...]]] It really isn't all that bad except that the downtime is ridiculous. It's almost like when darkness falls, so does the PPP connection to ucdavis. They reboot the PC on their end, and up it comes again--- but that only happens when someone is there (normal business hours). The past few weekends the PPP connection went bad for the whole weekend and into Monday morning. But it's nice to have *any* Internet access at all at UoP. Now if we can just get some computers... Disclaimer: My views are most certainly not those of the University of the Pacific nor of any of my employers. Cheers!greg
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (11/12/90)
In article <C*^^G5*.17206@cheers.Bungi.COM> greg@cheers.Bungi.COM (Greg Onufer) writes: >ccruss@pollux (Russ Hobby) writes: > >>funds. I know that a 9600 baud link to the Internet doesn't sound like >>much, but their other option is nothing at all [[...]]] > >It really isn't all that bad except that the downtime is ridiculous. >It's almost like when darkness falls, so does the PPP connection to >ucdavis. They reboot the PC on their end, and up it comes again--- >but that only happens when someone is there (normal business hours). >The past few weekends the PPP connection went bad for the whole Of course it doesn't have to be that bad. On van-bc we have a cron script that test's that we can ping the router at the far end of our PPP link (formerly SL/IP). If we can't we reboot the router, which drop's DTR which hangs the phone, then when the router comes back up DTR is raised which causes the modem to redial, and the connection is re-established. Our phone lines are quite noisy and typically it will redial once or twice a day. Do that every ten minutes and you have a good chance of even keeping ftp connections going over a reboot. BTW kudo's to Phil Karn and the UCDavis people for the new ka9q with PPP. It seems to be rock solid. SCO Xenix TCP/IP seems to like to play with it. So far our subjective opinion is that running PPP on PC-Routers (with VJ header compression) is definitely a step up and much more solid than running host based SL/IP. We won't go back! One question: does anyone have any opinions on whether it's better to use raw V.32, V.32+MNP, V.32+MNP+compression, or PEP for PPP/VJ type links. Adding MNP will presumably inrease latency over raw V.32. Compression a bit more but might help if lot's of compressable traffic (like a full news feed via nntp). -- Stuart Lynne Unifax Communications Inc. ...!van-bc!sl 604-937-7532(voice) sl@wimsey.bc.ca