Mike Richardson wrote:
>
> I've just been experimenting with puting a getty dialin on the same
> modem as diald uses to get out. I think I've probably done something
> wrong (which I'll see if I can sort) but it has provoked what I reckon
> must be a diald bug related to locking. The sequence is as follows:
>
> - start diald. diald sets /var/lock/LCK..cua3, to, say, 12345
> - start getty
> getty sets modem to autoanswer
> - poke link
> - diald connects
> ....
> - diald disconnects
> - getty gets SIGHUP and starts to reset modem; before this completes ...
> - diald tries to reopen /dev/cua3 and fails, so waits 30 seconds
> - getty completes setup to autoanswer
> - diald finishes wait, spots /var/lock/LCK..cua3, says
>
> "Device cua3 is locked by pid 12345"
>
> - diald waits 1 second, retries, waits, retries ....
>
> ie., we have a situation where diald is locked out by _itself_ !!!!!
>
> OOOPS ..... time to restart diald
>
> Fun, eh?
> Mike
When I started, I put a uugetty on ttyS2, and dialed out on cua2. The
uugetty program knows enough to stay out of the dialout programs' way until
a call actually comes in. When a call actually comes in, there will be no
other process locking the device, so when DCD comes up, uugetty will handle
the call without problems.
Just recently, I switched to using efax (so I could send/receive faxes as
well as dial in and dial out on the line). Since efax controls the line,
when it detects that an incoming call is a DATA call (as opposed to an
incoming FAX), I configured efax to start a getty (not a uugetty)
on the cua2 device to handle the incoming call. Seems to work pretty good.
efax is configured to lock the device, but removes its lock file until it
actually needs to use the device, leaving it available for other programs
(like kermit, getty, diald, etc).
--
Kevin J. Cummings
[EMAIL PROTECTED]
([EMAIL PROTECTED] is currently broken)
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
