cbp@foster.avid.OZ (Cameron Paine) (09/05/89)
We've recently upgraded to HP-UX 6.5. Prior to the upgrade, we were
running three CCITT compliant V.22 modems attached to the modem ports
of the four-channel MUXes (we have 8 MUXes in all). We were using the
modem(7) interface for ACU control, dial-out and dial-in access to
the ports. The device files were configured in SIMPLE mode (because
CCITT mode appeared not to work). This configuration had been working
fine since I set it up under 5.5.
Under 6.5, this arrangement will only work *once* for each port when
the system is rebooted. After that, getty sleeps forever (in an
interruptable state (TTIPRI?)) and refuses to enter a dialogue with
an incoming call. Does this sound familiar to anyone? (If so, read on)
I've tried a variety of experiments and am able to describe the symptoms
of the problem in considerable detail. I'll not post these here but I
am willing to email them to anyone who thinks they have an answer but
needs more detail.
There were some difficulties with the upgrade process and HP seem to be
concentrating their efforts to locating the flaw in the way we completed
the upgrade. I acknowledge that the problem could be due to a cockup on
our part. However I'd like to get some parallel thinking happening. This
has really crippled our operation.
Can anyone help me out? Please respond via email - this is not likely to
be of general interest. And *please*, no speculation or confirmation that
this works on your system. I know it does; that's what's driving me nuts!
--
cbp@foster.avid.oz - {ACS,CS}net
cbp%foster.oz.au@uunet.uu.net - ARPAnet
...!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!foster.oz.au!cbp - UUCP
Djand@maestro.htsa.aha.nl (Jan Derriks) (02/19/91)
HELP !
After reading modem(7) 77 times, I'm still having trouble
with the callin/callout/acu lines regarding DTR behaviour.
PROBLEM: when an open(2) on the dial-out line (cul2p0) fails because
there is no connection yet (DCD inactive), the DTR signal
becomes INACTIVE ! Is this normal ? When the open succeeds
and the line is closed, the DTR is dropped and re-raised.
We need DTR to reset the modem and to answer incoming calls.
System: HP-UX htsa A.B7.00 C 9000/835 18329
Details:
I use the three terminal type files
/dev/cua2p0 to dial and make an outgoing connection
/dev/cul2p0 to talk once the connection is set up
/dev/ttyd2p0 where the getty is waiting for DCD to come
just as the manual describes.
The CCITT mode ("use it if you are living in Europe, says SAM") hung
up all the lines until a system reboot, so I chose the 'SIMPLE' modem
control mode (recommended for people in USA or Canada). If anyone
knows how to fix a hanging CCITT device driver without a reboot I'd be
pleased to hear from her/him. Setting+dropping <status> didn't help.
Simple mode is an improvement, but look what happens if uucico dials
out (using dialers script, not dialit.c) and fails:
1. uucico acquires /dev/cua2p0, the ACU line to dial the number.
2. suppose the line is busy and we don't get DCD
3. uucico tried to open /dev/cul2p0 anyway (why?) and fails,
4. causing DTR to drop and stay inactive, causing
5. the modem not to answer incoming calls.
I now use a cron job to set DTR if it's not set but it seems to me that
a failed open shouldn't keep DTR low. What's going wrong ?
Jan Derriks.
-- jthomas@nmsu.edu (James Thomas) (02/21/91)
In article <2757@maestro.htsa.aha.nl> jand@maestro.htsa.aha.nl (Jan Derriks) writes:
jan> HELP !
jan> After reading modem(7) 77 times, I'm still having trouble
jan> with the callin/callout/acu lines regarding DTR behaviour.
modem(7) didn't help me either :-(
jan> PROBLEM: when an open(2) on the dial-out line (cul2p0) fails because
jan> there is no connection yet (DCD inactive), the DTR signal
jan> becomes INACTIVE ! Is this normal ? When the open succeeds
jan> and the line is closed, the DTR is dropped and re-raised.
jan> We need DTR to reset the modem and to answer incoming calls.
jan> ...
jan> I use the three terminal type files
jan> /dev/cua2p0 to dial and make an outgoing connection
jan> /dev/cul2p0 to talk once the connection is set up
jan> /dev/ttyd2p0 where the getty is waiting for DCD to come
jan> just as the manual describes.
My situation was not the same, but it involved similar problems (scattered
information in manuals, missing information in manuals :-(
I couldn't get a modem line to work (on an 840 with 7.0?) by hanging up
when the line was disconnected. I happened on lssf and mksf (not mkfs :-)
by flipping through manuals looking for other things. Ahha, /dev/cua0p1
didn't have the "I'm a modem line" bit set. (I have no idea where that
device entry came from to begin with...) OK, I'll say it's a modem line
and that will fix everything, right? Wrong.
Next try. "Well, let's try running getty on cua0p1 instead of tty0p1?"
Gee, that's interesting, w shows getty running on tty0p1 still (yes, after
telinit :-). "How about if we delete /dev/tty0p1?" Bingo! The modem bits
now worked, and the modem hung up when carrier dropped.
This might apply to your situation, too. Could an hp guru with sources
explain this? Could an hp manual writer add a section with a better setup
explanation???? Pretty Please???
While I'm at it, I wrote a program to watch the modem control bits on
/dev/cua0p1 and output them. It only worked for a process logged in on
/dev/cua0p1 ??? Even root got 0x00000000 back from the "read the modem
bits ioctl" unless it was logged in on the line. Why??? Is this an
undocumented appearance of A1 security already ?-)
Jim at jthomas@wsmr-emh89.army.mil@wsmr-emh82.army.mil (until routing
happens :-)franks@hpuamsa.neth.hp.com (Frank Slootweg CRC) (02/21/91)
> PROBLEM: when an open(2) on the dial-out line (cul2p0) fails because > there is no connection yet (DCD inactive), the DTR signal > becomes INACTIVE ! Is this normal ? This is not normal (in simple mode) and I think even impossible: For simple mode an open(2) will raise DTR and wait *for ever* (manual says: no connection timer is started) untill DCD is raised. So an open(2) on a simple mode device file can not fail (except for things like absent device file, wrong major/minor number, wrong mode/UID/GID, i.e. not related to the RS232 stuff). If some program seems to fail on an open(2) of a simple mode device file then it is probably doing something else than you think it does. We had a similar case with "cu(1)". I don't remember the exact details, but it went something like: "cu(1)" open(2)s a *direct connect* (i.e. non-modem) device file and then does some ioctl(2) magic (see "modem(7)") to set and get some modem lines. In this case the open(2) does *not* wait for DCD and when the get ioctl(2) does not see f.e. DCD then the *program* might say something like "open failed". It will probably not say "open(2) failed", because that would be lying. So the problem in the "cu(1)" case is caused by the fact that the innocent user thinks that "cu(1)" does an open(2) of a modem device file while it actually does an open(2) and ioctl(2) of a direct connect device file. Your problem might be similar. So my suggestion is to write a little program yourself which does an open(2) of the modem device file and check if the RS232 lines react in the way that "modem(7)" says they should. Of course a simple "sleep 3600 </dev/simple_mode &" will also do the trick. Hope this helps. Frank Slootweg, Hewlett-Packard, Dutch Customer Response Center.
gerwitz@Kodak.com (Paul Gerwitz) (02/22/91)
In article <675@opus.NMSU.Edu> jthomas@nmsu.edu (James Thomas) writes: >In article <2757@maestro.htsa.aha.nl> jand@maestro.htsa.aha.nl (Jan Derriks) writes: > ....[ lot's of detail deleted ] >Jim at jthomas@wsmr-emh89.army.mil@wsmr-emh82.army.mil (until routing >happens :-) Could either one of you post the 'ls -l' for the device files that you use as well as the inittab entries. I am having a similar problem but can't quite get it to work the same way. Before I 'cast stones' I want to make sure that I am set up the same way. (Have an 835 at 7.0) -- +----------------------------------------------------------------------------+ | Paul F Gerwitz WA2WPI | SMTP: gerwitz@kodak.com | | Eastman Kodak Co | UUCP: ..uunet!atexnet!kodak!eastman!gerwitz | +----------------------------------------------------------------------------+
perry@hpfcdc.HP.COM (Perry Scott) (02/22/91)
Re: modem(7) - what it REALLY says. In CCITT callin mode, the driver waits for Ring Indicate, then raises DTR (and CTS ? I'm foggy on that). When DSR and RTS comes up, the open() completes. In CCITT callout mode, the driver simply raises DTR, and waits for DSR and RTS. In SIMPLE mode, the driver raises DTR and waits for DSR, regardless of callin/callout bits. In CCITT mode, there are several timers that are activated. The one giving you problems is probably MTCONNECT, which defaults to 25 seconds. If you don't connect with that period of time, the open fails. I think this is because some modems actually take the phone off-hook when the computer raises DTR. Most phone companies frown on this, hence the existence of the timer. If you really want to disable the timer, set it to 0 with the MCSETT ioctl. Sorry you had to read the man page so many times. Sometimes I think the engineers run this company. :-) Perry Scott HP Ft. Collins, CO, USA
mat@emcard.UUCP (W Mat Waites) (02/22/91)
In article <675@opus.NMSU.Edu> jthomas@nmsu.edu (James Thomas) writes: > >"How about if we delete /dev/tty0p1?" Bingo! The modem bits >now worked, and the modem hung up when carrier dropped. I tried this technique on an 835 running 7.0 and did not get the desired results. Has anyone out there got a short synopsis of how to get modem control working (dial in, hang up, computer log you out; dial in, log out, computer drops dtr to hang up)?? Apparently the 3/4xx and 8xx techniques are slightly different. Thanks, Mat -- W Mat Waites | Walking the wire is living, {gatech,emory}!emcard!mat | the rest is just waiting. - Wallenda
jand@htsa.htsa.aha.nl (Jan Derriks) (02/24/91)
In article <28510025@hpuamsa.neth.hp.com> franks@hpuamsa.neth.hp.com (Frank Slootweg CRC) writes: >> PROBLEM: when an open(2) on the dial-out line (cul2p0) fails because >> there is no connection yet (DCD inactive), the DTR signal >> becomes INACTIVE ! Is this normal ? > > This is not normal (in simple mode) and I think even impossible: For >simple mode an open(2) will raise DTR and wait *for ever* (manual says: >no connection timer is started) untill DCD is raised. So an open(2) on a >simple mode device file can not fail (except for things like absent device >file, wrong major/minor number, wrong mode/UID/GID, i.e. not related to >the RS232 stuff). > OOPS! I see Frank is a CRC man and knows what he's talking about. (In contrary to Perry Scott who can only summarize manual pages). The problem description is not correct. I said 'when the open fails DTR is dropped', but I mean 'when the open does not succeed and is aborted DTR is dropped'. Failing is not the same as not succeeding of course. As the manual says, an open on a simple non-direct dial-out line wil wait until DCD arrives, but that's OK. The problem is, when you interrupt the open. *THEN* DTR stays low. And it's uucico that starts a time-out timer when the open of the dial-out line takes too long because the other end was busy or something. I'll give an even more detailed description of what happens and include inittab, devices and device numbers: Problem: with a getty on ttyd2p0 (the getty's OPEN should be responsible for raising DTR), DTR is dropped when a OPEN(2) of cul2p0 (with O_NDELAY *NOT* set) is interrupted/aborted. Reproducable by: 1. having simple tty line device numbers like: crw-rw---- 1 uucp staff 1 0x000200 Feb 21 13:45 /dev/cua2p0 crw-rw---- 1 uucp staff 1 0x100200 Feb 23 18:00 /dev/cul2p0 crw--w--w- 1 jand staff 1 0x200200 Feb 23 18:33 /dev/ttyd2p0 2. A getty on the dial-in line /dev/ttyd2p0 (spawned by init) inittab entry: a0:2:respawn:/etc/getty -h -t 60 ttyd2p0 19200tb (gettydefs entry 19200tb for telebit modem not important) 3. No pending opens besides the getty on /dev/ttyd2p0 4. TRY THIS IF YOU WANT TROUBLE: echo driverbugithink > /dev/cul2p0 (interrupt this. Output:) /dev/cul2p0: cannot create The interrupted open of /dev/cul2p0 makes it impossible for getty to re-raise DTR (Give me the driver sources and I'll fix it ;-). Workaround: experimental 'gekloot' (dutch) has shown that three things make DTR re-appear: a. an ioctl to the direct line (works BAD; getty's open wont work) b. an open("/dev/cul2p0", blabla | O_NDELAY) (works bit better). Strange isn't it ? With NDELAY you are allowed to open a line, which shouldn't be allowed to be opened until DCD appears. [Hey Perry Scott, can you tell me in what manual I can find that?] c. (Currently trying) open("/dev/ttyd2p0", O_WRONLY|O_NDELAY). You can also try echo foo>/dev/ttyd2p0 and abort it. Preliminary conclusion: It seems that the getty's OPEN of the call-in line needs help when an open of the higher priority line is aborted. Getty's open (in fact that piece of driver code that should reraise DTR when a higher-priority line drops it at close) seems to miss the fact that DTR has dropped when the higher priority open is aborted. Fortunately (?), when the open of cul2p0 is never aborted you won't have any trouble. Unfortunately our UUCICO fails many times (bad line) in maintaining the connection (made via cua2p0 direct line) and when I see uucp hp4nl (2/21-10:03:28,27175,0) TIMEOUT (generic open) uucp hp4nl (2/21-14:03:28,2055,0) TIMEOUT (generic open) uucp hp4nl (2/22-18:03:23,24827,0) TIMEOUT (generic open) in the 'uulog', the wrong has been done and people start complaining that the modem would not answer their call. (BTW when the next time uucico succeeds in calling out, the situation is solved because the line is closed properly. This is the case when you verify the complaints :-). Hello, is there anybody still reading this ? >Frank Slootweg, Hewlett-Packard, Dutch Customer Response Center. Sorry to be a bit vague the last time, Frank. I have never had the pleasure of HP Customer Response before. I hope 100 lines is enough ? Jan Derriks. [recently promoted to local modem interface guru]