philb@versyss.uucp (Phil Burtis) (06/07/91)
We are running SVR3.2 ATT Unix. We have Interlan boards and software. We run TCP-IP (mostly telnet, ftp) and also do some RFS over the net. Would like to be able to have uucp go over the net as well. We've been told we need a uucp daemon (uucpd?) and we don't know where to get it. Interlan doesn't supply it, and ATT doesn't either. Suggestions? Thanks in advance for your time and reply.
johnk@gordian.com (John Kalucki) (06/08/91)
In article <1991Jun6.185715.16350@versyss.uucp>, philb@versyss.uucp (Phil Burtis) writes: |> We are running SVR3.2 ATT Unix. We have Interlan boards |> and software. We run TCP-IP (mostly telnet, ftp) and also |> do some RFS over the net. Would like to be able to have |> uucp go over the net as well. We've been told we need |> a uucp daemon (uucpd?) and we don't know where to get it. |> Interlan doesn't supply it, and ATT doesn't either. |> Suggestions? Thanks in advance for your time and reply. Uucp doesn't need a daemon. uucico is started by /bin/login when the calling system logs into the target machine. uucico is also started on the outgoing side periodically (indirectly) cron. -John Kalucki
davecb@nexus.yorku.ca (David Collier-Brown) (06/09/91)
In article <1991Jun6.185715.16350@versyss.uucp>, philb@versyss.uucp (Phil Burtis) writes: | We are running SVR3.2 ATT Unix. We have Interlan boards | and software. We run TCP-IP (mostly telnet, ftp) and also | do some RFS over the net. Would like to be able to have | uucp go over the net as well. We've been told we need | a uucp daemon (uucpd?) and we don't know where to get it. | Interlan doesn't supply it, and ATT doesn't either. | Suggestions? Thanks in advance for your time and reply. Well, some peope don't know about it, but there really is a uucpd, which negotiates a uucp channel over tcp/ip. If this is what you want, it's from Berkeley 4.x for BSD-derived systems, and presumably is part of HoneyDanBer UUCP from AT&T... I have HDB with a uucpd on my Sun. --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | Today's featured dish: CANADA. 416-223-8968 | Sun-dried alligator.
rickert@mp.cs.niu.edu (Neil Rickert) (06/09/91)
In article <1991Jun9.005932.17584@newshub.ccs.yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes: > Well, some peope don't know about it, but there really is a uucpd, >which negotiates a uucp channel over tcp/ip. > If this is what you want, it's from Berkeley 4.x for BSD-derived systems, >and presumably is part of HoneyDanBer UUCP from AT&T... I have HDB with >a uucpd on my Sun. Unfortunately for those whose UUCP comes without uucpd, you probably can't use versions which might be publicly available. Using uucpd you will run into trouble right about the time uucico tries to change the terminal characteristics to raw mode. You need a uucico which is built to first check if its stdin/stdout is a socket. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
chip@chinacat.unicom.com (Chip Rosenthal) (06/10/91)
In article <1991Jun9.030935.27196@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >Using uucpd you will run into trouble right about the time uucico tries to >change the terminal characteristics to raw mode. You need a uucico which >is built to first check if its stdin/stdout is a socket. Or my `uucpm' daemon which sits on the other side of a pty from uucico. I announced availability of a test version last week over in comp.unix.sysv386, and sent out copies last weekend. It was written for and tested under SCO UNIX and XENIX, but it sounds like some folks plan to try it in other environments. I'd be glad to send out copies. There has been enough interest that I will probably post it to the net after a shakedown period. -- Chip Rosenthal <chip@chinacat.Unicom.COM> | Don't play that Unicom Systems Development 512-482-8260 | loud, Mr. Collins.
guy@auspex.auspex.com (Guy Harris) (06/11/91)
> If this is what you want, it's from Berkeley 4.x for BSD-derived systems, >and presumably is part of HoneyDanBer UUCP from AT&T... I have HDB with >a uucpd on my Sun. The Sun version of "uucpd" came from 4.xBSD, not from AT&T. The HDB in SunOS 4.1 has a lot of stuff from the H of HDB in it; its support for UUCP-over-TCP is among that stuff (as is support for the "max grade" stuff).
guy@auspex.auspex.com (Guy Harris) (06/11/91)
>Uucp doesn't need a daemon. uucico is started by /bin/login when the >calling system logs into the target machine. Well, that's *one* way "uucico" can get started; however, it's not the *only* way. The 4.xBSD UUCP-over-TCP mechanism doesn't involve a normal login from the calling system to the target machine; instead, the calling "uucico" makes a TCP connection to some particular TCP port on the remote machine (normally port 540), which connects it to the UUCP daemon on the target machine. The UUCP daemon prompts for a login name, reads that, prompts for a password, reads that, and does the same checks that "login" does (it originally didn't do so; that was added later), and then directly runs "uucico". The two UUCPs then communicate using a protocol such as the "t" protocol, running on top of TCP, rather than the "g" protocol used over asynchronous serial lines (although you can run UUCP-over-TCP on a connection that passes over an asynchronous serial line using SLIP or PPP, of course...). Now, as the person who asked the original question is running SVR3.2, the above doesn't necessarily apply. S5R3.2's UUCP has its *own* way of doing UUCP over various transport layers; it uses TLI, which achieves its goal of transport independence, in part, by not supporting any form of host-name-to-address translation, and requires you, from what I've seen, to put long strings of hex digits representing a transport-level address into the Systems file. (S5R4, with the aid of run-time dynamic linking, actually admits host+service-to-address translation into the Wonderful World of TLI; whether its UUCP makes use of that, or still requires hex digits in the Systems file, I don't know.) That address is the address of the "listener" process on the remote machine, which is a somewhat bizarre sort of network daemon that requires those who want to connect to it to send an identifier for the service to which they want to connect as *data* over the connection, rather than letting you simply say "this transport address belongs to this service" - or, at least, it did so in the S5R3's I've seen; perhaps they've replaced it with something rational (or, at least, capable of supporting normal Internet-style services) in S5R3.2. The "listener" would occupy the same niche in that scheme of UUCP-over-TCP as "uucpd" does in a BSDish scheme. There may well be documentation somewhere in the S5R3.2 documentation set on how to set that up, unpleasant long strings of hex digits and all....
chip@chinacat.unicom.com (Chip Rosenthal) (06/12/91)
In article <1991Jun10.154542.2992@chinacat.unicom.com> I wrote: >In article <1991Jun9.030935.27196@mp.cs.niu.edu> > rickert@mp.cs.niu.edu (Neil Rickert) writes: >>You need a uucico which is built to first check if >>its stdin/stdout is a socket. > >Or my `uucpm' daemon which sits on the other side of a pty from uucico. Due to the number of requests, I just posted this to alt.sources. -- Chip Rosenthal <chip@chinacat.Unicom.COM> | Don't play that Unicom Systems Development 512-482-8260 | loud, Mr. Collins.
eps@TOASTER.SFSU.EDU (Eric P. Scott) (06/12/91)
In article <8295@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Now, as the person who asked the original question is running SVR3.2, >the above doesn't necessarily apply. S5R3.2's UUCP has its *own* way of ^^^^^^^^^^^ >doing UUCP over various transport layers; it uses TLI That's only one of the options. There are several others in the source code, including a BSD 4.2-style sockets implementation that does a getservbyname("uucp", "tcp"). It all depends on what's #defined in parms.h at compile time. Will it interoperate with BSD uucpd? Not out of the box. For one, AT&T's code uses 'e' protocol rather than 't' protocol over TCP connections. -=EPS=-
sl@wimsey.bc.ca (Stuart Lynne) (06/12/91)
In article <1991Jun11.183342.23051@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes: >In article <1991Jun10.154542.2992@chinacat.unicom.com> I wrote: >>In article <1991Jun9.030935.27196@mp.cs.niu.edu> >> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>>You need a uucico which is built to first check if >>>its stdin/stdout is a socket. >> >>Or my `uucpm' daemon which sits on the other side of a pty from uucico. > >Due to the number of requests, I just posted this to alt.sources. I've tried this and it works quite well on SCO UNIX and SCO XENIX. I'm now feeding someone a news feed over a double PPP link. Looks something like: SCO UNIX <-> router <-> router <-> router <-> SCO XENIX ^ ^ | | PPP PPP The outside lines are ethernet. The inside two links are PPP running over a V.32bis /V.42bis and V.32 connection respectively. The problem now is that with SCO's uucico you can only use the "g" packet level protocol. This is blessed with small packets (64 bytes data) and a small window size (3, can be adb'd up to 7). The end result is truly amazing throughput :-) About 102 cps with windowsize of 3 and 170 with windowsize 7. Anyone feel like building uucp spoofing into uucpm and uucpd :-) (aka Trailblazer uucp spoofing). I also heard a rumour that a uucp replacement was announced at a Dallas BOF, any details? A replacement uucico would certainly do the trick. Anyway we now get to knock SCO (and other 386 vendors) for not including a uucp daemon when we can see how easy it is to implement AND for being so totally short sighted that they didn't include any protocols other than the standard "g" protocol. It's one thing to not port something (like uucp[md]) but presumably they actually had to turn off linking in the alternate protocols. I dream of a day when van-bc has all the networking facilities available on a Sun. Maybe I should start looking for a Sparc Clone. Might be the only way to get proper networking. I sometimes wonder if the Intel UNIX market will survive the attack of the Killer Micros (as embodied by various RISC UNIX systems). -- Stuart Lynne Computer Signal Corporation, Canada ...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca
lcuff@spectrum.CMC.COM (Leonard Cuff) (06/13/91)
In article <8295@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >S5R3.2's UUCP has its *own* way of doing UUCP over various transport layers; >it uses TLI. <lengthy (correct) background deleted> >The "listener" would occupy the same niche in that scheme of >UUCP-over-TCP as "uucpd" does in a BSDish scheme. There may well be >documentation somewhere in the S5R3.2 documentation set on how to set >that up, unpleasant long strings of hex digits and all.... There is indeed documentation: The manual I'm looking at has a title "AT&T Enhanced TCP/IP WIN/3B Release 3.0 Installation and Administration Guide for the AT&T 3B2 Computers" and it has a section "Setting up TCP/IP for WIN/3B for UUCP" that describes exactly this procedure. Those long hex strings are ugly, but a program "rfsaddr" is supplied to take a host name and shove the "0x00020401" onto the front of your host name's IP address thus eliminating a bit of typing. AT&T chose port number 1025 (0x401) for their network listener service, but RFC 1060 (Assigned numbers) lists port 1025 as "blackjack". Can anybody explain this? Is blackjack an alias for AT&T? 1/2 :-) -- Leonard Cuff lcuff@cmc.com
mah@wu-wien.ac.at (Michael Haberler) (06/14/91)
In article <1991Jun12.075244.26984@wimsey.bc.ca>, sl@wimsey.bc.ca (Stuart Lynne) writes: |> In article <1991Jun11.183342.23051@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes: |> >In article <1991Jun10.154542.2992@chinacat.unicom.com> I wrote: |> >>In article <1991Jun9.030935.27196@mp.cs.niu.edu> |> >> rickert@mp.cs.niu.edu (Neil Rickert) writes: |> >>>You need a uucico which is built to first check if |> >>>its stdin/stdout is a socket. | |> The problem now is that with SCO's uucico you can only use the "g" packet level |> protocol. This is blessed with small packets (64 bytes data) and a small window size |> (3, can be adb'd up to 7). The end result is truly amazing throughput :-) About 102 |> cps with windowsize of 3 and 170 with windowsize 7. Some uucico's can use the 'f' protocol which is a royal cludge for X25 PAD connections, and in use on quites some sites on this side of the pond. 'f' Protocol means: Escape all characters below space or above 127, append a checksum, and do flow control via XON/XOFF. Ack's are only sent after a whole file is done. Now if you could coerce uucico running the 'f' proto over a TCP socket, througput should be much better. Unfortunately, few manufacturers have picked it up (HP for sure, dont know about others). Definitely not the PC unix crowd. |> I dream of a day when van-bc has all the networking facilities available on a Sun. I just inquired ATT Unix Europe for BNU source alone, to do such things. They wont sell it without SystemV R4 attached to it, and at $100.000.- thats beyond scope for the application in question. Seems like they are dedicated to kill uucp. -michael -- Michael Haberler mah@wu-wien.ac.at, mah@awiwuw11.bitnet University of Economics and Business Administration A-1090 Vienna, Augasse 2-6 Biz: +43 (1) 31336 x4796 Fax: 347-555 Home: +43 (1) 961-679 (voice & fax) D-Netz: +43 (663) 811-056
chip@chinacat.unicom.com (Chip Rosenthal) (06/15/91)
In article <1991Jun14.105800.28984@swdsrv.edvz.univie.ac.at> mah@wu-wien.ac.at writes: >Now if you could coerce uucico running the 'f' proto over a TCP socket, >througput should be much better. Unfortunately, few manufacturers have >picked it up (HP for sure, dont know about others). Definitely not the >PC unix crowd. SCO has `g' and nothing else. Interactive has `g' and `e'. One person mentioned they moved a copy of uucico from their ISC to SCO machine to eek out some better TCP/IP performance, and it worked. (This was done using the `uucpm' daemon - not the builtin TLI stuff ISC provides.) >I just inquired ATT Unix Europe for BNU source alone, to do such things. >They wont sell it without SystemV R4 attached to it, and at $100.000.- >thats beyond scope for the application in question. Seems like they are >dedicated to kill uucp. AT&T has done a fine job of driving a stake through the heart of any troff future with their DWB3.1 pricing strategy. Maybe the same folks are responsible for the BNU marketing. -- Chip Rosenthal <chip@chinacat.Unicom.COM> | Don't play that Unicom Systems Development 512-482-8260 | loud, Mr. Collins.
darnold@felix.UUCP (Dave Arnold) (06/20/91)
In article <9106120113.AA16777@toaster.SFSU.EDU> eps@cs.SFSU.EDU writes: >Will it interoperate with BSD uucpd? Not out of the box. For >one, AT&T's code uses 'e' protocol rather than 't' protocol over >TCP connections. > > -=EPS=- But, what's to stop me from running 'g' over TCP connections?