Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!paperboy!think.com!spool.mu.edu!news.cs.indiana.edu!ariel.unm.edu!nmsu!opus!jthomas From: jthomas@nmsu.edu (James Thomas) Newsgroups: comp.sys.hp Subject: Re: modem(7) DTR question HELP! Message-ID: <675@opus.NMSU.Edu> Date: 20 Feb 91 18:25:50 GMT References: <2757@maestro.htsa.aha.nl> Sender: news@NMSU.Edu Organization: NMSU Computer Science Lines: 49 In-reply-to: jand@maestro.htsa.aha.nl's message of 19 Feb 91 13:20:08 GMT 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 :-) Brought to you by Super Global Mega Corp .com