Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!hplabs!hpcc05!hpgva1!hpuamsa!franks From: franks@hpuamsa.neth.hp.com (Frank Slootweg CRC) Newsgroups: comp.sys.hp Subject: Re: modem(7) DTR question HELP! Message-ID: <28510025@hpuamsa.neth.hp.com> Date: 21 Feb 91 13:10:10 GMT References: <2757@maestro.htsa.aha.nl> Organization: HP-Sales Office-The Netherlands Lines: 37 > 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