Matt Birkholz wrote: > You shouldn't use /dev/cua1. Use /dev/ttyS1 instead. I changed minicom, > dip, mgetty+sendfax and other programs that use the modem to use > /dev/ttyS1 instead of /dev/cua1 and it works like a charm. > > Huh? I thought /dev/cua1 was the callout device and /dev/ttyS1 was the > callin device -- the one that blocks until CarrierDetect. Assuming > minicom, dip and "other programs" call out, they should use /dev/cua1, > while mgetty+sendfax and other getty's should use /dev/ttyS1. No?
That will only work if you use the modem auto-answer feature. Mgetty does not use auto-answer (it just waits for the RING messages). Here is what the mgetty author says about this: <<< *Important note:* Use the `/dev/ttyS*' devices for getty and for dial-out (that is, for kermit, uucico, cu, seyon, ...) - *never* use `/dev/cua*'. Dialing out on `/dev/cua*' will result in the error message "device busy". (There are reasons why `mgetty' cannot use the "`ttyS*' vs. `cua*' kernel locking mechanism", see below), and dialing in (ugh) on `/dev/cua*' will result in dozens of strange things happening because the process may not get a controlling tty. Some guys seemingly can't resist posting misinformation to the net all the time, don't believe 'em. The `/dev/cua*' devices are *not* different from the `/dev/ttyS*' devices concerning data flow or modem control lines. The only difference is how the device reacts if you do an `open()': Opening `/dev/ttyS*' normally blocks until the "carier detect" line goes active (unless `open()' is called with the `O_NDELAY' flag; `mgetty' and all dial-out programs do that), and opening `/dev/cua*' will return an error message (`errno=EBUSY') if another process has the device already open, thus *preventing dial-out on `/dev/cua*'* if `mgetty' is active on `/dev/ttyS*'. We use `/dev/ttyS*' all the time for dial-in *and* for dial-out, and believe me, it works, and it's the *only* combination that will work properly. The kernel locking mechanism only works if you use modem auto-answer (the getty process sleeps until the modem gets a carrier), and mgetty uses manual answer (it waits for the RING message from the modem), which will save your callers a lot of grief because their calls will only be answered if your computer is ready to receive a call. Part of the motivation for writing mgetty was being tired of losing lots of money for useless calls to a hung machine. <<< Peter -- Peter Tobias EMail: Fachhochschule Ostfriesland [EMAIL PROTECTED] Fachbereich Elektrotechnik und Informatik [EMAIL PROTECTED] Constantiaplatz 4, 26723 Emden, Germany
