Re: Newbie question on serial ports in Linux - please help!
Mikael Bendtsen wrote:
>
> Hi all!
>
> After reinstalling Debian Linux 1.1 I can't get my computer to speak
> with my modem (standard USR Sportser 33.6). When running Minicom or
> pppd nothing happens. Because I'm really a beginner at Linux I don't
> know where to look. It seems that my installation lacks serial
> communication support.
>
> And by which device should I call my modem which is connected to the
> second serial port? /dev/cua1 or /dev/ttyS1? Where can I find out more
> about this?
>
You should be able to get the kernel to load the serial module by
either A) enabling auto-loading by putting a line with the word
'auto' in /etc/modules or by B) explicitly requesting the serial
module be loaded by putting a line with the work 'serial' in
/etc/modules. That should do it.
As for using /dev/cua1 or /dev/ttyS1 the consensus seems to be to
use /dev/ttyS1. The main reason that I can see for this is that
the only way to insure proper device locking is to have all programs
(getty/mgetty, pppd for instance) use the same device file. The
historic reason for having more than one device is that getty's
(again, "historic/prehistoric" getty's) used to call open() on the
tty device, which had the characteristic that the open() system
call wouldn't return until the modem detected a carrier (after
auto-answering the phone) and hence raising the CD signal high on
the cable. Of course having this restriction on the tty device
made it so that you couldn't really use a modem with the device
since you need to talk to the modem before a connection is established.
Thus a cua device was created which had the characteristic that
open() would return with requiring CD to be high. In our modern
day we don't need this sort of requirement because A) more sophisticated
getty's have been developed, notable mgetty and B) because this
characteristic can be set for a serial line with parameters to
open(). Whew. At any rate nowadays if you open the modem line and
establish a connection the getty (well, some gettys) will return
with an open connection after carrier is detected and will then
check the locks directory to see if a device lock file exists and
if one does then it will sleep and wait for its next chance or
otherwise will proceed as if someone was trying to log in. Now it
becomes apparent why one device (/dev/ttyS1) should be used otherwise
if you use /dev/cua1 then the getty will look for a lock file with
ttyS1 as the name, not find it, and proceed with its login sequence.
That said, if you don't use that line for dialin (and thus don't
have a getty running for the line) none of this matters, but go
with the flow and use /dev/ttyS1 anyway. ;)
--
Jens B. Jorgensen
jjorgens@bdsinc.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: