You should make sure that your modem is correctly set up and that you know which serial port it is connected to.
Remember:-
It is also worth remembering that if you have 4 serial ports, the standard PC set up is to have com1 and com3 share IRQ4 and com2 and com4 share IRQ3.
If you have devices on standard serial ports that share an IRQ with your modem you are going to have problems. You need to make sure that your modem serial port is on its own, unique IRQ. Many modern serial cards (and better quality motherboard serial ports) allow you to move the IRQ of the serial ports around.
If you are running Linux kernel 2, you can check the in-use IRQs using
cat /proc/interrupts
, which will produce output like
0: 6766283 timer 1: 91545 keyboard 2: 0 cascade 4: 156944 + serial 7: 101764 WD8013 10: 134365 + BusLogic BT-958 13: 1 math error 15: 3671702 + serial
This shows a serial port on IRQ4 (a mouse) and a serial port on IRQ15 (the permanent modem based PPP link to the Internet. (There is also a serial port on com2, IRQ3 and com4 is on IRQ14, but as they are not in use, they do not show up).
Be warned - you need to know what you are doing if you are going to play with your IRQs! Not only do you have to open up you computer, pull out cards and play with jumpers, but you need to know what is on which IRQ. In my case, this is a totally SCSI based PC, and so I can disable the on motherboard IDE interfaces that normally use IRQ14 and 15!
You should also remember that if your PC boots other operating systems, moving IRQs around may well mean that OS cannot boot properly - or at all!
If you do move your serial ports to non-standard IRQs, then you need to
tell Linux which IRQ each port is using. This is done using
setserial
and is best done as part of the boot process in
rc.local
or rc.serial
which is called from rc.local
or as
part of the SysV initialisation. For the machine illustrated above, the
commands used are
/bin/setserial -b /dev/ttyS2 IRQ 11 /bin/setserial -b /dev/ttyS3 IRQ 15
However, if you are using serial modules dynamically loaded when
required by the kerneld
process, you cannot set and forget the IRQ
etc once at boot time. This is because if the serial module is unloaded,
Linux forgets the special settings.
So, if you are loading the serial module on demand, you will need to reconfigure the IRQs etc each time the module is loaded.
If you are using a high speed (external) modem (14,400 Baud or above), your serial port needs to be capable of handling the throughput that such a modem is capable of producing, particularly when the modems are compressing the data.
This requires your serial port to use a modern UART (Universal Asynchronous Receiver Transmitter) such as a 16550(A). If you are using an old machine (or old serial card), it is quite possible that your serial port has only an 8250 UART, which will cause you considerable problems when used with a high speed modem.
Use the command
setserial -a /dev/ttySx
to get Linux to report to you the type of UART you have. If you do not have a 16550A type UART, invest in a new serial card (available for under $50). When you purchase a new card, make sure you can move the IRQs around on it!
Note: the first versions of the 16550 UART chip had an error. This was rapidly discovered and a revision of the chip was released - the 16550A UART. A relatively small number of the faulty chips did however get into circulation. It is unlikely that you will encounter one of these but you should look for a response that says 16550A, particularly on serial cards of some vintage.
Historically, Linux used cuaX
devices for dial out and ttySx
devices for dial in.
The kernel code that required this was changed in kernel version 2.0.x
and you should now use ttySx
for both dial in and dial out. I
understand that the cuaX
device names may well disappear in future
kernel versions.
You will need to configure your modem correctly for PPP - to do this READ YOUR MODEM MANUAL! Most modems come with a factory default setting that selects the options required for PPP. The minimum configuration specifies:-
&
K3 on many Hayes modems)Other settings (in standard Hayes commands) you should investigate are:-
&
C1 Carrier Detect ON only after connect&
S0 Data Set Ready (DSR) always ON
There is a site offering modem setups for a growing variety of modem makes and models at Modem setup information which may assist you in this.
It is also worth while investigating how the modem's serial interface between your computer and modem operates. Most modern modems allow you to run the serial interface at a FIXED speed whilst allowing the telephone line interface to change its speed to the highest speed it and the remote modem can both handle.
This is known as split speed operation. If your modem supports this, lock the modem's serial interface to its highest available speed (usually 115,200 baud but maybe 38,400 baud for 14,400 baud modems).
Use your communications software (e.g. minicom or seyon) to find out
about your modem configuration and set it to what is required for PPP.
Many modems report their current settings in response to
AT&
V, but you should consult your modem manual.
If you completely mess up the settings, you can return to sanity
(usually) by issuing an AT&
F - return to factory settings.
(For most modem modems I have encountered, the factory settings include
all you need for PPP - but you should check).
Once you have worked out the modem setup string required write it down. You now have a decision: you can store these settings in your modem non-volatile memory so they can be recalled by issuing the appropriate AT command. Alternatively you can pass the correct settings to your modem as part of the PPP dialing process.
If you only use your modem from Linux to call into your ISP or corporate server, the simplest set up will have you save your modem configuration in non-volatile RAM.
If on the other hand, you modem is used by other applications and operating systems, it is safest to pass this information to the modem as each call is made so that the modem is guaranteed to be in the correct state for the call. (This has the added advantage also of recording the modem setup string in case the modem looses the contents of its NV-RAM, which can indeed happen).
When data is traveling on serial communication lines, it can happen that data arrives faster than a computer can handle it (the computer may be busy doing something else - remember, Linux is a multi-user, multi- tasking operating system). In order to ensure that data is not lost (data does not over run in the input buffer and hence get lost), some method of controlling the flow of data is necessary.
There are two ways of doing this on serial lines:-
Whilst the latter may be fine for a terminal (text) link, data on a PPP link uses all 8 bits - and it is quite probable that somewhere in the data there will be data bytes that translate as control S and control Q. So, if a modem is set up to use software flow control, things can rapidly go berserk!
For high speed links using PPP (which uses 8 bits of data) hardware flow control is vital and it is for this reason that you must use hardware flow control.
Now that you have sorted out the serial port and modem settings it is a good idea to make sure that these setting do indeed work by dialing you ISP and seeing if you can connect.
Using you terminal communications package (such as minicom), set up the modem initialisation required for PPP and dial into the PPP server you want to connect to with a PPP session.
(Note: at this stage we are NOT trying to make a PPP connection - just establishing that we have the right phone number and also to find out exactly what the server sends to us in order to get logged in and start PPP).
During this process, either capture (log to a file) the entire login process or carefully (very carefully) write down exactly what prompts the server gives to let you know it is time to enter your user name and password (and any other commands needed to establish the PPP connection).
If your server uses PAP, you should not see a login prompt, but should instead see the (text representation) of the link control protocol (which looks like garbage) starting on your screen.
A few words of warning:-
It is worth dialing in at least twice - some servers change their prompts (e.g. with the time!) every time you log in. The two critical prompts your Linux box needs to be able to identify every time you dial in are:-
If you have to issue a command to start PPP on the server, you will also need to find out the prompt the server gives you once you are logged in to tell you that you can now enter the command to start ppp.
If your server automatically starts PPP, once you have logged in, you will start to see garbage on your screen - this is the PPP server sending your machine information to start up and configure the PPP connection.
This should look something like this :-
~y}#.!}!}!} }8}!}$}%U}"}&} } } } }%}& ...}'}"}(}"} .~~y}
(and it just keeps on coming!)
On some systems PPP must be explicitly started on the server. This is usually because the server has been set up to allow PPP logins and shell logins using the same user name/password pair. If this is the case, issue this command once you have logged in. Again, you will see the garbage as the server end of the PPP connection starts up.
If you do not see this immediately after connecting (and logging in and starting the PPP server if required), press Enter to see if this starts the PPP server...
At this point, you can hang up your modem (usually, type +++
quickly and then issue the ATHO command once your modem responds with
OK).
If you can't get your modem to work, read your modem manual, the man pages for your communications software and the Serial HOWTO! Once you have this sorted out, carry on as above.