steve@umnd-cs.UUCP (03/26/87)
Is anyone out there successfully running uucp through dial in's
connected to a bridge cs/*?
The biggest problem we run into is that telnet on some machines
doesn't pass all 8-bits characters through, and uucp times out
waiting for them.
Has anyone come up with a reasonable workaround for this problem?
Backending the bridge into a serial port on our uucp machine isn't
an option for us.
An option I haven't tried is using an Encore annex to do the same
thing. The annex also uses the rlogin protocol which might help.
Does anyone have any good ideas as to what we might try to make
this work, or as to why it will never work?
Thanks,
Steve
--
Spoken: Steven M. Miller UUCP: umnd-cs!steve CSNET: steve@umn-duluth.csnet
ARPA: steve@cs-gw.d.umn.edu
USNail: Computer Science Dept, University of Minnesota at Duluth
10 University Drive, Duluth, MN 55812budd@bu-cs.UUCP (03/28/87)
Summary: Keywords: If you have 4.3 uucp (or 4.2 bsd with the 'f' protocol), you might try that. The 'f' (PAD) protocol assumes only 7 bit characters, flow control, and no control characters other than ^P and NUL. If ^P is a problem you can patch location Msync to contain some other character. The PAD protocol exists for connections on X.25 PAD lines that are "mostly" reliable and flow controlled. Checksumming is done on a per-file basis. The SYSVR2 'x' protocol does NOT appear to be compatible (does no checksumming?) rlogin will still have problems for normal uucp: some control characters are sent as out of band messages, and you cannot disable the attention (~) sequences. I have been experimenting with uucp over our Ungerman/Bass NET1 terminal network with the 'g' (standard uucp packet) protocol modified to quote all control and 8-bit characters. We have only one directly connected modem on bu-cs, but the terminal network has a bank of 97!!
guy@gorodish.UUCP (03/29/87)
>The PAD protocol exists for connections on X.25 PAD lines that are >"mostly" reliable and flow controlled. Checksumming is done on a >per-file basis. The SYSVR2 'x' protocol does NOT appear to be >compatible (does no checksumming?) They aren't *supposed* to be compatible. The 'f' protocol is for use over PADs; it assumes a 7-bit non-transparent data path, and does not assume that the link level is completely reliable. The 'x' protocol is for use over a more direct X.25 connection; it assumes an 8-bit transparent data path and *does* assume that the link level will do the checksumming and flow control. (Sort of like the 'e' or 't' protocols.)
csg@pyramid.UUCP (03/30/87)
In article <5817@bu-cs.BU.EDU> budd@bu-cs.UUCP (Philip Budne) writes: >The PAD ['f'] protocol exists for connections on X.25 PAD lines that are >"mostly" reliable and flow controlled. Checksumming is done on a per-file >basis. The SYSVR2 'x' protocol does NOT appear to be compatible.... Correct. 'x' does no error detection or correction of any kind, and it assumes a transparent 8-bit data path. This is true in both SVR2 VAX version and HDB. <csg>
sob@cortex.UUCP (04/07/87)
We use the 'f' protocol when possible with the Bridge equipment here. It
works well. 'g' is used when 'f' is not available with good results.
If you have sources, I can provide a "BRIDGE" dialer to allow the
computer to make the connections without having all the stuff in
the chat script.
We have our ports configured with 8bit words, 1 stop and no parity,
BREAK is set to return the user to command mode and the Escape
character is disabled. We also have flow control disabled. This
gives us good results.
Stan uucp:{shell,rice,seismo}!soma!sob Opinions expressed here
Olan domain:sob@rice.edu or sob@soma.bcm.tmc.edu are ONLY mine &
Barber CIS:71565,623 BBS:(713)790-9004 noone else's.