pst@comdesign.cdi.com (Paul Traina) (09/28/88)
I've got a rather ugly situation. I'd like to be able to utilize more
serial ports than I really own. I've got a Sun 3/280 that acts as our
gateway to the known universe, but I can't adequately justify the purchase
of an ALM-2 (16 port serial card) to fit in it. This leaves 2 serial
ports on the CPU, one goes to the console, one is our modem line.
I've heard that someone out there has managed to get UUCP to work over
rlogin sessions. If this is the case, then I could attach another modem
(or several) to different workstations so that if a remote dialer logs
in as 'uucp' s/he will immediately be connected to the gateway. To
this end, I munged a little script to do this:
#! /bin/sh
#
# Act as a software terminal switch for remote uucp logins
# obnoxious hack stolen from Tim's Managing UUCP book.
#
# pst 15-aug-1988
#
#
gateway=comdesign
#me=`who am i | cut -d" " -f1 | cut -d! -f2`
if [ `hostname` != $gateway ]
then
stty raw
exec rlogin $gateway -8 -e\255
else
exec /usr/lib/uucp/uucico
fi
exit
Unfortunately, this doesn't work. The transfer takes place, the
shere messages start to fly, and then the rlogin session gets disconnected.
Does anyone know of a hack to make this work (invalid flags to rlogin?)?
I realize this whole thing is ugly, but unless I wirewrap another serial
card myself, it's the only way things are going to happen.
Thanks,
Paul
------
Paul Traina To believe that what is true for
{uunet|pyramid}!comdesign!pst you in your private heart is true
pst@condor.cdi.com for all men, that is genius.mml@magnus.UUCP (Mike Levin) (09/30/88)
In article <531@comdesign.CDI.COM> pst@comdesign.cdi.com (Paul Traina) writes: >I've heard that someone out there has managed to get UUCP to work over >rlogin sessions. If this is the case, then I could attach another modem . . . > >Unfortunately, this doesn't work. The transfer takes place, the >shere messages start to fly, and then the rlogin session gets disconnected. >Does anyone know of a hack to make this work (invalid flags to rlogin?)? > Sorry, Paul. Unless I'm *very* much mistaken, rlogin only supports an ASCII (7 bit) data stream. UUCP requires full 8-bits. This *may* not be true on your machine, but I'm sure it is on mine. :-( Regrettfully, Mike Levin -- +---+ P L E A S E R E S P O N D T O: +---+ * * * * * * * * * * | Michael M. Levin, Silent Radio, Los Angeles | I never thought I'd be LOOKING |{aeras|csun|mtune|pacbell|srhqla}!magnus!levin| for something to say! ! ! +----------------------------------------------+------------------------------+
badri@valhalla.ee.rochester.edu (Badri Lokanathan) (10/01/88)
In article <317@magnus.UUCP>, mml@magnus.UUCP (Mike Levin) writes: > Sorry, Paul. Unless I'm *very* much mistaken, rlogin only supports > an ASCII (7 bit) data stream. UUCP requires full 8-bits. This *may* not > be true on your machine, but I'm sure it is on mine. :-( > The UUCP distributed under 4.3 BSD does support 7-bit data paths with the 'f' protocol. We used to run UUCP over rlogin 2 years ago with a version hacked by Rick Adams. It worked without any problems. We dialled out over a dataswitch to connect to an annex server, then used rlogin to connect to the desired site. Nothing fancy was required. -- "We will fight for the right to be free {) badri@valhalla.ee.rochester.edu We will build our own society //\\ {ames,cmcl2,columbia,cornell, And we will sing, we will sing ///\\\ garp,harvard,ll-xn,rutgers}! We will sing our own song." -UB40 _||_ rochester!ur-valhalla!badri
chris@mimsy.UUCP (Chris Torek) (10/01/88)
>In article <531@comdesign.CDI.COM> pst@comdesign.cdi.com (Paul Traina) writes: >>I've heard that someone out there has managed to get UUCP to work over >>rlogin sessions. ... In article <317@magnus.UUCP> mml@magnus.UUCP (Mike Levin) writes: > Sorry, Paul. Unless I'm *very* much mistaken, rlogin only supports >an ASCII (7 bit) data stream. UUCP requires full 8-bits. This *may* not >be true on your machine, but I'm sure it is on mine. :-( The g-protocol requires an 8-bit path; UUCP itself does not care, but if you only have the g protocol inside it, you are stuck. But rlogin *does* support an 8 bit data path (`rlogin -8'). The problem is that rlogin, as it is delivered by Berkeley (and thus presuably DEC and Sun) will not allow you to disable escapes. `rlogin -e\255' (as Paul tried) sets the escape character to \. Since the escape character is in fact a `char' variable, and holds only 8 bits, there is no input that will set it to something UUCP will never use. If you have source, you can fix this; if not, you will have to plead with your vendor. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bill@carpet.WLK.COM (Bill Kennedy) (10/02/88)
|>In article <531@comdesign.CDI.COM> pst@comdesign.cdi.com (Paul Traina) writes: |>>I've heard that someone out there has managed to get UUCP to work over |>>rlogin sessions. ... | |In article <317@magnus.UUCP> mml@magnus.UUCP (Mike Levin) writes: |> Sorry, Paul. Unless I'm *very* much mistaken, rlogin only supports |>an ASCII (7 bit) data stream. UUCP requires full 8-bits. This *may* not |>be true on your machine, but I'm sure it is on mine. :-( | In article <13797@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: |The g-protocol requires an 8-bit path; UUCP itself does not care, but |if you only have the g protocol inside it, you are stuck. But rlogin |*does* support an 8 bit data path (`rlogin -8'). The problem is that |rlogin, as it is delivered by Berkeley (and thus presuably DEC and Sun) |will not allow you to disable escapes. `rlogin -e\255' (as Paul tried) |sets the escape character to \. Since the escape character is in fact |a `char' variable, and holds only 8 bits, there is no input that will |set it to something UUCP will never use. | |If you have source, you can fix this; if not, you will have to plead |with your vendor. |-- |In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) I'm sorry to duplicate so much of this but I'm genuinely confused and don't want to omit something that might be vital to my (and others') understanding. I did some work for Sun Microsystems a while back and the only reasonable way to get the data from where it was (an IBM PC-XT) to where it needed to be (a Sun 3/140) was to use uucp with the XT running UULINK. This was well and good until someone pulled out the serial line we had been using and left us with only one line to a terminal that was on another system. Not knowing that you couldn't rlogin to uucico I changed the chat script so that the first thing to do was rlogin to the target system and execute uucico as the default shell just like we did when we were connected directly and logged in via getty. It was perhaps not the most elegant approach to the problem but it did work and continues to work that way (as recently as yesterday). Should we not have been able to do this? We are transferring 8 bit binary .COM files into the Sun to be downloaded into an intelligent conveyor controller. That leaves me more puzzled than ever since we send them straight in, no uuencode or anything like that and they work. We don't have any sttys or anything, we just unplug the terminal that's connected to another system, log in and then rlogin to the target. I'm not really asking if it should work or not, I'm more concerned about whether it's likely to break. Should we be unable to do this? If so, should we be alert for it to stop working when someone "fixes" it? -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill
chris@mimsy.UUCP (Chris Torek) (10/02/88)
>In article <13797@mimsy.UUCP> I pointed out that >>rlogin ... will not allow you to disable escapes. In article <166@carpet.WLK.COM> bill@carpet.WLK.COM (Bill Kennedy) notes: >Not knowing that you couldn't rlogin to uucico I [did it anyway] ... >It was perhaps not the most elegant approach to the problem but it did work >and continues to work that way (as recently as yesterday). ... >I'm not really asking if it should work or not, I'm more concerned about >whether it's likely to break. Should we be unable to do this? If so, >should we be alert for it to stop working when someone "fixes" it? As long as UUCP never transmits one of the sequences RETURN escchar . RETURN escchar Meta-DEL RETURN escchar escchar (where escchar is the character set by -e, default `~') it will continue to work. Obviously, these three sequences are statistically unlikely: P=3/256^3 in uniformly random data, or about .000018%. You should be able to manufacture a file that will reliably break the connection, however, and Murphy dictates that your boss will do it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
erik@mpx1.UUCP (Erik Murrey) (10/03/88)
In article <13811@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > As long as UUCP never transmits one of the sequences > > RETURN escchar . > RETURN escchar Meta-DEL > RETURN escchar escchar > > (where escchar is the character set by -e, default `~') it will > continue to work. Obviously, these three sequences are statistically > unlikely: P=3/256^3 in uniformly random data, or about .000018%. You The escape sequence for TELENET (not telnet) is <cr>@<cr>. I found that when transmitting compressed files over PC-Pursuit, the file almost always contained this escape sequence, which escaped out of PC-Pursuit and caused the transmission to fail. I think that compressed files contain a very random distribution of the entire 8 bit set. (This is why compresseing a compressed file makes an even bigger file, right?) I would think that you would hit the rlogin escape very easily when sending 14 or 16 bit compressed files. -- Erik Murrey /| // /~~~~/ | / MPX Data Systems, Inc. / | / / /____/ |/ erik@mpx1.UUCP / / / / /| Data Systems, Inc. {spl1,vu-vlsi,bpa}!mpx1!erik / / / / |====================
pst@canary.cdi.com (Paul Traina) (10/04/88)
From article <317@magnus.UUCP>, by mml@magnus.UUCP (Mike Levin):
# In article <531@comdesign.CDI.COM> pst@comdesign.cdi.com (Paul Traina) writes:
#>I've heard that someone out there has managed to get UUCP to work over
#>rlogin sessions. If this is the case, then I could attach another modem
# . . .
#
# Sorry, Paul. Unless I'm *very* much mistaken, rlogin only supports
# an ASCII (7 bit) data stream. UUCP requires full 8-bits. This *may* not
# be true on your machine, but I'm sure it is on mine. :-(
The -8 flag in the command line of rlogin specifies an 8 bit path.
(I'm running 4.2bsd networking software (minor sad face)).
------
Paul Traina To believe that what is true for
{uunet|pyramid}!comdesign!pst you in your private heart is true
pst@condor.cdi.com for all men, that is genius.gareth@ufnmr.UUCP (Gareth J. Barker) (10/05/88)
In article <317@magnus.UUCP>, mml@magnus.UUCP (Mike Levin) writes: > In article <531@comdesign.CDI.COM> pst@comdesign.cdi.com (Paul Traina) writes: > > >I've heard that someone out there has managed to get UUCP to work over > >rlogin sessions. If this is the case, then I could attach another modem > > Sorry, Paul. Unless I'm *very* much mistaken, rlogin only supports > an ASCII (7 bit) data stream. UUCP requires full 8-bits. This *may* not > be true on your machine, but I'm sure it is on mine. :-( I came in to this a bit late, so I'm not sure what machine types we're talking about, but on Suns in particular rlogin has an 'undocumented option' ( -8 ) (<- that's a 'minus eight', not a 'smiley face') which gives a full eight bit connection. I've no idea if this is a BSDism, a SYS Vism or Sun specific, but it's been there at least since SunOs 3.2. Gareth J. Barker, University of Florida, Department of Radiology. INTERNET : ufnmr!gareth@BIKINI.CIS.UFL.EDU UUCP : ...gatech!uflorida!ufnmr!gareth
pst@osprey.cdi.com (Paul Traina) (10/05/88)
Thanks everyone for their suggestions. Since I didn't have source code
to my rlogin (grrr, Sun, curses to you), I digged out adb and hacked a
bit to bypass the escape character check.
After everything was done, I tried it out and lo and behold, it worked.
...
Slowly
...
The connection was (modem) -> ComDesign LAN Terminal server
-> ComDesign WAN/LAN gateway
-> ComDesign WAN Terminal server
-> Sun 3/50 serial port
-> rlogin session to Sun 3/280
Now, admittedly, the biggest bottleneck was this brain-dammaged stupidity
of having the sun 3/50 serial ports hung off a terminal server driven
by 1 9600bps link (I happend to be alpha-testing a new TS we're making
so that's why I was running two WAN nodes 5 feet across from each other).
Anyway, throuhput (modem at 1200 baud) was about 25cps. Sigh.
We'll see how it goes once I put that 3/50 back onto a LAN terminal server.
Thanks.
Paul
p.s. don't show this to any of our marketing nazi's, as our networking muxes
are supposed to be fast (sigh :-) ).
------
Paul Traina To believe that what is true for
{uunet|pyramid}!comdesign!pst you in your private heart is true
pst@condor.cdi.com for all men, that is genius.dyer@spdcc.COM (Steve Dyer) (10/09/88)
In article <13811@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >As long as UUCP never transmits one of the sequences > > RETURN escchar . > RETURN escchar Meta-DEL > RETURN escchar escchar > >(where escchar is the character set by -e, default `~') it will >continue to work. Obviously, these three sequences are statistically >unlikely: P=3/256^3 in uniformly random data, or about .000018%. You >should be able to manufacture a file that will reliably break the >connection, however, and Murphy dictates that your boss will do it. I should mention that I've been UUCPing at 9600 baud using rlogin from an annex box for over a year now. I get all my news and mail this way. This doesn't invalidate anything Chris says, but I've never come across a file of any sort which was a "bottleneck" and hung things up until it was deleted. I will have to try his suggestion. This works successfully with 4.3BSD on both VAXes and RT/PCs. HOWEVER, I find that I am unable to reliably use this to any Ultrix system--while UUCP transfers from the Ultrix machine to spdcc work more or less OK, any transfers in the spdcc-->Ultrix direction ultimately time out. This occurs even with running 4.3BSD UUCP under Ultrix. I had originally seen this only when trying to connect to machines on the other end of a slow link (9600 baud) and thought it might result from the Annex's incorrect calculation of RTT and subsequent wasteful retransmissions--I hadn't made the connection yet that it was happening only with Ultrix machines. However, I had the unfortunate experience of finding my primary news feed which is on the same ethernet as the Annex box converted overnight from 4.3BSD to Ultrix 2.2 and the same thing happens-- the rlogin sessions which had been working for so long were now effectively useless. Anyone know what's going on there? I was thinking maybe DEC diddled with their PTYs to handle DECnet better or their TCP/IP implementation or something. Suggestions or enlightenment welcome. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer