scott@cdp.UUCP (10/14/86)
I would like to talk to someone who has an X.25 connection to
Telenet, runs SysVr2 vanilla UUCP or something close, and has
people call them via Telenet to run UUCP. Any pointers on
running UUCP over Telenet would be appreciated.
-scott
415-322-9060
{ihnp4,...}!hplabs!cdp!scottcsg@pyramid.UUCP (Carl S. Gutekunst) (10/15/86)
In article <2600002@cdp> scott@cdp.UUCP writes: >I would like to talk to someone who has an X.25 connection to >Telenet, runs SysVr2 vanilla UUCP or something close, and has >people call them via Telenet to run UUCP. The answer is of general interest, which is why I'm posting. Good luck. Few UNIX sites have UUCP Telenet connections, and none I'm aware of use AT&T's 'x' protocol. (Having said that, I expect at least a dozen AT&T sites are going to jump down my throat. :-)) Most are using the 'f' protocol of 4.3BSD, and they are not compatible. The code for the 'f' protocol is in the public domain (right, Piet?), so you may be able to hack it in if you have source and a lot of time. There are other issues: Both SVR2 and 4.3BSD UUCP want a tty line (well, a character device anyway) that uucico can simply open, set the baud and a few other modes, and go. This is true for "external" PADs, that is, a black box external to your system that connects to your Telenet modem on one side and provides 1 to 8 RS-232 serial ports on the other. This is what most sites use for PAD access, since it's the simplest (if not the cheapest). If you have an internal PAD (a board inside your machine) or a general purpose X.25 interface (like you need for CSNet or X.25 DDN), you may have a problem. If you have to connect to a device that doesn't behave like a tty (different ioctls, or packetizing) or you have to tie into to a PAD utility using pipes, you have a lot of code hacking ahead of you. Neither 'x' nor 'f' protocol works well over a dialup PAD. That's where you call Telenet's local number and connect to a modem that's wired to an external PAD. The problem is the intervening telephone link: it's not error free. So you need an error-correcting protocol like good old 'g'. But 'g' protocol's teensy packet size will eat you alive on packet charges, and the thoughput will be terrible. You will also have to play some games in your L.sys file (or chat script in L-devices, if you have it). A normal X.28 PAD has something like 30 different control parameters, most of which default wrong for uucico. In particular, uucico uses CTRL-P as a sync character *before* it has selected a protocol to use. But CNRL-P is also the command escape character for the PAD. So you have to use your expect/send script to send the correct parameter command to the PAD to disable the escape character. Note that many of these problems don't apply when someone else calls you. Most of the issues with modes, devices, and PAD parameters only concern the calling system. If it's possible to connect to your machine from anywhere on Telenet and get a 'login:' prompt, and you're both using the same incarnation of UUCP (System VR2 vs. 4.3BSD), then it's probable that someone else can call you. We do run 4.3BSD UUCP on our Telenet connection, using Pyramid's general- purpose X.25 interface. (Calling in worked fine right off; for calling out I hacked a version of uucico that connects to our PAD utility using the Berkeley socketpair() system call.) Unfortunately we haven't been able to find much of anyone to talk to. I've been considering trying SVR2 on the PAD (Pyramid runs a dual port System V and BSD), although we could not call out with it unless I hack it up a lot. (It would be cheating to use socketpair() in an AT&T utility.) Easier to add the 'x' protocol to BSD UUCP, or wait until we have streams running and use HoneyDanBer calling TLI, and push in streams modules for the 'x' or 'f' protocols. Some day.... I've also heard gripes from other Telenet users that Telenet is unreliable compared to Tymnet or the now defunct Uninet. I've never had any problems, though. Throughput does vary tremendously, I assume based on the overall load on the network. <csg>