ken@argus.UUCP (Kenneth Ng) (10/17/86)
In article <44700004@cdp>, scott@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? -- Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** WARNING: NOT ken@bellcore.uucp *** !psuvax1!cmcl2!ciap!andromeda!argus!ken bitnet(prefered) ken@orion.bitnet McCoy: "This won't hurt a bit" Chekov: "That's what you said last time" McCoy: "Did it?" Chekov: "Yes"
simon@einode.UUCP (Simon Kenyon) (10/21/86)
>> 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. > > 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? the version of uucp running in the uk has been extensively hacked to work over 7bit data paths. it's basically a 4.2 uucp with mucho changes. it is not, repeat not the same as the european uucp, which gave the world the f protocol (see 4.3 uucp). the f protocol will not work over a lot of x.25 connections (little gripe) -- Simon Kenyon EUnet: simon@einode.UUCP Smail: The National Software Centre, Dublin, IRELAND Phone: +353-1-716255 EUnet is a registered trademark of the EUUG
jim@cs.strath.ac.uk (Jim Reid) (10/21/86)
In article <532@argus.UUCP> ken@argus.UUCP (Kenneth Ng) writes: >In article <44700004@cdp>, scott@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. > >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? UKUUCP (essentially a much hacked Honey Danber UUCP) runs over X.25 OK. It has been made to use a 7 bit data transfer and should be quite portable. I know it works on BSD VAXes and 64Kbyte PDP 11's and should go on Sys V too. Jim ARPA: jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"
simon@einode.UUCP (Simon Kenyon) (10/22/86)
> UKUUCP (essentially a much hacked Honey Danber UUCP) runs over X.25 OK.
WRONG! UKUUCP is a much hacked 4.2 uucp
--
Simon Kenyon
EUnet: simon@einode.UUCP
Smail: The National Software Centre, Dublin, IRELAND
Phone: +353-1-716255
EUnet is a registered trademark of the EUUGclewis@spectrix.UUCP (10/24/86)
In article <532@argus.UUCP> ken@argus.UUCP (Kenneth Ng) writes: >In article <44700004@cdp>, scott@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
hmm@exunido.UUCP (10/31/86)
Incorporating the f-protocol into other uucp's is fairly simple,
I have done this once for xenix uucp in 2 days. Doing the PAD dialling
is a bit more work, but it's possible, too. One hint: If your PAD
allows to set the remote parameters on incoming calls, use this feature !
It saves you a lot of hassle with callers who don't know how to set their
PAD parameters correctly. The MICOM PAD, which we use here at unido
supports this, for example (I guess others have similar facilities).
Hans-Martin Mosner
postmaster@{unido.uucp,unido.bitnet}clewis@spectrix.UUCP (Chris Lewis) (11/13/86)
In article <31800003@exunido.UUCP> hmm@exunido.UUCP writes: >Incorporating the f-protocol into other uucp's is fairly simple, >I have done this once for xenix uucp in 2 days. Doing the PAD dialling >is a bit more work, but it's possible, too. One hint: If your PAD >allows to set the remote parameters on incoming calls, use this feature ! >It saves you a lot of hassle with callers who don't know how to set their >PAD parameters correctly. The MICOM PAD, which we use here at unido >supports this, for example (I guess others have similar facilities). The above works fine, provided that your site is receiving X.25 connects only. I've written a full-blown dialer that works with MICOM and Motorola PADS. It works very similarly to normal ACU's - eg: "phone numbers" in L.sys and L-dialcodes along with "chat scripts" (which you'd probably have to tear out of for non-4.3 BSD UUCP). It may have made it to Rick Adams in time for 4.3 BSD UUCP, but I'm not sure. The dialer allows the SA to set up the PAD channel for "cu"-out type usage. When the dialer starts, it sets all of the parameters to the right values, then dials the number given in the L.sys/L-device phone number locations. Contact me if you want a copy... -- Chris Lewis Spectrix Microsystems Inc, UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis ARPA: mnetor!spectrix!clewis@seismo.css.gov Phone: (416)-474-1955