lrb@alex.ctrg.rri.uwo.ca (3787 x4108) (01/09/91)
RCS and i have been working on this, but we/I are/am getting nowhere fast.
I have to use uucp between my 822S and a sun 200miles away to move secure
large datafiles. telebit trailblazers are good, but the phone company is
idiosycratic enough to cause regular glitches and resends.
MOST (read sun) hdb implementations allow a TCP dataline to be specified in
the Systems file which lets you IP over to the other machine and move
files verrrrry quickly. HP's uucp does not yet support this.
I have tried a number of approaches, usually a variation on punting out a
serial line that either loops back into the HP (and performing an rlogin
over to the host) or connecting a serial port to my IP server and then defining
that IPserver port as a 'direct' connexion to the remote host.
In all cases, the sessions hang just after the initial 'H' message is sent
from the master node.
ie:
Proto started f
****Top**** - role=1, setline - X
wmesg 'H'
rmesg - 'H' got FAIL
the g protocol also dies at that point, sending 10 alarms first.
If anyone can help, i'd appreciate it.
--
Lance R. Bailey Systems Manager box: Robarts Research Institute
email: lrb@rri.uwo.ca Clinical Trials Resources Group
fax: 519.663.3789 P.O. Box 5015, 100 Perth Dr.
vox: 519.663.3787 ext. 4108 London, Canada N6A 5K8wehr@fmeed1.UUCP (Bruce Wehr) (01/15/91)
In article <2004@ria.ccs.uwo.ca>, lrb@alex.ctrg.rri.uwo.ca (3787 x4108) writes: > MOST (read sun) hdb implementations allow a TCP dataline to be specified in > the Systems file which lets you IP over to the other machine and move > files verrrrry quickly. HP's uucp does not yet support this. Very true. But I have source to a uucpd server that I got from a friend. This will allow the *other* machine (read sun) to initiate the connection. Your HP can't initiate a UUCP session over TCP/IP, but it can service one coming in with this. > I have tried a number of approaches, usually a variation on punting out a > serial line that either loops back into the HP I was working on a "ptypipe" program that essentially does just this, but using pseudo-terminals. You don't waste real hardware that way. But, I got the same hanging problem you describe. I haven't had time to track the problem any closer (new assignment, et al). I would love to hear any suggestions on this one, too. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...uunet!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Engineering Technology Services P.O. Box 2053, Room 1153, Dearborn, Michigan 48121-2053 (313)337-5304
ted@gouldnl.encore.nl (Ted Lindgreen) (01/18/91)
In <9335@fmeed1.UUCP> wehr@fmeed1.UUCP (Bruce Wehr) writes: >Very true. But I have source to a uucpd server that I got from a >friend. This will allow the *other* machine (read sun) to initiate the >connection. Your HP can't initiate a UUCP session over TCP/IP, but it >can service one coming in with this. We have tried this approach on the NLnet backbone machine (hp4nl) running HP-UX 7.0. However, there remain 2 problems with it: 1. The t-protocol, which is the best one to use for UUCP over TCP/IP (and is specially designed for that) is not supported by the Hp UUCP implementation. 2. The f-protocol (meant for UUCP over X.25), which is chosen in some cases as second best, contains a very old bug (it does not check whether stdin is a tty, before doing an ioctl in the routine fturnon in fio.c, as is done everywhere else in the code). This bug causes uucico to abort with: "ASSERT STTY FAILED". With Sun's on the other side it works (Sun choses the g-proto, not very efficient though, to say it mildly). With many other UUCP implementation one runs into problem 2). We had the choice of running our own UUCP version or to get rid of the UUCP over TCP/IP connnection with non-Sun's. We did the former previously, but resorted to the latter later. However, I must say that we never could have done that without the friendly cooperation of the EUnet backbone (mcsun), who took over our UUCP over TCP connections. Regards, -- Ted. -- | Ted Lindgreen ted@encore.nl | | Encore Unix Centre Europe ...!mcsun!hp4nl!encore.nl!ted | | Maarssenbroek, The Netherlands (USA) tlindgreen@encore.com |