jns@fernwood.mpk.ca.US (Jerry Sweet) (01/12/91)
For me, this note applies to RISC/os 4.51 on an RC3230. The man page for uugetty, as well as the Nutshell handbook, leads one to believe that uugetty will "step aside" for other processes that wish to use a modem port for which a uugetty process is awaiting login (presumably via "respawn" in the inittab). This appears not to be the case. Uugetty, while waiting for login, leaves a lock file in /usr/spool/locks. Kermit, of course, wants to put its lock file in the standard place, /usr/spool/uucp. If you request the same line for which there is a uugetty process, you're out of luck---it'll just sit there waiting for...what? The device to be closed? The question is: how does one properly make the alleged "step-aside" feature of uugetty happen? Does one have to (a) leave the port "off" in inittab, put up a uugetty only when one is done dialling out on a port, and then kill the uugetty if one wishes dial out on the same port again? or (b) kill the uugetty job for that port and quickly try to grab it before init spawns another uugetty? or (c) do the tedious thing of having two inittabs, one with uugetty off and one with uugetty on, etc., etc. ...? Perplexed in Menlo Park...
lgy@phys.washington.edu (Laurence G. Yaffe) (01/14/91)
jns@fernwood.mpk.ca.US (Jerry Sweet) writes:
-For me, this note applies to RISC/os 4.51 on an RC3230.
-The man page for uugetty, as well as the Nutshell handbook, leads one
-to believe that uugetty will "step aside" for other processes that
-wish to use a modem port for which a uugetty process is awaiting login
-(presumably via "respawn" in the inittab). This appears not to be the
-case. Uugetty, while waiting for login, leaves a lock file in
-/usr/spool/locks.
-The question is: how does one properly make the alleged "step-aside"
-feature of uugetty happen? [Various possibilities deleted]
I posted the same query about 6 months ago and someone (I forget who -
sorry!) reminded me that uugetty's from versions of RISC/os earlier than 4.50
seem to work better than the current released version. I believe I'm now using
a 4.31 version.
--
--------------------------------------------------------------------------
Laurence G. Yaffe Internet: lgy@newton.phys.washington.edu
University of Washington Bitnet: yaffe@uwaphast.bitnettrevc@moosehead.mips.com (Trevor Cotton) (01/15/91)
In article <lgy.663813854@newton>, lgy@phys.washington.edu (Laurence G. Yaffe) writes: > jns@fernwood.mpk.ca.US (Jerry Sweet) writes: > > > -For me, this note applies to RISC/os 4.51 on an RC3230. > > -The man page for uugetty, as well as the Nutshell handbook, leads one > -to believe that uugetty will "step aside" for other processes that > -wish to use a modem port for which a uugetty process is awaiting login > -(presumably via "respawn" in the inittab). This appears not to be the > -case. Uugetty, while waiting for login, leaves a lock file in > -/usr/spool/locks. > > -The question is: how does one properly make the alleged "step-aside" > -feature of uugetty happen? [Various possibilities deleted] > > I posted the same query about 6 months ago and someone (I forget who - > sorry!) reminded me that uugetty's from versions of RISC/os earlier than 4.50 > seem to work better than the current released version. I believe I'm now using > a 4.31 version. > > -- > -------------------------------------------------------------------------- > Laurence G. Yaffe Internet: lgy@newton.phys.washington.edu > University of Washington Bitnet: yaffe@uwaphast.bitnet The trick is to set up your modem so that DCD is off until a carrier is detected from the remote host. Use a line with modem control ( stty -clocal ) uugetty will then block until it detects a carrier, at which point it will create the lock file. The RISC/os 4.50 release notes explain which MIPS serial lines support modem control, and example cables to use. Here are the introductory notes from the source that give more detail. /* This program, when compiled as uugetty, is the */ /* standard getty modified */ /* to allow a tty line to be used by uucp/cu/tip or a dial in. */ /* For it to work with 801/212 dialers, */ /* put an entry into inittab like */ /* 30:2:respawn:/usr/lib/uucp/uugetty -t 60 ttymh4 1200 */ /* For direct lines, or intelligent modems use */ /* 30:2:respawn:/usr/lib/uucp/uugetty -r -t 60 ttymh4 9600 */ /* When this line is used, the Systems file that is */ /* used to call into it must have the following script */ /* "" \r\d\r\d\r\d\r in:--in: ... */ /* This is because the uugetty expects to read a character */ /* before the login message is output. */ /* It will only work on systems that permit kill(0, pid). */ /* This scheme was proposed by Larry Wehr and works as follows: */ /* The fopen of the line hangs until carrier is detected. */ /* At this point, uugetty attempts to create a LCK..line file */ /* If if fails, that means that uucico or cu are using the line. */ /* In this case, just do a busy wait, periodically checking */ /* for the LCK..line file. When it goes away, then exit and */ /* a new uugetty will be spawned. */ /* If it succeeds, then this is someone logging in--do normal */ /* getty processing. */ /* NOTE: */ /* When the person hangs up (login case) the LCK..line file */ /* will remain, but this is ok because the ulockf() function */ /* used by uucico and uugetty and cu check the pid in the LCK */ /* file and if it doesn't exist, the LCK file is removed when */ /* it is needed. */ /* Also, uugetty always sets the owner of the line to uucp. */ /* This is so that uucico/cu/tip can get at the line. (cu and tip */ /* must run setuid uucp--or this will not work.) */ /* */ /* There is an additional option for direct lines and lines */ /* that have intelligent modems (ones that return on open */ /* immediately. The -r option means wait for one character */ /* before putting out the login message. If the character */ /* comes in, then check the LCK file and proceed as above. */ --trevc-- Trevor Cotton, MIPS Computer Systems Inc. MS 6-05, 930 DeGuigne Drive, Sunnyvale, CA 94086 Tel: +1 408 524 7286 Fax: +1 408 524 7521 Email: {wyse,ames,decwrl,pyramid}!mips!trevc trevc@mips.com
jns@fernwood.mpk.ca.US (Jerry Sweet) (01/15/91)
I made another attempt to make uugetty do its step-aside thing, using a different modem, a Telebit T1600 this time. Using the RS232 breakout box, I verified that the behavior of DCD is correct: the modem only turns on DCD when there is actually carrier present. Unfortunately, uugetty is still exhibiting the same behavior: it won't step aside either for kermit or for tip. Tip reports "all ports busy". Kermit just sits there when you try to "set line". When I disable uugetty on the port, kermit and tip are able to get through with no trouble. Uugetty otherwise exhibits exemplary standard getty behavior vis a vis login when it's enabled. If another experiment is suggested that might make uugetty do the right thing, I'll give it a try. (I haven't yet tried using the RISC/os 4.30 version of uugetty, as Laurence Yaffe suggested in his response to me in comp.sys.mips.) Here's the setup (some recap): This is being run on an RS3230 with RISC/os 4.51. The modem (DCE) is connected via a MIPS-supplied "RJ45"(*)-to-DB25 cable to a MIPS-supplied 16-port DigiBoard (DTE). The T1600 is set to run with proper DCD behavior (&C1 - assert DCD only when carrier is actually present) and to use RTS/CTS hardware flow control (S58=2, S68=255). The gettydef line being used with the inittab entry is: tbplus.19200# B19200 RTSCTS HUPCL # B19200 SANE RTSCTS TAB3 HUPCL #\r\n\nlogin: #tbplus.19200 Based on my reading of termio(7) and gettydefs(4), I believe that the absence of CLOCAL here is equivalent to stty -clocal, unless SANE turns it on. (What exactly does SANE turn on and off, anyway?) The inittab line is: d0:234:respawn:/usr/lib/uucp/uugetty -r -t 60 ttyd0 tbplus.19200 none LDISC2 ;# TB+ in/out The device, /dev/ttyd0, is set up this way: crw--w--w- 1 uucp other 32, 0 Jan 14 22:04 /dev/ttyd0 If you're wondering how I got kermit to work with this configuration, I wrote a short and nasty little program that execs to kermit while setuid to uucp. Tip, of course, is already setuid to uucp. (*) Just thought I'd mention that the 10-pin modular connector to which MIPS refers as "RJ45" in its documentation does NOT appear to correspond to what the rest of the world calls RJ45: everyone else is using the term "RJ45" to refer to 8-pin modular connectors. Alternative local sources for ten pin modular connectors haven't yet made themselves apparent to me. I bought the MIPS cable, so there's presumably no question about the cable.
pbickers@tamaluit.phys.uidaho.edu (Paul Bickerstaff) (01/16/91)
A non-Mips distributor for the 10-conductor cables is K&H Distributors. Mips suggest them in their installation guide but the address has recently changed to: 6800 Shingle Creek Parkway Brooklyn Center MN 55430 Phone no. is still (800)328-8515 but the part no. has also changed. You'll have to call them for that as I don't have it handy. They once quoted me $6.50/cable but when I placed my order it was more like $16 so Mips' $20 isn't so bad. The difficulty here is finding this 10 conductor cable and connectors all (?) catalogues only list 4,6 and 8. A caution is to check the jumper settings on the Digiboard. In at least one case Mips have installed these with the Digiboard defaults :-( Paul Bickerstaff Internet: pbickers@tamaluit.phys.uidaho.edu Physics Dept., Univ. of Idaho Phone: (208) 885 6809 Moscow ID 83843, USA FAX: (208) 885 6173
trevc@moosehead.mips.com (Trevor Cotton) (01/16/91)
In article <9101150643.AA26295@fernwood.mpk.ca.us>, jns@fernwood.mpk.ca.US (Jerry Sweet) writes: > > I made another attempt to make uugetty do its step-aside thing, using > a different modem, a Telebit T1600 this time. Using the RS232 > breakout box, I verified that the behavior of DCD is correct: the > modem only turns on DCD when there is actually carrier present. > Unfortunately, uugetty is still exhibiting the same behavior: it won't > step aside either for kermit or for tip. Tip reports "all ports > busy". Kermit just sits there when you try to "set line". When I > disable uugetty on the port, kermit and tip are able to get through > with no trouble. Uugetty otherwise exhibits exemplary standard getty > behavior vis a vis login when it's enabled. > > If another experiment is suggested that might make uugetty do the > right thing, I'll give it a try. (I haven't yet tried using the > RISC/os 4.30 version of uugetty, as Laurence Yaffe suggested in > his response to me in comp.sys.mips.) > > Here's the setup (some recap): > Create the device /dev/ttydm0 with major number 32 and minor number 128 and use that instead. The serial line drivers are all written to use modem control by default on lines with minor number > 128. This is how I am set up here ( I use a Telebit T2500 ) and uugetty and cu co-exist happily. Note that I do have a problem with kermit; kermit creates its lock file in /usr/spool/uucp rather than /usr/spool/locks, which is where cu and uugetty create their lock files. The other problem, as you pointed out, is that kermit needs to run as uucp to be able to access the line as uugetty and cu make uucp the owner. I have submitted a (Mips) bug report for kermit . --trevc--
hartzell@boulder.Colorado.EDU (George Hartzell) (01/17/91)
In article <44917@mips.mips.COM> trevc@moosehead.mips.com (Trevor Cotton) writes: In article <9101150643.AA26295@fernwood.mpk.ca.us>, jns@fernwood.mpk.ca.US (Jerry Sweet) writes: > > I made another attempt to make uugetty do its step-aside thing, using > a different modem, a Telebit T1600 this time. Using the RS232 > breakout box, I verified that the behavior of DCD is correct: the > modem only turns on DCD when there is actually carrier present. > Unfortunately, uugetty is still exhibiting the same behavior: it won't > step aside either for kermit or for tip. Tip reports "all ports > busy". Kermit just sits there when you try to "set line". When I > disable uugetty on the port, kermit and tip are able to get through > with no trouble. Uugetty otherwise exhibits exemplary standard getty > behavior vis a vis login when it's enabled. > > If another experiment is suggested that might make uugetty do the > right thing, I'll give it a try. (I haven't yet tried using the > RISC/os 4.30 version of uugetty, as Laurence Yaffe suggested in > his response to me in comp.sys.mips.) > > Here's the setup (some recap): > Create the device /dev/ttydm0 with major number 32 and minor number 128 and use that instead. The serial line drivers are all written to use modem control by default on lines with minor number > 128. This is how I am set up here ( I use a Telebit T2500 ) and uugetty and cu co-exist happily. Note that I do have a problem with kermit; kermit creates its lock file in /usr/spool/uucp rather than /usr/spool/locks, which is where cu and uugetty create their lock files. The other problem, as you pointed out, is that kermit needs to run as uucp to be able to access the line as uugetty and cu make uucp the owner. I have submitted a (Mips) bug report for kermit . --trevc-- Could part of the problem be that Jerry is using tip, and you are using cu? Maybe tip has the same problem that kermit has? Make sure that you have the kernel option (man kopt for info) _riscos_ttys_default_clocal set to the default to get the scheme mentioned above to work. g. -- George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!ncar!boulder!hartzell
jns@fernwood.mpk.ca.US (Jerry Sweet) (01/17/91)
I didn't mean to confuse y'all about the nature of my continuing problems with uugetty at this point. I appreciate all the helpful suggestions. George Hartzell asked if there was a problem because of tip vs. cu. The answer is probably not, partly because tip and cu are linked together---they're the same program---and partly because some progress has been made, although it's not entirely satisfactory progress. Here's how it went down: 1. I attached a modem (a Telebit T1600) with the correct DCD behavior to the line (&C1, for those of you with similar modems). 2. I created the necessary tty devices, with the magic minor device numbers that make the kernel's device drivers do the right thing vis a vis modem control (see my previous posting of the script to do that in comp.sys.mips). 3. Uugetty now properly steps aside for tip, but it won't deliver a login prompt for dial-in connections, although DCD is definitely doing the right thing. I don't know for certain whether to blame uugetty or the modem. I am leaning toward blaming the modem, because Trevor Cotton assures me that everything is working for him, whereas the T1600 that I'm using is now exhibiting strange behavior, even when attached to another system with which it was working correctly before this experiment. I don't really know what to think at this point, except that I have some serious hours of diagnostic work ahead of me to figure out what may be wrong with the modem.
hartzell@boulder.Colorado.EDU (George Hartzell) (01/17/91)
In article <9101162234.AA07103@fernwood.mpk.ca.us> jns@fernwood.mpk.ca.US (Jerry Sweet) writes:
I didn't mean to confuse y'all about the nature of my continuing
problems with uugetty at this point. I appreciate all the helpful
suggestions.
George Hartzell asked if there was a problem because of tip vs. cu.
The answer is probably not, partly because tip and cu are linked
together---they're the same program---and partly because some progress
has been made, although it's not entirely satisfactory progress.
There is one tip (/bsd43/bin/tip) and two cu's (/usr/bin/cu and
/bsd43/bin/cu). The two /bsd43/bin programs are indeed linked but
they are quite different from /usr/bin/cu. user emptor.
Here's how it went down:
1. I attached a modem (a Telebit T1600) with the correct DCD behavior to
the line (&C1, for those of you with similar modems).
2. I created the necessary tty devices, with the magic minor device numbers
that make the kernel's device drivers do the right thing vis a vis
modem control (see my previous posting of the script to do that
in comp.sys.mips).
3. Uugetty now properly steps aside for tip, but it won't deliver a login
prompt for dial-in connections, although DCD is definitely doing
the right thing. I don't know for certain whether to blame uugetty
or the modem. I am leaning toward blaming the modem, because Trevor
Cotton assures me that everything is working for him, whereas the
T1600 that I'm using is now exhibiting strange behavior, even
when attached to another system with which it was working correctly
before this experiment.
I don't really know what to think at this point, except that I have
some serious hours of diagnostic work ahead of me to figure out what
may be wrong with the modem.
Good luck. I have had very little success with reliably running
modems on my M--2000. I've tried several modems, more cables
configurations than I want to think about, [absence of] magic minor
device numbers, and prayer. At this point I wouldn't be surprised if
someone from MIPS found some sort of a glitch with how there
drivers/streams code handles lines that are not CLOCAL.
Please let me know what you find.
g.
--
George Hartzell (303) 492-4535
MCD Biology, University of Colorado-Boulder, Boulder, CO 80309
hartzell@Boulder.Colorado.EDU ..!ncar!boulder!hartzellwje@redwood.mips.com (William J. Earl) (01/19/91)
In article <9101162234.AA07103@fernwood.mpk.ca.us>, jns@fernwood (Jerry Sweet) writes: >... > George Hartzell asked if there was a problem because of tip vs. cu. > The answer is probably not, partly because tip and cu are linked > together---they're the same program---and partly because some progress > has been made, although it's not entirely satisfactory progress. There are actually two cu programs. /bsd43/bin/cu is just a link to /bsd43/bin/tip, and is of course compatible with 4.3 BSD cu. /usr/bin/cu is a completely different program, and is the SVR3 cu. -- William J. Earl wje@mips.com MIPS Computer Systems 408-524-8172 930 Arques Avenue, M/S 1-03 FAX 408-524-8401 Sunnyvale, CA 94086-3650
wje@redwood.mips.com (William J. Earl) (02/05/91)
In article <9101111107.AA09005@fernwood.mpk.ca.us>, jns@fernwood (Jerry Sweet) writes: > > For me, this note applies to RISC/os 4.51 on an RC3230. > > The man page for uugetty, as well as the Nutshell handbook, leads one > to believe that uugetty will "step aside" for other processes that > wish to use a modem port for which a uugetty process is awaiting login > (presumably via "respawn" in the inittab). This appears not to be the > case. Uugetty, while waiting for login, leaves a lock file in > /usr/spool/locks. > > Kermit, of course, wants to put its lock file in the standard place, > /usr/spool/uucp. If you request the same line for which there is a > uugetty process, you're out of luck---it'll just sit there waiting > for...what? The device to be closed? > > The question is: how does one properly make the alleged "step-aside" > feature of uugetty happen? Does one have to (a) leave the port "off" > in inittab, put up a uugetty only when one is done dialling out on a > port, and then kill the uugetty if one wishes dial out on the same > port again? or (b) kill the uugetty job for that port and quickly try > to grab it before init spawns another uugetty? or (c) do the tedious > thing of having two inittabs, one with uugetty off and one with > uugetty on, etc., etc. ...? uugetty will step aside, but only if it does not yet have "carrier" on the line. If you use an ordinary terminal port (minor device number less than 128), CLOCAL is assumed at open time, at least until some ioctl() changes it. Since uugetty just does open()'s, without and then with O_NDELAY set, to first vhangup() the line and then wait for carrier, uugetty always finds carrier present on an ordinary terminal port. All real RISC/os terminal lines (where "real" means "not pty") have two minor numbers, differing by 128. The device with smaller minor number (such as /dev/tty1, which has major device number 0 and minor device number 1) defaults to CLOCAL on at open time, and the device with the larger minor number (such as /dev/ttym1, which has major device number 0 and minor device number 129) defaults to CLOCAL off. To use uugetty on a modem line, which is to be shared with tip, cu, uucico, and the like, you need to use the device with the larger minor number exclusively, and also set HUPCL and not set CLOCAL in the /etc/gettydefs declaration for the line. For example, to use uugetty on the first line on the first "c8" ("DigiData") serial I/O expansion card on a RC3240, assuming a Hayes-compatible 9600-baud modeem, add to /etc/inittab: m0:234:respawn:/usr/lib/uucp/uugetty -t60 ttymd0 dm_9600 none LDISC0 and add to /etc/gettydefs: dm_9600# B9600 # B9600 SANE TAB3 HUPCL #\r\n\n$HOSTNAME login: #dm_9600 and add to /etc/remote (for use by tip): ttymd0:dv=/dev/ttymd0:br#9600: ttymd1:dv=/dev/ttymd1:br#9600: ttymd2:dv=/dev/ttymd2:br#9600: ttymd3:dv=/dev/ttymd3:br#9600: ttymdialer:dv=/dev/ttymd3,/dev/ttymd2,/dev/ttymd1,/dev/ttymd0:br#9600: ttymd:du:at=hayes:pn=@:tc=ttymdialer: (assuming you have several such lines, /dev/ttymd3, /dev/ttymd2, /dev/ttymd1, and /dev/ttymd0 and want automatic selection of a free line), and add to /usr/lib/uucp/Devices: Direct ttymd0 - 9600 direct Direct ttymd1 - 9600 direct Direct ttymd2 - 9600 direct Direct ttymd3 - 9600 direct ACU ttymd3 - 9600 tb9600 \D ACU ttymd2 - 9600 tb9600 \D ACU ttymd1 - 9600 tb9600 \D ACU ttymd0 - 9600 tb9600 \D In the above, the "Direct" entries are suitable for use with manual dialing via cu and the "ACU" entries are suitable for use for automatic dialing via cu or uucico. Of course, if you only have one line, you can omit the extra names. In any case, the modem must be configured to drop DCD when carrier is lost and to raise DCD only when carrier is detected. The net effect is that when uugetty does an open on a line with CLOCAL not set, the open waits until DCD rises. Meanwhile, if, say, tip opens the line with O_NDELAY set, its open completes immediately. tip will at this point have locked the line. (uugetty briefly locks and then unlocks the line when doing its vhangup(), but leaves it unlocked while waiting in open for DCD.) If tip then dials the phone, and DCD rises, uugetty's open will complete, whereupon uugetty will try to lock the line. uugetty will find the line locked (by tip), so it will then slowly poll for the lock before trying again to wait for carrier. Later, when tip hangs up the phone, and releases its lock, uugetty will acquire the lock and restart the whole process. The above behavior was documented in the RISC/os 4.0 release notes, but this information was unfortunately omitted from the RISC/os 4.50 manual pages. (This is a bug in the latter; I have entered a bug report to that effect, which should be fixed in the near future.) -- William J. Earl wje@mips.com MIPS Computer Systems 408-524-8172 930 Arques Avenue, M/S 1-03 FAX 408-524-8401 Sunnyvale, CA 94086-3650