Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!htsa!jand
From: jand@htsa.htsa.aha.nl (Jan Derriks)
Newsgroups: comp.sys.hp
Subject: Re: modem(7) DTR question HELP!
Message-ID: <100@htsa.htsa.aha.nl>
Date: 23 Feb 91 18:32:11 GMT
References: <2757@maestro.htsa.aha.nl> <28510025@hpuamsa.neth.hp.com>
Organization: Polytechnical Institute AHA-TMF, Amsterdam, The Netherlands
Lines: 88

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]


Brought to you by Super Global Mega Corp .com