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