dlong@sdsu.UUCP (Dean Long) (09/23/86)
I can't get tip (cu) to work. The problem is that it can't open() the tty device. This device is used by uucp with no problems. I looked at some of the code for uucp. I saw that uucp uses /dev/kmem to to "enable" and "disable" the device before attempting an open. To me it looked like it was just setting some bits. Is this really necessary? By the way, when tip tries to open the device, it just waits. After 10 seconds, an alarm goes off and tip knows the open() didn't work. It doesn't return immediately with a -1 or something. Also, the protection on the device is OK. Any ideas?
steve@gec-mi-at.co.uk (Steve Lademann) (09/25/86)
In article <26@sdsu.UUCP> dlong@sdsu.UUCP (Dean Long) writes: > > I can't get tip (cu) to work. The problem is that it can't open() the >tty device. That's probably because the Carrier Detect (DCD) line from the modem is not asserted and the terminal line is 'config'ed with modem support. Symptoms are that the open hangs until timed out. >This device is used by uucp with no problems. I looked at >some of the code for uucp. I saw that uucp uses /dev/kmem to to "enable" >and "disable" the device before attempting an open. To me it looked like >it was just setting some bits. Is this really necessary? The code that does the bit twiddling actually *disables* the modem control by setting a bit in the software carrier array to indicate to the driver that it should regard Carrier Detect as being permanently set. You can also do the same thing at 'config' time by setting the appropriate bit in the 'flags' word for that particular terminal controller. This code also normally turns off the 'getty' running on that terminal line using a variety of methods. The one employed by 4.2BSD (what we run here) is to edit /etc/ttys to disable the terminal line and send a SIGHUP to init to get rid of it. If you don't do this, then getty can start arguing with uucp and produce all sorts of strange results! When uucp has done its thing, the whole thing is vice versaed to enable modem control and restore the getty on the terminal line. I believe that System V, 4.3BSD and Ultrix 1.2 have (different, of course) ways of achieving the same results. Your next question is fairly obvious. "Why naff about disabling modem control all the time? Why not just either set it or clear it?" The reason is that quite a lot of us poor lads out here can't afford to have separate lines for dailin and dialout. Now, for dialin, you *need* modem control (DCD detection, that is) otherwise, if the line gets dropped for any reason (e.g. crumby 'phone lines), your system won't know it's happened and doesn't know to log off the incoming user. On the other hand, for dialout, you *don't* need modem control, as with most modern auto-dial modems, you need to talk to the modem even though DCD is not asserted. The only danger here is that if the line gets dropped, your software should know what has happened, and act accordingly. For 'tip' this is fairly obvious; it goes very quiet. For uucp, it times out. So, to use 'tip' with your dialin/dialout line, you need to add similar code as that used in uucp. We use Bill Sebok's 'acu' program with uucp to enable/disable the terminal lines and also to check that a dialout line is not already busy handling a dialin, so that was quite easy to add to tip at an appropriate point in the connect procedure. You may also choose to write a dialer for your modem if you want it to be extra slick. On the other hand, you could just talk to the modem directly. We use both methods. The most frustrating thing to do is to intercept all the possible exits from tip, and to ensure that 'acu' is called again to enable getty and modem control. I just wrote a macro for 'exit' that did it all, and recompiled. (AAaaarrrgghhh!) (Hint: the first thing the subroutine called by the macro should do is #undef exit.) ----------------------------------------------------------------- |Steve Lademann |Phone: 44 727 59292 x326 | |Marconi Instruments Ltd|UUCP : ...mcvax!ukc!hrc63!miduet!steve | |St. Albans AL4 0JN |NRS : steve@uk.co.gec-mi-at | |Herts. UK | | ----------------------------------------------------------------- |"The views expressed herein do not necessarily reflect"| _____ | |"those of my employer, and may not even reflect my own"| ( ) | -----------------------------------------------------------------
dalem@hpfcph.HP.COM ( Dale McCluskey) (09/25/86)
Are you using the -m flag to CU? I had a very similar experience to yours until
I started including the -m flag. This is strange, because -m signifies Modem
control and my I/O board isn't supposed to have that. You might want to
try it, though.
Dale McCluskey
{ihnp4,hplabs}!hpfcla!dalemwls@astrovax.UUCP (William L. Sebok) (09/28/86)
In article <26@sdsu.UUCP> dlong@sdsu.UUCP (Dean Long) writes: > I can't get tip (cu) to work. The problem is that it can't open() the >tty device. This device is used by uucp with no problems. I looked at >some of the code for uucp. I saw that uucp uses /dev/kmem to to "enable" >and "disable" the device before attempting an open. To me it looked like >it was just setting some bits. Is this really necessary? As the one who originated this I feel I should comment. In my original posting on this subject (made several years ago) I had provided dialin/dialout mods to both uucico and to tip (4.2 BSD). Provided that your version hasn't changed too much from the stuff I did in that posting, what I say here should apply. I'm guessing that you are using the 4.3 BSD version. I am also guessing that in 4.3 BSD they forgot to provide similar dialin/dialout mods to tip as they applied to uucico. Enable/Disable device means to enable/disable logins on the device. In other words, contrary to your intuition, the device must be "disabled" before being used for dialing out. /dev/kmem is being poked to turn off modem control when the device is "disabled" and turn it on again when the device is "enabled". If modem control is not turned off when using a line for dialout, then when an attempt is made to open it, it will hang waiting for carrier on the modem. This is a problem, if one needs access to the modem to issue dialing commands and to read the modem's response. Ultrix has provided what I believe are the proper kernel hooks to accomplish this without poking /dev/kmem. One opens the device with the O_NDELAY option and then issues an ioctl to the device that allows one to talk to it in the absence of carrier. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,topaz}!astrovax!wls