rich@tincan.sawyer.af.mil (Richard Wachter) (06/12/90)
Well here goes. I've got a AT&T 3B2/600g running UNIX System V 3.2. I have a Zenith modem connected to one of the tty ports. After many hours of trial and error it works just great. However if for some reason you lose the connection it does not log the person off. It does reset the modem but if you call back it doesn't ask for a login it takes you back to the same place you left. This is great if no one calls in between your disconnect and your reconnect. Cause if they do they become you and don't have to login. If anyone out there can help with this please send me some mail. SRA Richard Wachter rich@tincan.sawyer.af.mil (132.39.2.1) 2001csxp@sacemnet.af.mil (26.17.0.144)
smarc@wb3ffv.ampr.org (Marc Siegel) (06/15/90)
In article <23608@adm.BRL.MIL>, rich@tincan.sawyer.af.mil (Richard Wachter) writes: > > Well here goes. I've got a AT&T 3B2/600g running UNIX System V > 3.2. I have a Zenith modem connected to one of the tty ports. After many > hours of trial and error it works just great. However if for some reason > you lose the connection it does not log the person off. It does reset the > modem but if you call back it doesn't ask for a login it takes you back to > the same place you left. This is great if no one calls in between your > disconnect and your reconnect. Cause if they do they become you and don't > have to login. > If anyone out there can help with this please send me some mail. > > SRA Richard Wachter > rich@tincan.sawyer.af.mil (132.39.2.1) > 2001csxp@sacemnet.af.mil (26.17.0.144) Check the gettydefs entry you are using with uugetty. it should contain HUPCL in the entry. HUPCL causes the session to terminate (HANGUP) on close. You may want to make your own gettydefs entry for the modem although I think HUPCL should be in _all_ the entries. +--------------------------------------------------------------------------+ _ | Marc Siegel ' )--,--, | Randallstown, Maryland / / / __. __ _ | {uunet}!wb3ffv!mas!smarc / / (_(_/|_/ (_(_' | smarc@mas.wb3ffv.AMPR.ORG +--------------------------------------------------------------------------+
cpcahil@virtech.uucp (Conor P. Cahill) (06/16/90)
In article <3608@wb3ffv.ampr.org> smarc@wb3ffv.ampr.org (Marc Siegel) writes: >In article <23608@adm.BRL.MIL>, rich@tincan.sawyer.af.mil (Richard Wachter) writes: >> >> [ problem of system not logging out user when line is dropped deleted] > >Check the gettydefs entry you are using with uugetty. it should >contain HUPCL in the entry. > >HUPCL causes the session to terminate (HANGUP) on close. However, it requires that the port on which the user logs in to be set up in modem control mode (i.e. it requires DTR from the modem to enable the login). The loss of DTR is the mechanism used by the system to determine when the line is lost. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
bill@twg.UUCP (Bill Irwin) (06/16/90)
In article <1990Jun15.224120.27813@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > >However, it requires that the port on which the user logs in to be set up in >modem control mode (i.e. it requires DTR from the modem to enable the >login). The loss of DTR is the mechanism used by the system to determine >when the line is lost. I've always thought that it was the computer that asserted DTR when the port was enabled and ready to spawn a getty, as soon as CD is present. If DTR isn't true, the modem's auto answer is disabled until the port is ready (DTR true). Once the modem connects and asserts CD, the getty comes up. If the line is lost, CD goes, and any orphaned processes on the port are killed if HUPCL is on. Isn't this right or am I totally out to luch? -- Bill Irwin - TWG The Westrheim Group - Vancouver, BC, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ uunet!van-bc!twg!bill (604) 431-9600 (voice) | UNIX Systems Bill.Irwin@twg.UUCP (604) 431-4629 (fax) | Integration
david@cs.uow.edu.au (David E A Wilson) (06/16/90)
bill@twg.UUCP (Bill Irwin) writes: >I've always thought that it was the computer that asserted DTR when the >port was enabled and ready to spawn a getty, as soon as CD is present. >If DTR isn't true, the modem's auto answer is disabled until the port is >ready (DTR true). Once the modem connects and asserts CD, the getty >comes up. If the line is lost, CD goes, and any orphaned processes on >the port are killed if HUPCL is on. I have seen two ways in which DTR is used to control a modem. 1) With auto answer modems, computer asserts DTR and getty blocks waiting for DCD. When modem answers and detects carrier, it asserts DCD, getty unblocks and login message is displayed. User logs in. Either user logs out, in which case on final close DTR is deasserted for a short time causing modem to hang up. OR connection is broken, DCD from modem drops, shell gets hangup signal and closes port which again deasserts DTR briefly. The procedure then repeats. 2) With "dumb" modems the computer must monitor RI (ring indicate) After the appropriate number of rings are detected, DTR is asserted and the modem goes off hook and the connection is made with the remote modem. Again, the modem is hung up by deasserting DTR but this time until RI indicates another call is coming in. David Wilson david@wraith.cs.uow.edu.au