HylaFAX The world's
most advanced open source fax server
|
|
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
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