Faxgetty, Mgetty and data calls are driving me potty!
I've spent hours and hours trying to set up Hylafax/Faxgetty to auto
detect fax/data calls and respond appropriately.
I have had partial success in that I can now get it to distinguish between
fax and data calls and accept the fax or start a getty for a data call.
Part of my original problem was that the default config.ttyS1 GettyArgs
included -h as the first option which caused Mgetty to start and then
immediately stop after printing a 'Usage' line in the log.
My current config.ttyS1 gettyargs is:
GettyArgs: "-D %l dx_%s"
I have also tried "-r -s %s %l" together with many other combinations.
If I dial in from another machine the call is answered as a data call and
the getty started but on the machine that I dialled in from I see a line of
about two dozen characters, most of which appear to be '?', then the cursor
returns to the beginning of the line, overwrites part of the existing line
before dropping down one line, printing a few more characters then dropping
down another line and displays 'NO CARRIER'. I never get to see a login
prompt and these tests are costing me a fortune in telephone calls!
The getty on the Hylafax machine is left running and has to be killed.
My current config.ttyS1 gettyargs is:
GettyArgs: "-D %l dx_%s"
I have also tried "-r -s %s %l" together with many other combinations.
The mgetty log shows:
02/23 09:52:33 yS1 mgetty: experimental test release 1.1.21-Jul24
02/23 09:52:33 yS1 check for lockfiles
02/23 09:52:33 yS1 huh? It's *our* lock file!
02/23 09:52:33 yS1 locking the line
02/23 09:52:33 yS1 makelock(ttyS1) called
02/23 09:52:33 yS1 do_makelock: lock='/var/lock/LCK..ttyS1'
02/23 09:52:33 yS1 we *have* the line!
02/23 09:52:33 yS1 lock made
02/23 09:52:34 yS1 tio_get_rs232_lines: status: RTS CTS DSR DTR
02/23 09:52:34 yS1 tss: set speed to 115200 (10002)
02/23 09:52:34 yS1 tio_set_flow_control( HARD )
02/23 09:52:34 yS1 waiting for line to clear (VTIME), read:
02/23 09:52:34 yS1 send: \d\d\d+++\d\d\dATZ[0d]
02/23 09:52:37 yS1 waiting for ``OK''
02/23 09:52:37 yS1 got: [0d][0a]CONNECT[0d][0a][0d][0a]OK ** found **
02/23 09:52:43 yS1 waiting for line to clear (VTIME), read: [0d][0a]
02/23 09:52:43 yS1 removing lock file
02/23 09:52:43 yS1 waiting...
Although, in this section, the modem is reset I have tried other options
which give the following in the log:
02/23 09:40:20 yS1 mgetty: experimental test release 1.1.21-Jul24
02/23 09:40:20 yS1 check for lockfiles
02/23 09:40:20 yS1 huh? It's *our* lock file!
02/23 09:40:20 yS1 locking the line
02/23 09:40:20 yS1 makelock(ttyS1) called
02/23 09:40:20 yS1 do_makelock: lock='/var/lock/LCK..ttyS1'
02/23 09:40:20 yS1 we *have* the line!
02/23 09:40:20 yS1 lock made
02/23 09:40:20 yS1 tio_get_rs232_lines: status: RTS CTS DSR DTR
02/23 09:40:20 yS1 tss: set speed to 115200 (10002)
02/23 09:40:20 yS1 tio_set_flow_control( HARD )
02/23 09:40:20 yS1 waiting for line to clear (VTIME), read:
02/23 09:40:20 yS1 send: \dATQ0V1H0[0d]
02/23 09:40:21 yS1 waiting for ``OK''
02/23 09:40:21 yS1 got: [0d][0a]OK ** found **
02/23 09:40:21 yS1 send: AT[0d]
02/23 09:40:21 yS1 waiting for ``OK''
02/23 09:40:21 yS1 got: [0d][0a][0d][0a]OK ** found **
02/23 09:40:21 yS1 waiting for line to clear (VTIME), read: [0d][0a]
02/23 09:40:22 yS1 removing lock file
02/23 09:40:22 yS1 waiting...
I am running Debian 2.2 with kernel 2.2.18pre21, I have a Hayes Accura 56k
fax/data modem and I am running Hylafax version 4.0.2-14.
The machine that I'm dialling in from is running Windows 95.
I apologise in advance for that bit of important information that I have
almost certainly forgotten to include.
What am I doing wrong? Help would be very much appreciated.
I'm no longer subscribed to the list so any e-mail (see below) replies
would be welcome. I do follow the list in the Debian archives but that
lags behind by about a day. I have also read as much documentation as I
could find without any luck and have tried posting on two newsgroups but
have had no replies.
Barry Samuels
My real e-mail address is:
bsamuels (AT) datamansys (DOT) co (DOT) uk
Reply to: