paul@cscnj (Paul Moody) (01/08/91)
Does anyone know of an implementation of PPP or SLIP for STREAMS? Preferably for ATT 386. Even more preferably with source. Thanks in advance Paul Moody -- Paul Moody UUCP: rutgers!cscnj!paul Computer Sciences Corporation PHONE: (908)562-6529 # the opinions expressed are entirely imaginary #
tin@smsc.sony.com (Tin Le) (01/09/91)
In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes: > >Does anyone know of an implementation of PPP or SLIP for STREAMS? >Preferably for ATT 386. Even more preferably with source. Yes, I have one I found (I think) on ftp.ee.lbl.gov. $ ls -l ppp* -rw-r----- 1 tin eng 98223 Oct 23 23:14 ppp-streams.tar.Z You can try getting it yourself if you have ftp. If not, I can mail it to you. I haven't had time to try it out yet (I am working on SVR4). -- Tin -- .---------------------------------------------------------------------- . Tin Le Work Internet: tin@smsc.Sony.COM . Sony Microsystems UUCP: {uunet,mips}!sonyusa!tin . Work: (408) 944-4157 Home Internet: tin@szebra.uu.net
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (01/09/91)
In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes: >Does anyone know of an implementation of PPP or SLIP for STREAMS? >Preferably for ATT 386. Even more preferably with source. If you are talking about paying for a commercial product, I believe Spider TCP/IP (A British company, I don't have a contact for them because our copy came bundled w/ our OS & hardware) is STREAMS based, and supports data-link over X-25 and SLIP, as well as ethernet, and is STREAMS based. They exhibited at InterOp (great show!), but I think I trashed my exhibitors list. Does Wollengong TCP/IP support other data-link layers besides ethernet as a standard part of the package? Good luck, Dan --- Daniel A. Graifer Coastal Capital Funding Corp. Sr. Vice President, Financial Systems 7900 Westpark Dr. Suite A-130 (703)821-3244 McLean, VA 22102 uunet!fciva!dag fciva.FRANKCAP.COM!dag@uunet.uu.net
jbreeden@netcom.UUCP (John Breeden) (01/09/91)
In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes: > >Does anyone know of an implementation of PPP or SLIP for STREAMS? >Preferably for ATT 386. Even more preferably with source. > AT&T SysV/386 R4's Win/TCP R4 has a SLIP driver (and other goodies). -- John Robert Breeden, netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."
tin@smsc.sony.com (Tin "Man" Le) (01/10/91)
>In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes: >Does anyone know of an implementation of PPP or SLIP for STREAMS? >Preferably for ATT 386. Even more preferably with source. Previously I mentioned something called ppp-streams.tar.Z that contain an implementation of PPP for streams (and BSD/socket). I made a mistake when I said it was available on ftp.ee.lbl.gov (actually that was where I found cslip source code, not PPP). You can get ppp-streams from UC Davis, ucdavis.ucdavis.edu [128.120.2.1], in the directory /dist/ppp. -- Tin -- .---------------------------------------------------------------------- . Tin Le Work Internet: tin@smsc.Sony.COM . Sony Microsystems UUCP: {uunet,mips}!sonyusa!tin . Work: (408) 944-4157 Home Internet: tin@szebra.uu.net
larry@nstar.rn.com (Larry Snyder) (01/10/91)
jbreeden@netcom.UUCP (John Breeden) writes: >AT&T SysV/386 R4's Win/TCP R4 has a SLIP driver (and other goodies). how about PPP (compressed headers) SLIP? -- Larry Snyder, NSTAR Public Access Unix 219-289-0282 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu}
tin@smsc.sony.com (Tin "Man" Le) (01/10/91)
In article <1991Jan9.195420.2011@smsc.sony.com> tin@smsc.sony.com (Tin "Man" Le) writes: >>In article <1991Jan8.154358.32@cscnj> paul@cscnj (Paul Moody) writes: >>Does anyone know of an implementation of PPP or SLIP for STREAMS? >>Preferably for ATT 386. Even more preferably with source. > > Previously I mentioned something called ppp-streams.tar.Z that contain > an implementation of PPP for streams (and BSD/socket). I made a mistake > when I said it was available on ftp.ee.lbl.gov (actually that was where > I found cslip source code, not PPP). > > You can get ppp-streams from UC Davis, ucdavis.ucdavis.edu [128.120.2.1], > in the directory /dist/ppp. I've been told that the ppp stuffs on ucdavis is for PC only, using KA9Q. Sorry about that. One more update. The response to my posting has been more than I have time to handle. Thanks to Paul Vixie, ppp-streams.tar.Z is now on gatekeeper.dec.com (or should be soon). I've mailed it off to him. Just keep checking on there, in /pub/net/ppp* One other place to check is tut.cis.ohio-state.edu, in /pub/ppp That contain ppp-streams, modified for SunOS 4.1. -- Tin -- .---------------------------------------------------------------------- . Tin Le Work Internet: tin@smsc.Sony.COM . Sony Microsystems UUCP: {uunet,mips}!sonyusa!tin . Work: (408) 944-4157 Home Internet: tin@szebra.uu.net
tin@smsc.sony.com (Tin "Man" Le) (01/11/91)
In article <1991Jan09.203715.2498@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: >jbreeden@netcom.UUCP (John Breeden) writes: > >>AT&T SysV/386 R4's Win/TCP R4 has a SLIP driver (and other goodies). > >how about PPP (compressed headers) SLIP? > PPP != SLIP They are two different things. SLIP = Serial Line IP PPP = Point to Point Protocol The original SLIP was a straight forward encapsulation type of IP onto serial line. Van Jacobson later added header compression to SLIP (CSLIP, available at ftp.ee.lbl.gov). PPP is a newer protocol, designed to get around problems in SLIP. -- Tin -- .---------------------------------------------------------------------- . Tin Le Work Internet: tin@smsc.Sony.COM . Sony Microsystems UUCP: {uunet,mips}!sonyusa!tin . Work: (408) 944-4157 Home Internet: tin@szebra.uu.net
paul@cscnj (Paul Moody) (01/12/91)
Many thanks to all who have responded. We had intended to go with S5R4. Its nice to know that slip comes with it. Paul -- Paul Moody UUCP: rutgers!cscnj!paul Computer Sciences Corporation PHONE: (908)562-6529 # the opinions expressed are entirely imaginary #
fks@FTP.COM (Frances Selkirk) (01/12/91)
> PPP is a newer protocol, designed to get around problems in SLIP.
Specifically, PPP masks characters (in a given range) that a modem
might interpret as control characters and masks them. It transmits the
masked character preceded by a character which signals to PPP that the
following character is masked. The receiving PPP implementation then
decodes the masked character. Because of this, PPP can actually be somewhat
slower than SLIP, but it is more dependable. Assumably, that dependability
should save you time in the long run.
Frances Kirk Selkirk info@ftp.com (617) 246-0900
FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (01/12/91)
It is also worth reminding people that PPP support does not necessarilly imply that header compression is supported. Header compression support is orthagonal to whether you run SLIP or PPP... BillW -------
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (01/13/91)
> PPP is a newer protocol, designed to get around problems in SLIP.
[Stuff about masking dangerous characters]
This is only one of the problems PPP was designed to solve. Off the
top of my head, here are some others:
PPP has a CRC covering the whole packet, SLIP uses the IP/TCP/UDP
checksum, which was (a) never intended to detect the types of errors
likely to occur in async transmission, and (b) not always present
(NFS comes to mind).
PPP is designed to support protocols other than IP.
PPP includes a negotiation protocol to negotiate "stuff", like the
address of each end, compression, encryption, authentication, protocols,
and so on. Many people seem to think that PPP implies support of TCP
header compression, but this is just an option that can be negotiated.
PPP is defined for both Sync and Async communications. Things like
async PPP to sync PPP translation are theoretically possible.
On the dim side, PPP is very new, so not all of its advantages are
exploited by the implementations currently available. Currently,
IP is the only protocol widely supported (and the only one that has
made it to RFC status, I think.) Hopefully, time will change this.
Bill Westfield
cisco Systems.
-------mshiels@tmsoft.uucp (Michael A. Shiels) (01/13/91)
But does PPP negotiate things like full/half duplex connection? If it's half duplex do some sort of polling back and forth to say who can transmit.
tcs@ccci.UUCP (Terry Slattery) (01/14/91)
> On the dim side, PPP is very new, so not all of its advantages are > exploited by the implementations currently available. While PPP solves some of the SLIP problems and is blessed with RFC status, there is still a problem with *real* multi-vendor support. I cannot get a vendor supported, dial-up, serial link protocol for interconnecting workstations, routers, and terminal servers. When I asked vendors at Interop about PPP, many shrugged it off. There wasn't even the vague "We're working on it" that was heard about OSPF, Frame Relay, and all the other new stuff. No-one is interested in SLIP support due to the problems already mentioned on this list, and I agree with them. Besides the use of connecting remote workstations to central sites, there is a real need to build backup connections for diagnosing and working around WAN link failures. A few places can afford to purchase switched 56K service, but most perfer to live with one circuit, and rely on some method of accessing the remote equipment when this one link dies. Multiple dial-up links could be brought up to replace the failed link if the OSPF or IGRP routing protocol support of multi-path were used. One of the problems is that FDDI, Frame Relay, OSPF, and all the new stuff is 'sexy' and is getting the majority of the resources at workstation and router vendors. Until enough customers start asking for PPP, they will continue to put it on the back burner. I don't recall ever hearing about a PPP interoperability test. Perhaps Interop should consider setting up a demonstration of PPP at its next conference? Consider this my vote for vendors to support PPP in their products. -tcs Terry Slattery Chesapeake Computer Consultants, Inc. Network and Unix Consulting 2816 Southaven Drive (301) 970-8076 Annapolis, MD 21401
scooper@max4.llnl.gov (Steve Cooper) (01/15/91)
> >I don't recall ever hearing about a PPP interoperability test. Perhaps >Interop should consider setting up a demonstration of PPP at its next >conference? At Interop '90 there was a small "Solutions Showcase (tm) Demonstration" on PPP. It had cisco, Telebit, 3Com, and Network Systems communicating at 56K bps synchronous and Telebit, INTERACTIVE, and Xylogics communicating at 9.6K and 19.2K bps asynchronous. There is also a nice little article discussing SLIP and PPP in the January 7, 1991 _UNIX Today!_. >Consider this my vote for vendors to support PPP in their products. > > -tcs > You can add my vote, too. -- ---------------------------------------+-------------------------------- Stephen P. Cooper | scooper@aracmax1.llnl.gov (now) who works at but does not represent | cooper10@llnl.gov (soon) Lawrence Livermore National Laboratory |
jbvb@FTP.COM (James B. Van Bokkelen) (01/16/91)
At Interop '90 there was a small "Solutions Showcase (tm) Demonstration"
on PPP. It had ... and Telebit, INTERACTIVE, and Xylogics communicating
at 9.6K and 19.2K bps asynchronous....
We had PPP code there, but not all implementations interoperated as of that
date. The list of implementations that I know to interoperate is larger now,
but I'd still recommend "try before you buy".
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (01/16/91)
In article <9101131946.AA28696@ccci>, tcs@ccci.UUCP (Terry Slattery) writes: > ... > > I don't recall ever hearing about a PPP interoperability test. Perhaps > Interop should consider setting up a demonstration of PPP at its next > conference? ... There was talk of an INTEROP PPP test. I heard at first it would be restricted to "commercial implementations that would be available to end users by Oct. 1990", or words to that effect. That sort of requirement has a chilling effect on what is necessarily a low profit product. (How much would you pay for a PPP implementation? How many copies at that price would be required for my employer to recover my time to port or implement it and to pay for stocking, distributing, and advertising it? How many copies would be required to recover the INTEROP fees to participate in the demo?) By the end of the 2nd FDDI Hot Staging, I was told the rules were much looser. Perhaps I just misunderstood at first. Trade show "interoperability tests" don't measure what you may think they measure. They do not ensure that two random companies' products will work usefully together in your network. Instead they show that the vendor representatives can avoid killing each other and the show management during the hot stagings and that things can be made to look good during the show. They are marketing events. (I have been involved with INTEROP demos for two years. I cannot answer any questions about what I may have observed at any booth other than my employer's, and so can say nothing about observed interopability or problems.) Vernon Schryver, vjs@sgi.com
john@loverso.leom.ma.us (John Robert LoVerso) (01/17/91)
In article <1991Jan14.082326@max4.llnl.gov> scooper@aracmax1.llnl.gov writes: > At Interop '90 there was a small "Solutions Showcase (tm) Demonstration" > on PPP. [...] and Telebit, INTERACTIVE, and Xylogics communicating > at 9.6K and 19.2K bps asynchronous. This is slightly incorrect; Xylogics pulled out and did not show PPP on the Annex. The glossies were already printed, however. In the same way, I believe FTP was a late addition and did have PPP running over PC/TCP. Finally, there were several interoperability problems between vendors. ../John [formerly of Xylogics] -- John Robert LoVerso, Concurrent Computer Corp, loverso@westford.ccur.com [to reach me, not the corporate puppet: john@loverso.leom.ma.us]