gregg@quintus.UUCP (W. Gregg Stefancik) (11/24/87)
Has SLIP been wired into any TCP/IP package for the IBM-PC? I would be interested in non-commercial packages. Gregg Stefancik Quintus Computer Systems
jbvb@ftp.UUCP (James Van Bokkelen) (11/24/87)
The only PC implementation of SLIP I know of is ours, which is commercial. James B. VanBokkelen FTP Software Inc.
mac@idacrd.UUCP (Bob McGwier) (11/24/87)
in article <264@tarski.quintus.UUCP>, gregg@quintus.UUCP (W. Gregg Stefancik) says: > > Has SLIP been wired into any TCP/IP package for the IBM-PC? I would be > interested in non-commercial packages. > > Gregg Stefancik Phil Karn's KA9Q net.exe supports SLIP. It is available for ftp on louie.udel.edu, ftp anonymous /pub/ka9q/net_src.arc and used pkxarc to de-arc it. Bob
ddl@husc6.UUCP (Dan Lanciani) (11/25/87)
The CMU pc/ip code includes a SLIP driver. Dan Lanciani ddl@harvard.*
TS0400@OHSTVMA.BITNET.UUCP (11/26/87)
It would seem that if one is going to use SLIP in a dial-in environment,
would not POP also be called for? Is there an implementation of SLIP/POP
available?
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>khanna@JESSICA.STANFORD.EDU.UUCP (11/26/87)
At Stanford we are planning to add SLIP facility to our SU-PC/IP package. POP client for PCs already exists and it would definiteley be supported over SLIP. We have looked at many SLIP implementations and my concern is that most implementations require PCs to have IP addresses in the custom file. From my experience with PCs on ethernet, I have realized that, no matter what you do, people are going to make copies of PC/IP diskettes and ignore to change IP address. This results in multiple machines with same IP address. This was the reason for resorting to RARP and BOOTP for allocating IP addresses to PCs. Does anyone else share my concern? I am looking for a scheme in which an IP address would be dedicated to each line on the server. During the handshake this address could be assigned to the PC for the duration of the session. I plan to raise this issue at the Interoperability meeting. raman khanna
snorthc@NSWC-OAS.ARPA.UUCP (11/30/87)
I share the concern voiced by Raman vis SLIP. PC users WILL share diskettes, a small minority of them will realize/bother to change the IP address. SLIP and its 'fixed' IP address is a problem which prevents greater/more functional use of SLIP. NetBIOS/SLIP anyone? I still feel it is too bad the Stanford people will not make their code available to the (Non-Academic) net community. We never found POP anywhere else. I cannot see how this benefits Stanford, the academic community, DOD, or the country (USA). Stephen Northcutt (snorthc@nswc-g.arpa) Disclaimer: All personal opionions.
nelson@CLUTX.CLARKSON.EDU.UUCP (11/30/87)
> SLIP and its 'fixed' IP address is a problem which prevents >greater/more functional use of SLIP. I don't understand why this is a problem. There are two simple and workable solutions: give one IP number per phone line, or, if using unix, give one IP number per userid. Surely bootp can be made to recognize a serial line address as well as it does an ethernet address... -russ
BILLW@MATHOM.CISCO.COM (William Westfield) (11/30/87)
Surely bootp can be made to recognize a serial line
address as well as it does an ethernet address...
Well, ethernet addresses are supposed to be unique in the world, so
that the mapping from ethernet address to IP address is also unique.
Is there any software readable equivilent for PCs? Say, something
like the serial number combined with the computer type ?
Bill Westfield
cisco Systems.
-------ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (12/01/87)
I've been thinking about this for quite a while now and I have a few ideas. I've been planning on putting together a proposal but haven't gotten the time... There are three options that I see: 1. Use the MIT SLIP. It provides IP address assignment in the link layer protocol. Gross, but it works. The problem with this option is that it requires a modified driver at the server end. I.e. it doesn't work with the UNIX SLIP driver. 2. Use BOOTP more or less unmodified. You quickly run into the issue Bill Westfield pointed out, lack of a unique serial number (ethernet address). However, assuming that the IP address is associated with the incoming port and NOT the PC, this is not a problem since the BOOTP server would always answer the same IP address to queries received on that port. It wouldn't be too hard to modify the boot server to do this. 3. Invent a new BOOTP-like protocol more appropriate for serial line use. I think this protocol should be more capable than bootp/rarp type protocols and should allow you to configure a SLIP line in a number of different ways. It should allow either end to request an address from the remote end OR allow either end to tell the remote end who it wants to be. The remote end should have the capability of rejecting the desired address if that address would not allow packets to be routed correctly. Both ends of the connection would be configured to operate in either mode, either through some kind of configuration info or maybe hardcoded into the particular implementation. I.e. maybe a UNIX SLIP implementation wouldn't allow the remote end to specify it's own address. Drew
BILLW@MATHOM.CISCO.COM (William Westfield) (12/02/87)
Well, at cisco we are making SLIP server boxes, and there are additional considerations. Consider the following situation: +--------+ PC1------| cisco | Ethernet HOST2 TERMINAL----| slip |==================================.... PC2------| server | HOST1 HOST3 +--------+ Let's assume that PC1 is permanently connected to the server. Its address is fixed, and it is not a problem. TERMINAL is a terminal; it doesn't have an IP address, so it is not a problem. PC2, however, is on a dial-in port, and might be some other PC at some other time. It is the source of all the problems. Let's further assume that we have decided to use some variation of the BOOTP protocol for PC2 to get/specify its own IP address (note that BOOTP has a packet field for "Vendor specific information", and could probably be easily extended to do anything we want, without having to invent a NEW protocol). There are a couple of possibilities as to who would answer such a BOOTP request - either one of the HOSTs on the ethernet, or the slip server itself. The SLIP server HAS to know this information, for obvious reasons, so it seems like the logical that it should answer. However, the usual function of the SLIP server is to receive SLIP format IP packets from the serial lines and send them out the ethernet, and to snarf appropriate packets off the ethernet and send them down the serial line. It never does much in the way of looking inside any of the packets, beyond making sure they have valid IP headers. To have the server check each packet to see whether it is a BOOTP request would be undesirable. One solution that I sort of like is to use a different IP version number in the bootp packet, as a hack to indicate that it should be looked at by intermediate gateway type entities. In the MIT PC/IP model of the world, you probably want a separate bootp program to set things up in the device driver - otherwise every application has to have its own bootp code, which is probably more work than necessary. Presumably you could say something like "bootp 326-1941", have it dial that number, do its thing, set up the configuration, and exit... An additional piece of information that needs to be requested/provided somehow is whether the PC is going to attempt to be a gateway for some other network behind it - this isn't necessarily possible (I sent a long message to TCP-IP a while ago explaining the differences between gateway and terminal-server models of SLIP servers - should I repost that to this list also ?). In general, I think that dial-in slip connections should have a fixed set of IP addresses that are allowed. Having a separate IP address for every PC that could dial in will quickly become a address-management nightmare. Bill Westfield cisco Systems. -------
tcasey@CS.UCL.AC.UK (12/02/87)
Bill, I probably got it but lost it, so will you send me a copy of your msg re diffs between gateway and terminal-server models of SLIP servers? Thanks Tom