> 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 [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]