Need help with UUCP over X.25

[clewis at spectrix.UUCP]

In article <532 at argus.UUCP> ken at argus.UUCP (Kenneth Ng) writes:
>In article <44700004 at cdp>, scott at 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.  Any pointers on
>> running UUCP over Telenet would be appreciated.
>> 
>> -scott
>> 415-322-9060
>> {ihnp4,...}!hplabs!cdp!scott
>
>If you get this to work I'd be interested.  About a year ago this
>site tried to get uucp to work over a couple Dynapac X.25 pads.
>It never worked.  Apparently the problem is that uucp does not
>have an option to use only 7 bit data transfer.  It seems that
>all the options uucp has are variations of the same single option.
>By the way, I never found documentation that says that uucp needs
>8 bit transfer, the local Unix guru swears that uucp works 7 bit
>however.  Can anyone confirm or deny this?

Back in my cX days, we did get SVR2 and BSD4.2 UUCP standard protocol
"g" talking over Motorola/MICOM PADS.  Basically, you have to dedicate 
an "outgoing" PAD line/tty and/or "incoming" PAD line/ttys.  Then,
you have to set quite a few parameters on these lines in the PAD.
I can't remember all of the details, but these are a few that I remember:

	1) 8-bit data path
	2) packet timeout (we used the minimum - 50 ms. I think)
	3) Turn off *ALL* special characters - especially ^P.
	4) packet size shouldn't matter much.

You should be able to put the parameter settings plus the "conn" sequences
into the L.sys file.  Once this is done, normal "g" protocol will work, but
VERY slowly.  Eg: on 9600 baud lines all of the way through the network, we
were acheiving effective baud rates of about 600 to 1200.  Eg: takes
64 Ms. to place the packet in the PAD, 50 Ms. later it times out and sends
the packet, then the other side writes the acknowledge into the remote PAD, 
and the remote PAD waits another 50 ms. before sending it back.  Approx
3:1 time expansion.  Further, you might have problems trying to hang up 
the connection.  Further, since you are always sending short packets (most
of them only a few bytes), it'll cost a lot if your network is charging
"per-packet" (ala DATAPAC).

YECH!

Yes, "g" protocol *DOES* use 8 bit data transmission.

After we got this to work, I started thinking about writing a new protocol,
when, miracle of miracles, we managed to get a copy of alpha 4.3 UUCP.  It has
protocol "f" which is designed for X.25 PADS.  We acheived thruput in excess
of 5600 baud.  Protocol "f" is rather simple minded:

    1) Most non-printing characters (ASCII and 8th bit on chars) are converted
       into two characters.
    2) The whole file is blasted out on the line without any packetization.
    3) The only acknowledge is a checksum exchange after the file has been
       transmitted.
    4) X-ON/X-OFF better work well between your computer and the PAD - if
       you drop characters, UUCP only notices it at the end of the transmission
       and simply retransmits the whole file again.  Can be very expensive with
       big files.

I've written a "proper" "PAD" dialer (as opposed to ACU or DIR) for protocol 
"f" and sent it off to Rick Adams - however, it was probably too late for 
inclusion in the "official" 4.3 release.  This dialer does all of the 
PAD parameter settings itself, so that it is no longer necessary to 
dedicate PAD lines.  If you already have 4.3 UUCP, you'll already have 
the "f" protocol itself.  If you have 4.3 UUCP and you're interested 
in the dialer, contact me for a copy of it.  However, because of rather 
extensive internal differences between 4.3 UUCP and it's predecessors, 
I am unable to help people add proto "f" into non-4.3 UUCP's.

Protocol "f" and the dialer work quite well - mnetor (my previous home)
has taken over almost all of utzoo's long haul incoming news feed - getting
it from seismo.
-- 
Chris Lewis
UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis
Phone: (416)-474-1955