tron@nsc.UUCP (04/08/87)
At nsc we have noticed a problem with our modem lines which is becoming
quite annoying. When somebody leaves a process in background and then
logs out the modem does not hangup. Then, when another call comes in on
that modem it does not answer. Everything seems to work correctly when
no background processes remain.
We are running 4.3BSD on a VAX-11/785, with Hayes Smartmodem 1200s connected
to DHU-11s. Modem control is enabled on the DHU-11 lines, and all switches
are up on the Hayes modems except 4 and 8, which are down. These are the
newer Smartmodems with 10 switches instead of 8. A typical session that
causes the trouble is:
% make >& make.out &
% logout
Please respond by mail if you have seen this before, know what might be
wrong or know how to fix this undesireable behavior.
Thanks in advance
--
tron |-<=>-| ARPAnet: nsc!tron@sun.COM
tron@sc.nsc.com UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron
(C)Copyr 1987 Ronald S. Karr; you can redistribute only if your recipients can.hartley@uvm-gen.UUCP (04/10/87)
In article <4183@nsc.nsc.com>, tron@nsc.nsc.com (Ronald S. Karr) says:
< Keywords: hayes modems 4.3bsd hangup
< Xref: uvm-gen comp.unix.wizards:1753 comp.unix.questions:1755
<
< ..... A typical session that causes the trouble is:
<
< % make >& make.out &
< % logout
<
A kludge is to "ask" everybody to do the following (redirect stdin also):
% make </dev/null >& make.out &
^^^^^^^^^^
% logout
That way the port is not open and the "last close" will really close.
--
Department of Computer Science and Elec. Eng. Stephen J. Hartley
USENET: {decvax,ihnp4,linus}!dartvax!uvm-gen!hartley University of Vermont
CSNET: hartley%uvm@csnet-relay (802) 656-3330, 862-5323mp@allegra.UUCP (04/12/87)
In article <29@sdeggo.UUCP>, David Smith writes: > It's because the modem lines only get > dropped when the *last* close (i.e. everything which has the port open > closes it) is done. As long as you have a background process running > it still has the port open, unless you disassociate it from the port > somehow. Our problem is getting the modem to behave correctly after the last process is done. This system (4.2bsd 750) has one dialup, a Ventel 1.something (we've tried several, a few 1.11's and the newer tan things) on a dz. That tty is used only for uucp. The problem we have is that sometimes the modem will keep the phone line off-hook INDEFINITELY. It seems to happen most often when the system that has just called us has an entry near the bottom of our Systems file, or isn't listed in it at all. In these cases, I imagine uuxqt takes awhile to run, even when there's nothing to xqt (the sites who actually call us turn out not to be high-volume sites). The way I currently unwedge things manually is to disable the tty in /etc/ttys, kill -1 1, pause 15 seconds, re-enable the tty, and kill -1 1. Or I press a button on the Ventel to reset it. I suppose I could have uucico do a TIOCNOTTY before the exec of uuxqt. It already looks like it's closing all its file descriptors. I dimly remember a long time ago that someone said that adding a sleep(5) in init would fix things. Does anyone remember this? Mark Plotnick allegra!mp
tron@nsc.nsc.com (Ronald S. Karr) (04/13/87)
In response to my query about modem hangup difficulties (article <4183@nsc.nsc.com>), I received a number of responses which pretty much verified what I was guessing was the problem, while also verifying that there is no easy answer other than user education. The most succinct response was from Chris Torek: >If you run `make </dev/null >& /dev/null &' and log out, all will be >well. If you rewrite vhangup(), that will fix it too: The problem is >that the virtual hangup vhangup performs is quite weak. Until the >process(es) that were attached to the terminal exit, the driver's >close routine never gets called. All vhangup does is revoke access; >it should sneakily alter file descriptors to point at /dev/null. > >Chris Thanks Chris and thanks also to the several others that responded to my query. The redirection of stdin, stdout and stderr to something other than the terminal solves the problem quite well, as long as users are properly informed that they need to do this, and as long as they remember. -- tron |-<=>-| ARPAnet: nsc!tron@sun.COM tron@sc.nsc.com UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron (C)Copyr 1987 Ronald S. Karr; you can redistribute only if your recipients can.
salzman@rdlvax.UUCP (Gumby) (04/21/87)
In article <4183@nsc.nsc.com> tron@nsc.nsc.com (Ronald S. Karr) writes: >At nsc we have noticed a problem with our modem lines which is becoming >quite annoying. When somebody leaves a process in background and then >logs out the modem does not hangup. Then, when another call comes in on >that modem it does not answer. Everything seems to work correctly when >no background processes remain. I have a solution to that problem that's been working well for a while, and has an added benefit: dialin security! It runs on a VAX 11/780 4.2bsd, should be pretty much the same on 4.3bsd.... The original intent was to provide extra security to dialin lines without hacking /bin/login itself (since I don't have source liscense :-(. It lies between getty and login and prompts for an additional password for dialin access and then fork()'s and exec()'s /bin/login. It maintains a very extensive log of ALL attempts to access the dialin lines, good or bad - which can easily be fed to awk for a nice report. Also multiple attempts are not allowed and the line is locked out to the same user name for a set period of time (or until root unlocks it). Now, for the solution to the problem: as I said, it fork()'s and exec()'s login, it doesn't just exec() it, meaning that when login finishes (i.e. when your shell exit()'s since it's execed from login) it makes an entry in the log file and forces a hangup on the line: tty.sg_ispeed = tty.sg_ospeed = 0; ioctl(0,TIOCSETP, &tty); /* HANG IT UP!! */ Get the idea? You always hangup, period, no matter what's running in the background. It has no adverse effects on background processes either, at least that I know of. I commonly run makes in the background and logout with no problems. If my line gets interrupted for any reason (somone calls and my call waiting hangs it - i HATE that :-), SIGHUP gets sent to all the children as it should and any forground process I have will get taken care of properly also.... I don't know if forking login as opposed to execing login has any wierd effects - I have yet to see any. I'd like to hear what some of the Guru's out there think of this.... Anyway, if anyone's interested in this stuff, e-mail me. If I get enough responses, I will clean it up and pack it off to mod.sources (or is it now comp.sources.unix), or net.sources, or I'll just mail to those interested if I get a few responses. Any thoughts on dialin security and other solutions are appreciated (those that don't involve hacking /bin/login). By the way I happen to believe that this one can't be cracked. If someone would like to try cracking it, I'll send them a copy... If it can be cracked, I'd like to know how, so I can fix it! :-) -Isaac Salzman. -- * Isaac Salzman - Systems Analyst ---- * Research Development Labs (RDL) /o o/ / * 5721 W. Slauson Ave. | v | | * Culver City, California, 90230 _| |_/ * AT&T: +1 213 410 1244, x118 / | | * UUCP: ...!{psivax,csun,sdcrdcf,ttidca}!rdlvax!salzman | | | * ARPA: rdlvax!salzman@SEISMO.CSS.GOV | |