Xref: utzoo comp.protocols.iso:1249 comp.protocols.tcp-ip:13122 Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!mips!apple!voder!pyramid!csg From: csg@able.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: SLIP over X.25 Message-ID: <128067@pyramid.pyramid.com> Date: 24 Sep 90 06:51:46 GMT Sender: daemon@pyramid.pyramid.com Reply-To: csg@pyramid.com (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 41 >Have anybody tried this weird combination? Sure. To place the call, I modified the 4.3BSD slattach(8) utility to open up an X.25 device, perform call setup, condition the line for data only, and then change the line discipline to SLIPDISC. A similar trick could be done with a hardware PAD and a uucico-like dialer. To answer the call, I simply used the NASA Ames slipsh (SLIP Shell), and invoked it right out of /etc/passwd. The likely problems are: - If you are using a PAD, it will have to be able to go 8-bit transparent. In this case, it will also be imperitive that the answering side emit the right X.3 parameters before going to the SLIP discipline. This might happen auto- matically; or you might have to kludge something into slipsh. - If you are using a host-based interface, either a software PAD or a direct X.25 connection, it will have to have true line discipline support, and it will have to correctly set the PAD parameters when the line discipline is changed. Out of a dozen or so commercial UNIX X.25 implementations that I am aware of, only Pyramid and Sun do this correctly, although I'd bet that most of the university ones will, too. I'd guess that Sun's is hard on the machine because you have to wander in and out of the "if" layer twice; but I haven't tried it, so I don't really know. Performance between two Pyramids was very good, although I was using a 72Kbps link. :-) Over 9600bps, expect interactive response to be sluggish, certainly more so than over a direct wire or a modem. Some of this will depend on your ability to tune X.29 behavior, if applicable. (A good X.29 will try to bunch up characters into full packets.) We also have the Van Jacobson 4.3BSD-tahoe performance enhancements (as does Sun), which seem to make a big difference on SLIP. SLIP over X.25 is not anywhere as weird as it sounds. A proper IP over X.25 implementation (like SNDCF) is a nasty and complex beast. SLIP over X.25 is a cheap and easy way to get point-to-point IP over X.25, with only slightly higher overhead. SLIP/X.25 can even run over a PAD, which SNDCF cannot. The big disadvantage, of course, is that SLIP/X.25 *is* point-to-point, just like regular SLIP; you have to place a call and keep it there for every X.25 address to which you are likely to connect.