jbvb@VAX.FTP.COM (James Van Bokkelen) (03/15/89)
Date: Mon, 13 Mar 89 19:36:09 EST From: Russ Nelson <nelson@sun.soe.clarkson.edu> Reply-To: nelson@clutx.clarkson.edu James-- Should the application or the packet driver perform the SLIP encoding? Also, how do you handle the problem of establishing the serial line connection in the first place? I am thinking that a special pair of functions for SLIP drivers would be useful for talking to the modem -- send single character and receive single character. Then, a special 'dial' program could talk to the modem and establish the connection. -russ This seems right to me, but I am going to post it to PCIP and see if anyone finds gross holes in my reasoning. This approach does imply on-the-fly compression of SLIP_ESC, which is easy to do on char-at-a-time ports. Anyone using DMA on asynch? --------------------------------------------------------------------------- I think that the SLIP framing and byte-stuffing can be viewed as functionally identical to the Ethernet preamble and CRC, which are done in the MAC layer. Thus, on send_packet() the SLIP driver should get passed an array of bytes, sans byte-stuffing or SLIP_END characters, and the access_type() upcall should get passed the same thing. When PPP finally standardizes a protocol type (and maybe LAPB addresses, powers that be spare me), then this will be generated by the application, and passed to the upcall, but the packet driver (or the hardware) will do the checksum/CRC and the byte/bit stuffing necessary for transmission. Regarding dialing, would an establish_connection()/terminate_connection() be enough more general to make it worthwhile to add? It could take a fairly large array as an argument, to be interpreted in a way that depended on the MAC layer in use. I don't know enough about X.25 to know if this is enough for that kind of connection-oriented environment, or not. Comments? jbvb
nelson@SUN.SOE.CLARKSON.EDU (Russ Nelson) (03/16/89)
Regarding dialing, would an establish_connection()/terminate_connection() be enough more general to make it worthwhile to add? It could take a fairly large array as an argument, to be interpreted in a way that depended on the MAC layer in use. I don't know enough about X.25 to know if this is enough for that kind of connection-oriented environment, or not. I fear that that would not suffice if interaction was required to set up the SLIP link. Can we hear from someone at umich or ucdavis? I am pretty sure that they both support SLIP dialins. What might be workable for SLIP at least is to specify the string in a method similar to UUCP's sys line (send this, wait for this, send this, wait for this, etc.) --russ (nelson@clutx [.bitnet | .clarkson.edu]) If you can, help others. If you can't, at least don't hurt others--the Dalai Lama
emv@math.lsa.umich.edu (Edward Vielmetti) (03/17/89)
In article <8903160327.AA01938@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes: > > Regarding dialing, would an establish_connection()/terminate_connection() be > enough more general to make it worthwhile to add? It could take a fairly >I fear that that would not suffice if interaction was required to set up the >SLIP link. Can we hear from someone at umich or ucdavis? I am pretty sure >that they both support SLIP dialins. umich (actually Merit) supports SLFP, not SLIP. The KA9Q changes here only add space for a simple number to dial, not an elaborate expend-sequence that devotes of uucp have learned to love. I don't have any ready access to dialing code that isn't entangled in an AT&T copyright, but you might send mail to hokey@plus5.com and see what he has. --Ed
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (03/17/89)
There was a nice state driven dial() routine posted to usenet a while back. I think it's much better than uucp type scripts. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff