lmc@denelcor.UUCP (Lyle McElhaney) (02/17/84)
In a similar vein to the article about 4.2 uucp timing out, we seem to have a similar (same?) problem under 4.2. We are transmitting between a VAX 750 running 4.2 and an 11/44 running System 3. The medium is a 9600 baud link managed over Interlan NTS10 Ethernet terminal servers. I have managed to get the two systems to call each other over the Interlan but generally everything dies in mid-conversation. The Master uucp (running -x4 debug) complains about alarm1-5, and quits. The Interlan interface uses xon/xoff flow control to keep its buffers manageable. Could this be a problem? Can uucp handle the flow control, or is it all transparent and handled in the tty handler? Its just an idea. Anyway, I would appreciate any help anyone can offer with this problem. By the way, is there any problem moving the 4.2 uucp over to the System 3 system on the '44? Has anyone done it? Thanks for your advice and assistance. -- Lyle McElhaney (hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc
dmmartindale@watcgl.UUCP (Dave Martindale) (02/18/84)
Uucico needs an absolutely transparent 8-bit data path from one host to the other. Anything sitting in between which modifies the data stream in anyway (such as generating or responding specially to XON/XOFF will break it. The best fix is to build a special protocol, to be used instead of the default 'g' protocol, which takes care not to transmit XON or XOFF by changing them into a 2-char escape sequence instead. We've been running such code for about 2 years to talk over a Sytek localnet and it seems to be fine.
mark@cbosgd.UUCP (Mark Horton) (02/18/84)
UUCP expects a fully transparent 8 bit data path. If the Interlan box is intercepting xon and xoff, it won't work. Also, if there are certain characters that will wake up the Interlan to allow local commands, you'll have the same problem. Sizes and sequence numbers are sent as binary numbers in the headers. UUCP does its own flow control, so as long as the baud rates are the same on both ends (or close enough that 2-3 64 byte packets can be buffered) there is no need for external flow control. This is true of all versions I know of. Mark
lmc@denelcor.UUCP (Lyle McElhaney) (02/20/84)
Thanks to the net (or a large part of it, anyway) for explaining that uucp operates in RAW mode and does its own flow control. The Interlan boxes are attempting to do flow control on their data sources to avoid buffer overrun, and the xon/xoffs added to the packets are driving uucp bonkers. Now, does anyone have a fix for this? I cannot eliminate flow control on NTS boxes, but I can tell them to do EIA flow control (with DSR rather than xon/xoff) and then ignore it. I presume that packets will then be corrupted by Interlan. Will uucp recover? What other possibilities are there? Thanks again, to all the big brothers out there. -- Lyle McElhaney (hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc
rpw3@fortune.UUCP (02/20/84)
#R:denelcor:-33400:fortune:2100001:000:702
fortune!rpw3 Feb 19 22:11:00 1984
I believe you can turn off the NTS-10 xon/xoff flow control with a status
setting command, but you will need to do it at BOTH ends. A somewhat
hacky way to do this is to have the out-dialing UUCP port be a "network
administrator" port, and exercise super-user priv's on the destination
port to turn off xon/xoff. (It will make your L.sys entry LLOOOONNNNGGGGG...)
Better is to just trust uucp's flow control (as Mark said), and set the
ports up that way permanently, and not to use those particular ports
for any non-uucp traffic.
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065