Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!pyramid!csg From: csg@pyramid.UUCP Newsgroups: comp.unix.wizards Subject: Re: UUCP 'f' (X.25) protocol questions Message-ID: <2409@pyramid.UUCP> Date: Sat, 16-May-87 14:51:09 EDT Article-I.D.: pyramid.2409 Posted: Sat May 16 14:51:09 1987 Date-Received: Sun, 17-May-87 02:47:29 EDT References: <52@sdeggo.UUCP> Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 41 Keywords: uucp x.25 In article <52@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >I've got a SysV.2 system and there is an X.25 protocol documented in the >manual. However, it says that there are no settings for baud rate with this. True, if you're on an AT&T or DEC system using an internal PAD. It's a board in the bus, and baud is pretty meaningless in that context. And while you do have a synchronous serial link from the board to your PDN modem, that speed is part of the system configuration, and not under user control. >In my experience with X.25 I've had external PADs hooked up to serial ports. Like Dynapac, Micom, and others? Depending on your implementation, SVR2 UUCP will run X.25 on those, too, as will the BNU (HoneyDanBer) UUCP from SVR2.0.4 and SVR3. I wouldn't advise this, though, for the reasons below. (Binary sites should note, too, that AT&T no longer is shipping BNU with the X.25 support enabled. You have to have source, and recompile.) >Is this protocol compatible with the 'f' protocol documented in the BSD 4.3 >UUCP manual? No. The 'f'-protocol uses a 7-bit-printable-ASCII encoding (suitable for the bizarre international gateways) and carries a checksum accross the entire file for error detection. AT&T SVR2 and BNU use the 'x'-protocol, which requires total 8-bit transparency and provides no error detection whatsoever. Neither uses packetizing, and both depend on the underlying hardware for flow control and catastrophic failure detection (like a down line). I would discourage the use of the 'x'-protocol for anything other the domestic links using an internal PAD, where the error rate between the PAD and the UUCP software is likely to be very low (and error corrected by hardware). External PADs will introduce flow control problems (you can't use XON/XOFF), and you'll never know if an error occurs. You can use good ol' 'g'-protocol through an external PAD on domestic X.25 links, although it will nearly quadruple your packet charges. If you are not paying by the kilosegment, then this won't matter much. Note that the 'f'-protocol source is publically available from mod.sources archive sites. The 'x'-protocol is proprietary to AT&T.