Re: Fixed! (Re: mgetty isn't answering the phone (ioctl problem))
> I use DCON.. its DCON that can't OPEN the port... pppd works fine, and
> mgetty work fine.. but its DCON that can't share the port...
That would happen if DCON is trying to open, say, /dev/cua0, rather
than /dev/ttyS0. mgetty will get in the way of that. The Serial Gods
could tell you a lot more than I can, but I do know that if everyone
uses ttyS<n> then everyone is happy. I don't know what DCON is, but
perhaps you can reconfigure it.
Part of reconfiguring it is to make sure it obeys the locking
conventions; as far as I know all the cua<n> devices did for you was a
kernel-level lock, rather than the cooperative, user-space method used
by programs sharing ttyS<n>.
Gorier detail: mgetty does a select() on ttyS0, waiting for the modem
to do something (e.g., emit "RING"). Because mgetty has ttyS0 open,
trying to open cua0 fails (or blocks, perhaps), which is presumably
what's happening with DCON. But you can still open ttyS0, and use it;
the first time you cause the modem to emit any characters, mgetty's
select() returns, and if mgetty finds that someone else has written a
lockfile it quits. If someone hasn't written a lockfile, then mgetty
writes the lockfile itself and tries to make sense of what the modem
is saying (usually "RING", but maybe "AT..." if your program is trying
to use the modem without having written the lockfile).
The moral being that your program should open ttyS0, but if it hasn't
written a lockfile before it talks to the modem, your program and
mgetty will trip over each other trying to converse with it.
--
Pete Harlan
pete@mymenus.com
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: