![]() |
Jeff, just a guess: maybe you have to program your modem to dro the line if TDR dropps? Isn't it just ignroing DTR? Bernd > -----Original Message----- > From: jeff@wisdom.bubble.org [mailto:jeff@wisdom.bubble.org] > Sent: Friday, July 21, 2000 5:28 AM > To: hylafax-users@hylafax.org > Subject: Re: [hylafax-users] Modem not dropping DTR > > > I've been doing a little more probing on what's going on, the system is > actually dropping > DTR, however it is dropping too fast for the modem to identify a DTR > drop, I can identify the drop as a short "blip" on the DTR light. I > tried to reduce the time the modem requires to see a DTR drop before > it'll act upon it. However, I was unsuccessful as the drop is too > quick. > > I did adjust the ModemResetDelay command up as high as 10000, and > according to the tracelogs, faxgetty is lowering DTR for 10 seconds > > Jul 20 23:15:21 wisdom PAM_pwdb[15842]: (login) session closed for user > jeff > Jul 20 23:15:21 wisdom FaxGetty[15835]: GETTY: exit status 0 > Jul 20 23:15:21 wisdom FaxGetty[15835]: MODEM set DTR OFF > Jul 20 23:15:31 wisdom FaxGetty[15835]: MODEM set DTR ON > Jul 20 23:15:31 wisdom FaxGetty[15835]: MODEM set baud rate: 115200 > baud, input flow RTS/CTS, output flow RTS/CTS > Jul 20 23:15:31 wisdom FaxGetty[15835]: MODEM flush i/o > Jul 20 23:15:31 wisdom FaxGetty[15835]: <-- [4:ATZ\r] > Jul 20 23:15:36 wisdom FaxGetty[15835]: MODEM TIMEOUT: reading line from > modem > Jul 20 23:15:36 wisdom FaxGetty[15835]: MODEM <Timeout> > Jul 20 23:15:36 wisdom FaxGetty[15835]: MODEM set DTR OFF > Jul 20 23:15:46 wisdom FaxGetty[15835]: MODEM set DTR ON > > I'm guessing there is a timing issue someplace. some help from somebody > would really be appreciated! > > Thanks.. > > Jeff > > > Jeffrey Ross wrote: > > > > I've done a little more investigating and I'm now starting to point my > > finger at faxgetty (albiet probably incorrectly). > > > > It appears as if when a call comes in, faxgetty correctly does whatever > > modem controlling it needs to do and then passes the call off to either > > the getty or the fax program. What I believe is happening is faxgetty > > is somehow retaining some control of the port. This in turn is > preventing > > the DTR to drop since there remains 1 active process on the port. > > > > What I did to test this theory was after I connected (I allowed > faxgetty to > > accept the call and hand it off to getty) I stopped faxgetty by removing > > its entry in the inittab, and issuing an "init q". Upon > issuing an exit, I > > was promptly greeted with a "NO CARRIER" on my terminal, in otherwords > > DTR did get dropped. > > > > Is there something I missed in the configuration of faxgetty? I thought > > I followed the directions. Or are all my guesses off the mark? > > > > HELP!! > > > > Thanks. > > > > Jeff > > > > > > > > > > > The setup is as follows, hylafax-4.1beta2-5rh6.i386.rpm was installed > > > and configured, I am using faxgetty with the following line in > > > /etc/inittab: > > > > > > d1:345:respawn:/usr/sbin/faxgetty ttyD1 > > > > > > Modem: Multitech MT2834 > > > Serial port: Digiboard PC/8e (the standard PC serial ports have been > > > tried with the same results) > > > > > > O.S. RedHat 6.2 (originally) > > > Kernel 2.2.16 > > > > > > upon completion of a data call or a fax call, DTR is never dropped to > > > the modem. I have verified this not only by the light on the font of > > > the modem and using &D3 command, but with a serial line monitor that > > > lights up red or green when a line is high or low. > > > > > > the config.ttyD1 is attached below, it is essentually > unchanged from how > > > the modem config set it up. > > > > > > prior to receiving the call, an stty -a provides the following (with > > > faxgetty running): > > > > > > speed 115200 baud; rows 0; columns 0; line = 0; > > > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; > > > eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = > > > ^W; > > > lnext = ^V; flush = ^O; min = 1; time = 0; > > > -parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts > > > -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > > > -ixon > > > -ixoff -iuclc -ixany -imaxbel > > > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 > > > bs0 vt0 > > > ff0 > > > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh > -xcase -tostop > > > -echoprt -echoctl -echoke > > > > > > When a data call is established, the same command yields: > > > > > > speed 115200 baud; rows 0; columns 0; line = 0; > > > intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>; > > > eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = > > > ^W; > > > lnext = <undef>; flush = ^O; min = 1; time = 0; > > > -parenb -parodd cs8 hupcl -cstopb cread -clocal crtscts > > > -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon > > > -ixoff > > > -iuclc ixany -imaxbel > > > opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 > cr0 tab0 bs0 > > > vt0 ff0 > > > isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop > > > -echoprt > > > -echoctl -echoke > > > > > > notice hupcl is now set differently. > > > > > > If I kill faxgetty (remove the entry from inittab and do an > init q) and > > > then do an "stty -F /dev/ttyD1 hupcl", DTR will go low, suggestions > > > please??? > > > > > > HELP!!! > > > > > > thanks.. Jeff > > > > > > LongDistancePrefix: 1 > > > InternationalPrefix: 011 > > > DialStringRules: etc/dialrules > > > ServerTracing: 1 > > > SessionTracing: 11 > > > RecvFileMode: 0600 > > > LogFileMode: 0600 > > > DeviceMode: 0600 > > > RingsBeforeAnswer: 1 > > > SpeakerVolume: off > > > GettyArgs: "-h %l F115200 vt100" (*NOTE* the > F115200 line > > > in gettydefs > > > does > > > LocalIdentifier: "Jeffrey Ross" have HUPCL set) > > > ClocalAsRoot: yes > > > TagLineFont: etc/lutRS18.pcf > > > TagLineFormat: "From %%l|%c|Page %%p of %%t" > > > MaxRecvPages: 200 > > > # > > > # > > > # Modem-related stuff: should reflect modem command interface > > > # and hardware connection/cabling (e.g. flow control). > > > ## and hardware connection/cabling (e.g. flow control). > > > # > > > ModemType: Class2 # use class 2 interface > > > ModemRate: 115200 # lock rate for DCE-DTE > > > communication > > > ModemFlowControl: rtscts # default > > > # > > > ModemHardFlowCmd: AT&E4 # hardware flow control > > > ModemSoftFlowCmd: AT&E5 # software flow control > > > ModemSetupDTRCmd: AT&D3 # setup so DTR drop > resets modem > > > ModemSetupDCDCmd: AT&C1 # setup so DCD > reflects carrier > > > (or > > > not)ModemSetupAACmd: AT+FAA=1 # enable adaptive-answer in > > > class 2 > > > # > > > # NB: some models get confused by the @ > > > # > > > ModemDialCmd: ATDT%s@ # T for tone dialing, @ for > > > silence > > > # > > > Class2RecvDataTrigger: "\022" # character sent to modem to > > > start recv > > > > > > -- > > > .Sig??? you want a stinkin' .Sig??? > > > Jeff Ross > > > 973-463-0175 (home) jeff@wisdom.bubble.org > > > > > > > > > ____________________ HylaFAX(tm) Users Mailing List > _______________________ > > > To unsub: mail -s unsubscribe > hylafax-users-request@hylafax.org < /dev/null > > > > > > > > > > -- > > .Sig??? you want a stinkin' .Sig??? > > Jeff Ross > > 973-463-0175 (home) jeff@wisdom.bubble.org > > > > ____________________ HylaFAX(tm) Users Mailing List > _______________________ > > To unsub: mail -s unsubscribe > hylafax-users-request@hylafax.org < /dev/null > > -- > .Sig??? you want a stinkin' .Sig??? > Jeff Ross > 973-463-0175 (home) jeff@wisdom.bubble.org > > > ____________________ HylaFAX(tm) Users Mailing List > _______________________ > To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org > < /dev/null > ____________________ HylaFAX(tm) Users Mailing List _______________________ To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null