stephen@osc.COM (H. Stephen Au-Yeung) (03/30/89)
According to "Managing UUCP and Usenet" by O'Reilly & Associates (A Nutshell
Handbook), SunOS has a mechanism of its own that allows a port to be used in
both directions. I have tried to follow that mechanism (on page 34-35) but
everytime when getty tries to open /dev/ttyd? it gets through! Could someone
please tell me what I have done wrong (we use Telebit T1000 modems)? Thanks!
Stephen Au-Yeung
...!{amdcad,pacbell,stratus}!osc!stephenperry@key.COM (Peter Kiehtreiber) (04/05/89)
In article <160@osc.COM> stephen@osc.UUCP (H. Stephen Au-Yeung) writes: > > According to "Managing UUCP and Usenet" by O'Reilly & Associates (A Nutshell > Handbook), SunOS has a mechanism of its own that allows a port to be used in > both directions. I have tried to follow that mechanism (on page 34-35) but > everytime when getty tries to open /dev/ttyd? it gets through! Could someone > please tell me what I have done wrong (we use Telebit T1000 modems)? Thanks! > > Stephen Au-Yeung > ...!{amdcad,pacbell,stratus}!osc!stephen [I tried to mail a reply, but decwrl gave me the thumbs-down, and this may just be of use to others.] [SunOS's mechanism for dual call-in/call-out on one line, in case you others wonder, is to split /dev/tty* into /dev/ttyd* (dial-in) and /dev/cua* (call-out), distinguished by minor device number. The two logical devices lock each other out, so the call-out device fails the open while the corresponding call-in device is in use, and vice versa.] Stephen, Sounds like your setup doesn't properly handle the CD (carrier detect) signal. In the correct setup, getty will hang on the open(2) call for the modem because CD is down (off) until somebody actually dials in and the modem connects and turns CD on. Conversely, the corresponding /dev/cua* device will return open errors while CD is up (because the line is currently used for dial-in). For mostly historical reasons, most modems get delivered with a factory default that causes the modem to assert CD at all times. That's because in olden times, the computer/modem hardware and/or cabling tended to do unreasonable things with this signal. For the SunOS setup to work, CD must properly reflect the connect status of the modem. So: check your documentation. Find the dip switch and/or modem command that sounds like "raise and lower Carrier Detect depending on modem connection" as opposed to "always keep Carrier Detect asserted". Use it. Next potential gotcha: for similar reasons, the default configuration of the serial drivers pretends that the CD signal is always on, no matter what the hardware says (does that start to sound familiar?!). Check your kernel configuration file (/usr/sys/conf/WHATEVERFILENAME). If you use the CPU board serial port(s), check the "device zs0" line (say "man zs" for details). If you use a serial interface board (e.g. an ALM-2), check its configuration line (the ALM-2 is "man mcp", in case you wondered). In either case, clear the appropriate "flags" bits in the configuration file. [Yes, this means you have to build and install a new kernel. That's life.] If that doesn't help either, you're probably using bad cables that have short- circuited the CD line (yes, you can really buy such cables!). I hope this helps -- perry -- ------------------------------------------------------------------------ Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com ** What good signature isn't taken yet? ** ...!pacbell!key!perry
frank@ladcgw.UUCP (Frank Mayhar) (04/05/89)
The problem I found with bidirectional modem lines on my Sun 386i/150 running
4.0.1 was that, even when I made the kernel fix (a change to the serial port
flags), getty was still able to open the line, EVEN WITH THE CABLE UNPLUGGED!
Apparently either the flag is ignored (bug!) or the connection has a short.
Since I can't get the maintenance contract signed (budget problems), I'm
stuck.
--
Frank Mayhar <known-world>!uunet!ladcgw!frank
Frank-Mayhar%ladc@bco-multics.hbi.honeywell.com
Bull HN Los Angeles Development Center
5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241lmb@vicom.COM (Larry Blair) (04/06/89)
In article <743@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: =In article <160@osc.COM> stephen@osc.UUCP (H. Stephen Au-Yeung) writes: => => According to "Managing UUCP and Usenet" by O'Reilly & Associates (A Nutshell => Handbook), SunOS has a mechanism of its own that allows a port to be used in => both directions. I have tried to follow that mechanism (on page 34-35) but => everytime when getty tries to open /dev/ttyd? it gets through! Could someone => please tell me what I have done wrong (we use Telebit T1000 modems)? Thanks! = =Stephen, =Sounds like your setup doesn't properly handle the CD (carrier detect) =signal. = = [[advise on how to get it working.]] = =If that doesn't help either, you're probably using bad cables that have short- =circuited the CD line (yes, you can really buy such cables!). One more thing you forgot. If he's using an ALM-1, the DCD and DSR pins are reversed (sounds idiotic, but it's true). You'll have to build a special cable. -- Larry Blair ames!vsi1!lmb lmb@vicom.com
rayd@laidbak.UUCP (Ray Dueland) (04/06/89)
In article <743@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: >Sounds like your setup doesn't properly handle the CD (carrier detect) >signal. In the correct setup, getty will hang on the open(2) call for >the modem because CD is down (off) until somebody actually dials in and >the modem connects and turns CD on. Conversely, the corresponding >/dev/cua* device will return open errors while CD is up (because the line >is currently used for dial-in). If you think about it, this won't work. The dial out will cause CD to go high and the getty to complete its open. There has to be additional lock to secure access to the tty. In the bidirectional setups I've seen this is done with the LCK..tty file. Getty opens the tty and then *tries* to create the lockfile, cu/uucico creates the lockfile and then opens the tty. There is still a little time for a dialin user to get hosed here though. I have no experience with Sun uucp (other than the fact that its HDB). >So: check your documentation. Find the dip switch and/or modem command that >sounds like "raise and lower Carrier Detect depending on modem connection" >as opposed to "always keep Carrier Detect asserted". Use it. I agree on the problem. >Next potential gotcha: for similar reasons, the default configuration >of the serial drivers pretends that the CD signal is always on, no matter >what the hardware says (does that start to sound familiar?!). The file /usr/include/sys/tty.h on my Sun 3.5 system does not have the NOHANG tty mode flag that I've seen in other kernels to prevent the blocking on the open system call. -- Ray Dueland {amdahl|clout|masscomp|nucsrl|sun|tellab5}!laidbak!rayd
guy@auspex.auspex.com (Guy Harris) (04/07/89)
>>Sounds like your setup doesn't properly handle the CD (carrier detect) >>signal. In the correct setup, getty will hang on the open(2) call for >>the modem because CD is down (off) until somebody actually dials in and >>the modem connects and turns CD on. Conversely, the corresponding >>/dev/cua* device will return open errors while CD is up (because the line >>is currently used for dial-in). > >If you think about it, this won't work. Yes, but it works nonetheless, which means you have to think a bit harder. See below.... >The dial out will cause CD to go high and the getty to complete its >open. There has to be additional lock to secure access to the tty. Nope. The scheme used in, among other places, SunOS, has *two* device files that refer to the same serial port. One is the "dial-in" device, and has "getty" (or "init", on older systems) running on it waiting for somebody to dial in. The other is the "dial-out" device, and is what UUCP, "tip", "cu", etc., etc. use to dial out on that line. Opens on the "dial-in" device block until carrier comes up (unless you've not turned "soft carrier" off - more on this below). Opens on the "dial-out" device succeed even if carrier isn't up, so that you can talk to the modem. In addition, once the dial-out device is open, any opens on the dial-in device that are waiting for carrier to come up will *NOT* complete when carrier comes up! CD will come up if the dial out succeeds; however, this will *not* cause the "getty" to complete its open. Only when the program dialing out is done with the line, and closes it, does the line revert to "normal" mode, in which carrier coming up causes the "open" to complete; if the dial-out device is opened again, the "getty" will again not complete its "open" if carrier comes up. Attempts to open the dial-out device while the dial-in device is open fail with an error (EBUSY in SunOS 4.0). In SunOS, the dial-in device is generally named "/dev/ttydN", for some value of N, and the corresponding dial-out device is generally named "cuaN" or "cuN" or something such as that (this isn't an absolute requirement, though, as far as I know). >In the bidirectional setups I've seen this is done with the LCK..tty >file. Getty opens the tty and then *tries* to create the lockfile, >cu/uucico creates the lockfile and then opens the tty. There is still >a little time for a dialin user to get hosed here though. In the bidirectional setup I've seen, namely the SunOS one, "getty" knows absolutely nothing about UUCP lock files, which is nice; you don't have to change "getty" to have it work with this scheme. I think most, if not all, of the window in the other scheme is closed with the two-devices scheme. >I have no experience with Sun uucp (other than the fact that its HDB). Either: 1) you have experience with the SunOS 4.1 UUCP; 2) your experience with the SunOS UUCP comes from connections with Sun's UUCP machine "sun"; or 3) you have even less experience with the Sun UUCP than you think; because, in the current release, it's *not* HDB. 4.1 will have HDB, and that version of UUCP is what's running on "sun" right now, but systems in the field don't have it. >>Next potential gotcha: for similar reasons, the default configuration >>of the serial drivers pretends that the CD signal is always on, no matter >>what the hardware says (does that start to sound familiar?!). > >The file /usr/include/sys/tty.h on my Sun 3.5 system does not have the >NOHANG tty mode flag that I've seen in other kernels to prevent the blocking >on the open system call. Well: 1) NOHANG sure doesn't do that under BSD - it only prevents SIGHUP from being delivered when carrier goes down. The way you prevent the blocking on the open system calls in 4.xBSD, for x >= 2, is to use the O_NDELAY flag on open. The SunOS 3.5 tty driver is mostly based on the 4.3BSD one; I think it has NOHANG. However, <sys/tty.h> is the wrong place to look; it's in <sys/ioctl.h> in 4.3BSD, and probably in SunOS 3.5 as well. 2) The default configuration *does*, in fact, pretend that the CD signal is always on, no matter what the hardware says, precisely as the previous poster stated. This is the "soft carrier" I referred to above. In order to turn "soft carrier" off for a port, you have to reconfigure your kernel - except, I think, on the Sun386i, where there may be: 1) a flag "local" in "/etc/ttytab" to specify that a line has "soft carrier" enabled; 2) an "ioctl" TIOCSSOFTCAR that permits you to set or clear the "soft carrier" flag for a tty port, and an "ioctl" TIOCGSOFTCAR that gets the state of the "soft carrier" flag for a port; 3) a program "ttysoftcar" that can be told to scan "/etc/ttytab" and set soft carrier appropriately and, possibly, to individually set or clear "soft carrier" on a port and print the status of "soft carrier" on that port. If you have a 386i, check whether there's a "local" field on the line in question in "/etc/ttytab"; if so, remove it, and try running "ttysoftcar -a", which I think may be the flag to scan "/etc/ttytab" (I didn't write it, and don't remember the details). Try "ttysoftcar -!" or something else to provoke it into issuing a usage message; unfortunately, this stuff was, I think, not documented. It may show up in the non-386i Suns in a future release, hopefully with documentation....
peter@ficc.uu.net (Peter da Silva) (04/07/89)
In article <1395@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > Opens on the "dial-in" device block until carrier comes up. [...] Opens on > the "dial-out" device succeed even if carrier isn't up, [...] In addition, > once the dial-out device is open, any opens on the dial-in device [...] will > *NOT* complete when carrier comes up!... This is likely to cause problems if you're trying to implement callback, isn't it? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
lmb@vicom.COM (Larry Blair) (04/08/89)
In article <3748@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: =In article <1395@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: => Opens on the "dial-in" device block until carrier comes up. [...] Opens on => the "dial-out" device succeed even if carrier isn't up, [...] In addition, => once the dial-out device is open, any opens on the dial-in device [...] will => *NOT* complete when carrier comes up!... = =This is likely to cause problems if you're trying to implement callback, =isn't it? Absolutely! I have struggle many an hour trying to figure out a way to do a callback that drops into getty. I have yet to figure it out and, apparently, neither has anyone else with a Sun. -- Larry Blair ames!vsi1!lmb lmb@vicom.com
guy@auspex.auspex.com (Guy Harris) (04/09/89)
>> Opens on the "dial-in" device block until carrier comes up. [...] Opens on >> the "dial-out" device succeed even if carrier isn't up, [...] In addition, >> once the dial-out device is open, any opens on the dial-in device [...] will >> *NOT* complete when carrier comes up!... > >This is likely to cause problems if you're trying to implement callback, >isn't it? Huh? Its sole purpose is to prevent two programs ("getty" and the program that's dialing out) from gaining simultaneous access to the same serial line. Giving them that simultaneous access is likely to cause problems; for one thing, they'll both be writing to it, and getting their output intermingled, and for another thing, they'll both be *reading* from it, and input will be randomly distributed among them.... If by "implement callback" you mean "implement a scheme by which computer A calls computer B and tells computer B to call computer A back", it doesn't cause any problems with that at all; the portion of the description which you elided explains why that works.
guy@auspex.auspex.com (Guy Harris) (04/09/89)
>Absolutely! I have struggle many an hour trying to figure out a way to >do a callback that drops into getty. I have yet to figure it out and, >apparently, neither has anyone else with a Sun. Huh? What do you mean by "a callback that drops into getty"? Do you mean you want to be able to have the machine call out to a terminal, and, once the connection is made, exec "getty"? Well, SunOS doesn't have "ct", but you could probably write a similar program. The 4.3BSD "getty", upon which the SunOS 4.0 "getty" is based, can be told to get the terminal on which it operates from file descriptor 0, rather than opening it explicitly. (Then again, "ct" doesn't "exec" "getty", it forks and then "exec"s it, so that might not even be a problem.) You can't rig it to cause the "getty" waiting on the dial-in line to wake up, but so what? "getty" is "getty"; the only difference is that the tty port will have a different name - "/dev/cua0", say, instead of "/dev/ttyd0". What's in a name? You can call the dial-out port "/dev/ttycu0" if you want.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (04/09/89)
>=This is likely to cause problems if you're trying to implement callback, >=isn't it? > >Absolutely! I have struggle many an hour trying to figure out a way to >do a callback that drops into getty. What's the problem? The dialout program opens the dialout device. It dials. The remote host answers. The dialout program forks/execs getty. getty execs login. login execs a shell. Shell goes away. The dialout program wakes up, closes the dialout device, and exits. Done! <csg>
peter@ficc.uu.net (Peter da Silva) (04/09/89)
In article <1403@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > If by "implement callback" you mean "implement a scheme by which > computer A calls computer B and tells computer B to call computer A > back", it doesn't cause any problems with that at all; the portion of > the description which you elided explains why that works. No it didn't. You described how line-sharing would work, but not how you can call back and provide a login session. Let's say you have a custom login program: Getty running on ttyXX. Phone rings. Open completes. Getty calls login. Login hangs up by closing ttyXX. Login opens culXX Login calls computer back. Login closes culXX and opens ttyXX Onwards... Unfortunately, when login closes culXX it drops DTR. If it doesn't drop DTR, then how do you hang up after calling, say, uunet? If it does, how do you hand off back to ttyXX without closing culXX? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
peter@ficc.uu.net (Peter da Silva) (04/09/89)
In article <1404@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > You can't rig it to cause the "getty" waiting on the dial-in line to > wake up, but so what? "getty" is "getty"; the only difference is that > the tty port will have a different name - "/dev/cua0", say, instead of > "/dev/ttyd0". What's in a name? You can call the dial-out port > "/dev/ttycu0" if you want. Then utmp is screwed up, because init thinks you were logged in on ttyd0 instead of ttycu0, and it never clears the login entry for ttycu0 in utmp. You'll show up in 'who' forever after. We do it this way on Xenix 3.5, because it's the only way to do it, and I'm having to rewrite init to track this multiple-tty-name stuff and clear BOTH entries. It's a pain. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
les@chinet.chi.il.us (Leslie Mikesell) (04/10/89)
In article <1395@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > >>In the bidirectional setups I've seen this is done with the LCK..tty >>file. Getty opens the tty and then *tries* to create the lockfile, >>cu/uucico creates the lockfile and then opens the tty. There is still >>a little time for a dialin user to get hosed here though. > >In the bidirectional setup I've seen, namely the SunOS one, "getty" >knows absolutely nothing about UUCP lock files, which is nice; you don't >have to change "getty" to have it work with this scheme. I think most, >if not all, of the window in the other scheme is closed with the >two-devices scheme. With the lockfile approach there is a small window between getty's open completing and the creation of the lockfile, during which an outgoing call might also think the line was free. This could be eliminated if there were a way for the outgoing caller to detect that carrier was already up on the line (atomically, of course..) or if a device could be opened for exclusive use, although that would cause other problems unless access could be restricted to the process group of the process that opens it first. With both approaches, there is still a window where the outgoing caller has grabbed the line and is preparing to dial when an inbound call hits the modem. This would typically be a longer interval than that required to make the lockfile, so there is probably little practical advantage to the two-device approach. However, if RFS networking makes it practical to use devices on a remote machine the "lockfile containg PID of active process" method is going to have to be replaced with something more versatile as well as dropping the assumption that ttys live in /dev. An "exclusive use" mode where the device could be used by the opening process or its children would be nice, with open modes that would either wait till the device becomes available or return immediately with an appropriate status. (Hmm.. this is beginning to sound a lot like file/region locking - does that work with devices?) Les Mikesell
itwaf@dcatla.UUCP (Bill Fulton [Sys Admin]) (04/11/89)
In article <260@ladcgw.UUCP> frank@ladcgw.UUCP (Frank Mayhar) writes: >The problem I found with bidirectional modem lines on my Sun 386i/150 running >4.0.1 was that, even when I made the kernel fix (a change to the serial port >flags), getty was still able to open the line, EVEN WITH THE CABLE UNPLUGGED! >Apparently either the flag is ignored (bug!) or the connection has a short. >-- >Frank Mayhar <known-world>!uunet!ladcgw!frank Great! Two months after I wrestled with this problem, along come some great articles about how to make it work. :-) Here's something I found out, relevant to the above follow-up, that may be of interest. I felt real dumb after I figured it out, but now I know there's at least one other guy who missed it, too. (Sorry, Frank!) On both a 3/50 Sun workstation, and a 3/280 Sun server (and so, I guess, on all/most Sun machines), the CD signal must be *ACTIVELY* pulled low. It seems that the Sun hardware actually pulls CD a little bit *HIGH*. This means that, even if you made all the necessary software/configuration changes (an experience in itself), if you just unplug the RS232 cable, the session/ application on that port will NOT sense a CD transition, and the session will stay up! (Can you say "security hole"?) I had a user who's application was never getting the SIGHUP when a *MODEM* hung up!!! Given that I have somewhat limited experience - I was still pretty surprised at this behaviour. I tried to contact the Sun hotline about this (just to get thier opinion/statement), but they said it was a (all together now) "hardware problem". I would think that CD should actually be pulled LOW by the internal hardware, requiring that it be actively tugged up in order for a connection to be honored, and insuring that a physical disconnect be sensed. Anybody out there familier enough with RS232 specs to comment? Anyway, hope this helps some - it sure would have saved me at least one late night - and a lot of forehead slapping, after the "problem" was recognized! Bill Fulton ..!gatech!dcatla!itwaf
guy@auspex.auspex.com (Guy Harris) (04/11/89)
>Then utmp is screwed up, because init thinks you were logged in on ttyd0 >instead of ttycu0, and it never clears the login entry for ttycu0 in utmp. >You'll show up in 'who' forever after. Not if the program that fires up "login" (e.g., "ct") knows enough to clear the login entry (which "ct" appears to do).
guy@auspex.auspex.com (Guy Harris) (04/11/89)
>If it does, how do you hand off back to ttyXX without closing culXX?
Why hand it off at all? (No, "so that the utmp entry gets cleared
properly" isn't an answer; "ct" clears the entry out for you, for
example, so if you have a "ct"-like program that does the calling and
then forks/execs "login", that's not a problem.)vjs@rhyolite.SGI.COM (Vernon Schryver) (04/11/89)
In article <16910@dcatla.UUCP>, itwaf@dcatla.UUCP (Bill Fulton [Sys Admin]) writes: > I would think that CD should actually be pulled LOW by the > internal hardware, requiring that it be actively tugged up in order for a > connection to be honored, and insuring that a physical disconnect be sensed. > Anybody out there familier enough with RS232 specs to comment? > > Bill Fulton > ..!gatech!dcatla!itwaf I call this a feature, not a bug. Having a 5-10K pullup on DCD and possibly CTS and maybe DSR is good. It makes common 3-wire cables (RD,TD,SG) work, without hurting real modem use. As long as the modem follows RS-232-C, avoiding the +/- 3v dead zone, and so is not just a TTL driver (does anyone still use such hacks?), what's the harm? Having a session going on an unplugged port does not sound like much a security problem. :-) At various employers over the last couple of decades, I've done it both ways, with and without pullups, and now prefer having pullups. Having to repeatedly communicate to novices that their dumb device which uses only TD,RD,&SG must have a connector which wraps RTS/CTS, DTR/DCD/DSR, and so on and on is harmful to one's good humor. Vernon Schryver Silicon Graphics vjs@sgi.com
rcodi@chudich.co.rmit.oz (Ian Donaldson) (04/11/89)
From article <1395@auspex.auspex.com>, by guy@auspex.auspex.com (Guy Harris): > Opens on the "dial-in" device block until carrier comes up (unless > you've not turned "soft carrier" off - more on this below). Hmmm. A technical point on this... measurements I have made on a Sun-3/260 with both mti and zs serial ports is this: DCD - when low, prevents the Sun driver from receiving data. Any data received in this state is ignored. Opening the cua device when DCD is low succeeds but you can't hear anything! ie: tie Sun-DCD to Sun-DTR so that you can always hear things when the device is open (either via cua or tty open). DSR - when low, prevents the Sun driver from allowing open's on the device to complete (unless O_NDELAY is specified or the kernel is configured to ignore "carrier" or a cua open is attempted). ie: tie Sun-DSR to remote-DTR so that the tty open succeeds when a connection to the remote happens. CTS - when low, prevents the serial chip from sending data iff: - the zs driver has been patched to set the bit in the scc that enables hardware flow control (patch needed at least on SunOS 3.whatever) - using the mti driver, in which case hardware flow control is on all the time, regardless of kernel running. Other manufacturers may adopt different policies WRT DCD and DSR; DSR is usually ignored and DCD handles both the data reception and open completion. Ian D
peter@ficc.uu.net (Peter da Silva) (04/13/89)
In article <1423@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > >Then utmp is screwed up, > Not if the program that fires up "login" (e.g., "ct") knows enough to > clear the login entry (which "ct" appears to do). The program that fires up 'login' isn't alive any more at that point. init execs getty; getty execs login; login calls back and execs the real login. There's some reason I have to have the parent of 'sh' be init, though I don't recall what it was, it didn't work if it wasn't done that way. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
kevin@iisat.UUCP (Kevin Davies) (04/14/89)
In article <3834@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <1423@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > > >Then utmp is screwed up, > > Not if the program that fires up "login" (e.g., "ct") knows enough to > > clear the login entry (which "ct" appears to do). > > init execs getty; getty execs login; login calls back and execs the real > login. There's some reason I have to have the parent of 'sh' be init, though > I don't recall what it was, it didn't work if it wasn't done that way. The parent of 'sh' has to be init, because that is the only indication that the program has that it is the login shell as apposed to a shell called by another program/shell. I suspect it is also the one that sends hangup signals to all other processes in the same process group etc. -- Kevin Davies International Information Service (IIS) UUCP: {uunet,utai,watmath}!dalcs!iisat!kevin Bitnet/Uucp: kevin@iisat.uucp Arpanet: kevin%iisat.uucp@uunet.uu.net
guy@auspex.auspex.com (Guy Harris) (04/15/89)
>init execs getty; getty execs login; login calls back and execs the real >login. There's some reason I have to have the parent of 'sh' be init, though >I don't recall what it was, it didn't work if it wasn't done that way. In that case, your "sh", or something, is broken. The SunOS version doesn't have this problem; otherwise, neither "rlogin" nor TELNET would work very well, since the login shell on a remote login is a child of the rlogin or TELNET daemon, not a child of "init". For that matter, "ct" won't work very well, either, on a system that demanded that the parent of a login shell be "init". (In the future it is possible that *no* login shells will be children of "init" on some systems.) I'm sorry you have a broken system, but that hardly renders SunOS-style dialin/dialout schemes unusable, except on broken systems such as the one you have.
allbery@ncoast.ORG (Brandon S. Allbery) (04/15/89)
As quoted from <3774@ficc.uu.net> by peter@ficc.uu.net (Peter da Silva): +--------------- | We do it this way on Xenix 3.5, because it's the only way to do it, and I'm | having to rewrite init to track this multiple-tty-name stuff and clear | BOTH entries. It's a pain. +--------------- Uh, Peter, is SCO Xenix *really* so broken that O_NDELAY and/or CLOCAL don't work? I've used them in Microsoft Xenix 3.x (untouched by SCO) and UNIX System III; they work fine. fd = open("/dev/ttyxx", O_RDWR|O_NDELAY); ioctl(fd, TCGETA, &ttyinfo); ttyinfo.c_cflag |= CLOCAL; ioctl(fd, TCSETA, &ttyinfo); fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) & ~O_NDELAY); signal(SIGALRM, timeout); alarm(120); /* send the dial command to the modem */ ttyinfo.c_cflag &= ~CLOCAL; ioctl(fd, TCSETAW, &ttyinfo); /* wait for response; timeout() catches failure */ I've never understood why SCO uses the two-file kluge. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
guy@auspex.auspex.com (Guy Harris) (04/18/89)
>Hmmm. A technical point on this... measurements I have made on a Sun-3/260 >with both mti and zs serial ports is this: > > DCD - when low, prevents the Sun driver from receiving data. Any > data received in this state is ignored. > Opening the cua device when DCD is low succeeds but you > can't hear anything! > ie: tie Sun-DCD to Sun-DTR so that you can always hear things > when the device is open (either via cua or tty open). This has not been the default case on the zs ports for quite a while; I assume you ran it on a port with RTS/CTS flow control enabled. (I think RTS/CTS may have been enabled by defaul on very old systems; there are patches to enable it on all ports on SunOS systems up to 4.0, and there is a flag bit that controls it that's settable with "ioctl"s on 4.0.) Were it unconditionally true on all ports, our system wouldn't be successfully dialing out to "uunet", and you wouldn't be reading this article.... This may be true on the MTI ports, since Systech used the Signetics 2661 EPCI chip, which *always* shuts the receiver off when DCD goes down. The Zilog 8530 chip used on the zs ports (and ALM-2 ports) allows this to be turned or off; turning it on also turns RTS/CTS flow control on. The patch mentioned in the previous paragraph causes this to be turned on for all ports; the "ioctl" bit in 4.0 turns it on for a particular port. > DSR - when low, prevents the Sun driver from allowing open's on > the device to complete (unless O_NDELAY is specified or > the kernel is configured to ignore "carrier" or a cua open is > attempted). > ie: tie Sun-DSR to remote-DTR so that the tty open succeeds > when a connection to the remote happens. This is true only on the MTI ports. Systech and Sun compensated for the 2661's obnoxiousness by making DSR be the line that is treated as "carrier detect", and wiring CD high. > CTS - when low, prevents the serial chip from sending data iff: > > - the zs driver has been patched to set the bit in the > scc that enables hardware flow control > (patch needed at least on SunOS 3.whatever) If the bit in the scc is not set, DCD doesn't have to be high in order to receive data; see above. This bit is *not* set by default. I'll bet you applied the patch, which forcibly sets the bit on all ports, since you claim that DCD *must* be high in order for the receiver to work. > - using the mti driver, in which case hardware flow control > is on all the time, regardless of kernel running. Even if you write your own driver, this will still be the case - it's a characteristic of the chip see above.
guy@auspex.auspex.com (Guy Harris) (04/18/89)
>The parent of 'sh' has to be init, because that is the only indication that >the program has that it is the login shell as apposed to a shell called >by another program/shell. Nonsense. The closest thing to a "standard" indication that a shell is a login shell, in UNIX, is that argv[0] (or the last component thereof) begins with "-". Neither the Bourne nor the C shell, in S5 or 4.xBSD, check the parent process ID; they both check whether "argv[0]" begins with "-". >I suspect it is also the one that sends hangup signals to all other processes >in the same process group etc. This sentence has a dangling reference; "it" in "it is also the one that sends hangup signals" doesn't refer to anything obvious. In S5, the hangup signal that's sent to all other processes in a process group when the process group leader exits is sent by the kernel. A process group leader is defined as a process whose process ID is equal to its process group ID; for the signal to be sent, the process must also have a controlling tty, and that controlling tty's process group must be the process group of the process in question. Having a parent process ID of 1 has nothing to do with it.
doug@letni.LawNet.Com (Doug Davis) (04/19/89)
In article <13570@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <3774@ficc.uu.net> by peter@ficc.uu.net (Peter da Silva): >+--------------- >| We do it this way on Xenix 3.5, because it's the only way to do it, and I'm >| having to rewrite init to track this multiple-tty-name stuff and clear >| BOTH entries. It's a pain. >+--------------- > >Uh, Peter, is SCO Xenix *really* so broken that O_NDELAY and/or CLOCAL don't >work? I've used them in Microsoft Xenix 3.x (untouched by SCO) and UNIX >System III; they work fine. Sorry Brandon, that piece of code won't work under SCO given the conditions described by the original article. If you have a process sitting on a port i=open("/dev/ttxx", O_RDWR) so it is blocked waiting for a carrier. You have to do some real bizzaro-twists to make a dialer dial out across it. This is from memory, it should be fairly close.... /* * Open the tty */ tty = open("/dev/ttyxx", O_RDWR | O_NDELAY); (void) fcntl(tty, F_SETFL, fcntl(tty, F_GETFL, 0) & ~O_NDELAY); if (ioctl(tty, TCGETA, &ttystuf) != 0) (void) boom(); /* set all the flags stuff up */ ttbuf.c_cflag |= CLOCAL; (void) ioctl(tty, TCSETA, &ttystuf); tmptty = open (dcname, O_RDWR); if (tmptty > 0) { close(tty); tty = tmptty; } /* * Now 'tty' is set up correctly and you can dial out... */ The "trick" lies in the open/close the second open is the fd that is set correcty. What's real fun is the original processes never unblocks and now, never will. Even when you force carrier onto the port. If there is interest I can provide info on how to make a 'uugetty' work. (you won't like it either, but it does work) About a year ago, myself and some people I worked with reported this to SCO, I suspect nothing has been done about it since all the new stuff I have from them *STILL* has the same buggy tty drivers. --- Doug Davis/LawNet/1030 Pleasant Valley Lane/Arlington/Texas/76015/817-467-3740 {sys1.tandy.com, motown!sys1, uiucuxc!sys1 lawnet, killer, texbell} letni!doug Same siggie, .9832% less filling..
david@ms.uky.edu (David Herron -- One of the vertebrae) (04/19/89)
In article <1446@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>The parent of 'sh' has to be init, because that is the only indication that >>the program has that it is the login shell as apposed to a shell called >>by another program/shell. >Nonsense. The closest thing to a "standard" indication that a shell is >a login shell, in UNIX, is that argv[0] (or the last component thereof) >begins with "-". Neither the Bourne nor the C shell, in S5 or 4.xBSD, >check the parent process ID; they both check whether "argv[0]" begins >with "-". Further ... on systems running X to "log into" some other system you commonly do rsh host xterm -display host:0.0 blah blah and one of the options to xterm is to make it a "login window". It does this by putting that '-' in argv[0]. But the xterm process stays there between the shell and init, the shell's parent is *NOT* init. And if you think about it long enough, the shells parent *CANNOT* be init since xterm has to get all these characters going in and out of the window and to X type things with them. For that matter, rlogin works similarly... -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- The problem with mnemonics is they mean different things to different people.
steve@nuchat.UUCP (Steve Nuchia) (04/19/89)
In article <13570@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <3774@ficc.uu.net> by peter@ficc.uu.net (Peter da Silva): >| We do it this way on Xenix 3.5, because it's the only way to do it, and I'm >| having to rewrite init to track this multiple-tty-name stuff and clear This can also be done in getty; pretty easy there, just clear it all before you try the open, then set the locks and whatever else when the open returns. When you find a lock set use kill 0 to see if it's real or memorex. >Uh, Peter, is SCO Xenix *really* so broken that O_NDELAY and/or CLOCAL don't >work? I've used them in Microsoft Xenix 3.x (untouched by SCO) and UNIX >I've never understood why SCO uses the two-file kluge. It can be a real bitch to add O_NDELAY to an open call for which you do not have source. Why you might not have source is an excersize best left to another newsgroup. I do not have source for my uucico, for instance. My vendor does, but chooses to ignore the fact that they do. I would ignore them except I'm poor and hate DOS. The file-name "kludge" is a useful, understandable, managable solution, and is at least as "right" as O_NDELAY. Use of minor device bits to control things, like for instance tape density, that application programmers failed to include ioctls or special open flags for goes back a long way. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
david@ms.uky.edu (David Herron -- One of the vertebrae) (04/21/89)
In article <3914@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <11536@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >> if you think about it long enough, the shells parent *CANNOT* be init >> since xterm has to get all these characters going in and out of the >> window and to X type things with them. > >Why does the shell's parent have to be xterm to satisfy this requirement? As I described before -- xterm's job (and that of rlogind as well) is to handle the characters going in and out of the terminal session. On systems with which I am familiar characters flow in/out of a /dev/tty thing directly to the process(es). With xterm/rlogind it is the same except it's a /dev/ttyp thing. Also the characters, instead of going out a physical device (or in to the physical device) go out (or in) another process -- xterm or rlogind. The xterm & rlogind processes are conventionally the parent of the shell because they take on the task of crafting up the environment surrounding the pty. Also they need to know when the child exits so that they can clean up after themselves. This is most easily done if they are the partent of the shell so that they receive SIGCHILD (SIGCLD) and/or SIGHUP signals. Or so that wait()'s return. Or whatever exact mechanism is being used. But right now I can't think of a good reason why it *MUST* be the way it is now. I can envision that init could treat the pty's as any other terminal device with a process hanging on 'em that'd start up a /bin/login when the other end of the pty was opened. But then we wouldn't be able to just use a pty without having to log in. No more *shell* windows in Emacs, no more script(1), no more rlogin with .rhosts allowing you an automagic login. -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- The problem with mnemonics is they mean different things to different people.
peter@ficc.uu.net (Peter da Silva) (04/21/89)
In article <11549@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > In article <3914@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >Why does the shell's parent have to be xterm to satisfy this requirement? > As I described before -- xterm's job (and that of rlogind as well) is > to handle the characters going in and out of the terminal session. Yes. > The xterm & rlogind processes are conventionally the parent of the > shell because they take on the task of crafting up the environment > surrounding the pty. Conventionally. But they don't have to be... in fact they don't even have to be related: they could be spawned by parents that know the names of the virtual devices. But even if they are related it doesn't have to be parent- child. > Also they need to know when the child exits so that they can clean > up after themselves. This is most easily done if they are the partent > of the shell so that they receive SIGCHILD (SIGCLD) and/or SIGHUP > signals. They can also get SIGPIPEs when the child goes away. > But right now I can't think of a good reason why it *MUST* be the > way it is now. I can envision that init could treat the pty's as > any other terminal device... > But then we wouldn't be able to just use a pty without having to > log in. Why not? INIT isn't magic... any program could set up the two procs and kick them off, just as they do with pipes now. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
allbery@ncoast.ORG (Brandon S. Allbery) (04/22/89)
As quoted from <1438@auspex.auspex.com> by guy@auspex.auspex.com (Guy Harris): +--------------- | >init execs getty; getty execs login; login calls back and execs the real | >login. There's some reason I have to have the parent of 'sh' be init, though | >I don't recall what it was, it didn't work if it wasn't done that way. | | In that case, your "sh", or something, is broken. The SunOS version | doesn't have this problem; otherwise, neither "rlogin" nor TELNET would | work very well, since the login shell on a remote login is a child of | the rlogin or TELNET daemon, not a child of "init". +--------------- May I suggest that the real reason it broke was that the login shell wasn't leader of the process group that owns the terminal? This would likely cause various nasty things to happen wrt. signals, perhaps (I'm not well-versed in this subject, but it seems quite possible) especially job control. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
guy@auspex.auspex.com (Guy Harris) (04/25/89)
>May I suggest that the real reason it broke was that the login shell wasn't >leader of the process group that owns the terminal? If that's the real reason it broke, then the scheme Peter was saying wouldn't work (which really meant "wouldn't work on his system", since login shells that are not children of "init" work fine on other systems) *would* work - "ct" can most definitely arrange that the process it forks off to run "getty" becomes the leader of the process group that owns the terminal. In fact, it does precisely that; before "exec"ing "getty", it calls "setpgrp".