Linux Kernel Serial Port Buffer Size In Logic

Linux Kernel Serial Port Buffer Size In Logic 5,0/5 4978 votes

USB to UART converters or bridges present themselves as a serial port to your computer and send serial data over a couple of wires. They can be used to make a serial connection to another device. In this post we’ll look into how this works.

Applications

This leaves any new drivers using the tty core to interact with the user and the system as serial port drivers. To determine what kind of tty drivers are currently loaded in the kernel and what tty devices are currently present, look at the /proc/tty/drivers file. This file consists of a list of the different tty drivers currently present. Lx-dmesg - Print Linux kernel log buffer lx-fdtdump - Output Flattened Device Tree header and dump FDT blob to the filename lx-iomem - Identify the IO memory resource locations defined by the kernel lx-ioports - Identify the IO port resource locations defined by the kernel lx-list-check - Verify a list consistency.

From a hacking perspective, the most interesting application of UARTs is in embedded devices. Most embedded devices have a UART header on the board. The device sends console output and accepts commands over the UART interface. Often, this gives direct access to a root shell.

UART communication is sometimes also needed to interact with a development board, such as an Arduino or ESP8266, although most of these boards have a USB to serial converter on board.

Several other protocols are built upon UART communication, such as IrDA, DMX, MIDI and smart meter P1 ports. These can be used with USB to UART bridges, but require further hacking to get working.

Communicating with UARTs

When two devices communicate using UART, they are connected with at least three wires:

  • Common ground, or 0V, or the negative lead of the power supply.
  • The transmitting pin (Tx) of one device is connected to the receiving pin (Rx) of the other device.
  • Similarly, Rx is connected to Tx.
  • For isolated adapters, Vcc or the positive lead of the power supply.

Now, the devices can send data to each other by varying the voltage on the Tx lines, and read data by checking the voltage on the Rx line. UART uses a binary protocol, so there are only two voltage levels: high and low.

There is no clock signal and no negotiation between the two devices. To correctly communicate, both devices must be configured beforehand to use the same speed of communication, called the baud rate.

Baud rate

The baud rate is a term for the number of bits per second that are transmitted over the wire. A common baud rate is 9600 bits per second. In that case, one bit takes up 19600 of a second, or 104µs.

The sending party flips the signal every 104µs, and the receiving party checks the voltage on the line every 104µs. It will still work if this is off by a couple of per cent. This sometimes happens with microcontrollers, that have trouble keeping an exact clock.

The most common baud rates in use are 9600 and 115200. Then there are a handful of standard baud rates, such as 19200 and 38400. In theory you can use any baud rate, but old interfaces only support the standard baud rates. It is possible to use different baud rates for sending and receiving, although this is pretty rare.

Start, stop and parity bits

UART frames consist of a start bit, seven or eight data bits, optionally a parity bit and one or two stop bits. By far the most common configuration is to use eight data bits, no parity bit and one stop bit, or 8N1. So the transmitting party first sends a start bit, then eight data bits, followed by a stop bit.

Voltage levels

UARTs use two voltages: one voltage indicates a 0 bit and another voltage indicates a 1 bit. What voltage exactly is used depends on the device:

  • RS232 serial ports use negative and positive voltages, up to -15V and 15V.
  • Some devices use 0V and 5V, such as an Arduino Uno that runs on 5V.
  • Most devices use 0V and 3.3V.
  • Some devices use 0V and 1.8V.

For RS232, negative voltage is a logical 1, positive voltage a 0. For most other UART devices, 0V indicates a 0 bit and the higher voltage indicates a 1 bit.

To avoid frying your device, it is important to use the correct voltage. Connecting your 3.3V bridge to a 15V RS232 line will quickly destroy it.

Voltage that ranges between 0 and power supply voltage (Vcc) is also called TTL voltage levels. 5V TTL voltage levels consider everything above 2V a logic high, and can thus also receive data from 3.3V UART devices. So in that case it is possible to communicate with a 5V UART using a 3.3V UART.

USB to UART converter module

To let your computer talk UART, you need a device that converts computer bytes to UART signals; a USB to UART converter module. This is a small device that plugs into your USB port and has at least ground, Rx and Tx outputs. It pretends to be a serial port to your computer. The computer sends data to this serial port and the module converts it to UART signals.

Chip differences

A USB to UART bridge has a chip on it specifically for this purpose. There are several commonly used chip families:

  • Jiangsu Qinheng / WCH CH340
  • Silicon Labs CP2102
  • Prolific PL2303
  • FTDI FT232

These have different versions with different specs:

ChipPriceI/O voltageMax baud rateBuffer sizeGPIODatasheet
CH340€0.253.3 / 5V2 Mbps32 + 32 B0CH340
CH341€0.753.3 / 5V2 Mbps32 + 32 B0CH341
CP2102€0.753.3V11 Mbps576 + 640 B0CP2102/9
CP2102N€1.503.3V3 Mbps512 + 512 B7CP2102N
PL2303HXD€0.901.8 - 3.3V112 Mbps512 B4PL2303HXD
PL2303TA€0.701.8 - 3.3V6 Mbps512 B2PL2303TA
FT232R€3.501.8 - 5V3 Mbps128 + 256 B4FT232R
FT231X€1.801.8 - 4V3 Mbps512 + 512 B4FT231X
  1. The CP2102 and PL2302HXD only output a maximum 3.3V, but can take up to 5V as input, making them compatible with 5V UART devices.

Besides the differences in the chips, the quality of the drivers also differs between the various chips. Some chips have Windows drivers built-in to Windows or distributed through Windows Update, creating a plug-and-play experience. Other chips have drivers that reliably crash the operating system when you read and write significant amounts of data to the device. Linux is an exception in this, since the Linux drivers are written, maintained and checked by kernel developers instead of the chip manufacturer.

The FTDI is around the longest and was previously the only implementation available for USB to UART bridges. They were so common that a bridge was often called a FTDI, after the company name that made the converter chip. Nowadays, they are quickly taken over by much cheaper Chinese converter chips.

Fake FTDI chips

FTDI FT232 chips are pretty popular and relatively expensive (€3.50). This led to the rise of fake Chinese knock-offs. These imitations have the FTDI logo on them and work correctly, and are hard to tell from fakes.

FTDI was not happy with this. In 2014 they pushed a driver update that only works with real FTDI chips, and bricked counterfeit chips. Later they reverted this controversial behavior, but it severely damaged their reputation. Despite that, fake FT232 chips are still widely used and available.

Adapter differences

The cheapest adapters simply have an USB port and pin header directly connected to the chip. They typically expose only ground, positive voltage (Vcc), Rx and Tx, and not other data control modem lines such as RTS and CTS.

There are also galvanically isolated adapters. These use the ground and Vcc of the device you want to communicate with, and don’t electrically connect the device with your computer. This protects your computer from high voltage, prevents ground loops, and reduces noise. These adapters are more expensive, but they may safe your computer’s life in case you ever connect the bridge to a high voltage by mistake.

Buyer’s guide

When picking a USB to UART bridge, keep these things in mind:

  • Voltage level. Determine the voltage level you want to use. Some bridges support both 3.3V and 5V, and there is a little jumper to switch voltage.
  • Drivers. Check whether the bridge you want to buy has drivers for your platform.
  • Blinking LEDs. They look cool and they can help you with troubleshooting.
  • USB connector. Some bridges plug right into your computer, but it is often nice to have a USB cable between your computer and your bridge so that you have more room on your desk. Bridges with mini-USB sockets are pretty common, but I prefer micro-USB sockets.
  • Features. Do you need special features such as inverted signals or custom EPROM? Check the data sheet of the chip.
  • Speed. Do you need particularly fast or uncommon speeds? Check the data sheet of the chip.
  • Galvanic isolation. As described above, electrically disconnecting the USB connection from the I/O pins protects from damage to your computer.
  • Modem control signals. If you need RTS, CTS, DSR, DTR, DCD, and RI control signals, make sure your bridge has pins for them.

I think the FTDI chips are the best. They are also the most expensive and it is hard to determine whether you have a legitimate chip or a cheap knock-off.

For normal UART usage, any chip is fine. With the cheapest bridge on AliExpress (€0.50) you can talk to embedded devices just fine.

Drivers

Your computer needs to know how to talk to the module, and for that you need drivers. If you plug the module into your computer, you should gain a serial port. If this doesn’t happen, you probably need a driver.

On Linux the drivers ship with the kernel. The most common chips are supported from kernel version 2.6 and up, and the drivers are still being improved in the latest versions.

MacOS comes with built-in drivers for certain chips. Several FTDI chips are supported from MacOS 10.9 or 10.10, and certain CH340 and PL2303 chips are supported under MacOS 10.14. For other chips, you need drivers on MacOS. For example, the CH340 driver can be installed using homebrew using the following command:

Alternatively, you can use the excellent Serial app for macOS, which comes with its own drivers.

On Windows you need drivers. For FTDI chips these can be obtained through Windows Update, and for others an installer can be found on the manufacturer site.

Some of these drivers are of questionable quality and can make your system unstable. I could reliably crash my Mac by reading and writing a large amount of data to the serial port when using the CH340 driver.

Finding the serial port name

A USB to UART bridge adds a serial port to your computer. To communicate over the UART, you have to read and write to the correct serial port. If you can’t find the correct port, you probably have trouble with drivers or the USB connection to your bridge.

Linux

The device is called something like /dev/ttyUSB0. If you plug the device in a look in the logs (sudo dmesg), a line typically indicates where the newly found device is attached:

macOS

The device is called something like /dev/tty.wchusbserial1410. I haven’t found a reliable way to get the filename of this port. You can try the following things:

  • View the logs using sudo dmesg.
  • List USB devices using ioreg -p IOUSB, or by going to About This Mac, System Report, USB.

If all else fails, list all files in /dev, plug the device in, list again and diff the two:

Windows

On Windows, the port is called COM3 or some other number. You can find the correct port number in the device manager.

Talking to the serial port

You need software that sets the baud rate and sends and receives bytes over the serial port. Use tio on Linux, Putty on Windows and Serial on macOS. Don’t use screen.

When using Putty on Windows, turn of software handshaking, which is on by default. In the Serial menu, set Flow control to None.

You typically want software that supports arbitrary baud rates and informs you of what is going on. In that regard, screen and gtkterm are insufficient. While screen can set up a serial connection and it may works correctly, it doesn’t inform you when it can’t do what you want. If you run the command screen /dev/ttyUSB0 128000, you may expect the baud rate to be set to 128000. However, this is an unsupported baud rate and screen silently falls back to 9600. Everything seems to be OK, except the baud rate is incorrect.

Even more weirdly, screen /dev/ttyUSB0 4098 uses a baud rate of 115200, because the kernel constant B115200 equals 4098, and screen interprets the given number either way.

The cu command at least tells you that the baud rate is unsupported.

Everything you type is sent over the serial line, which can make it tricky to exit the program. Use the following key shortcuts to exit:

  • screen: ctrl-a, k, y
  • tio: ctrl-t, q
  • cu: ~. enter

Finding an UART interface on a device

If you want to connect to an embedded device, the first step is to find the correct pins on the board. Often there is a row of four or five pins with at least ground, Vcc, Rx and Tx. Sometimes the pins are omitted and there are only holes. Often such a connection is labeled as J5 or another number.

In the following image you can see a UART interface on a Huawei modem. The device came with blank pads and I soldered the pins to it. You can see a little table in the silk screening that describes the pins: Tx, Gnd, Vcc, Rx. The pins on the right side are JTAG pins. Having UART and JTAG in one connector makes it possible to easily connect a debug cable to the board for debugging. For similar reasons, debug ports are often on the side of the board.

If you suspect a pin to be a UART line, the first step is to measure the voltage using a multimeter. First, find a good connection for the common ground and connect the black lead of the multimeter to it. Then measure the voltage on the suspected pins with the red lead. A Tx line will be 3.3V when idle. Keep measuring while rebooting the device. Data is often sent on boot, so we can use this to determine whether data is sent over the line. If data is sent, the voltage will temporarily drop below 3V according to the multimeter.

Now you have determined that the line has an acceptable voltage and there is activity on it. This does not yet mean that the line is an UART line, it could use another protocol such as I2C or SPI. One way to determine this is to use a logic analyzer or oscilloscope to view the electrical signals. Or, you can connect your USB to UART bridge and see if it works.

In the example below a camera has five holes, initially hidden under a white sticker. This makes it possible to access the UART interface from the outside. However, I couldn’t get this working and soldered wires to the pads. The pads are marked as TP41, TP42, and so on, where TP stands for test point.

Connecting to the device

Before connecting to the device, make sure it emits a voltage that is compatible with your bridge. RS232 lines, for example, use -15 and +15V, which can easily ruin your brige. Even if the voltage is acceptable, you may want to put a 300Ω resistor between your bridge and the device to prevent too large currents.

When connecting your UART bridge to the device, connect ground, Tx and Rx. The Rx of the bridge connects to the Tx of the device, and the other way around.

Whether to connect Vcc depends on whether you use an isolated bridge. If you have an isolated bridge there is no electrical connection between your USB port and the I/O pins. However, the I/O pins still need to put out a voltage, and for this the I/O side needs Vcc.

If your adapter is not isolated, connecting Vcc of your bridge to the device may interfere with the voltage already on the device. If the device gets power from another power supply it already has a certain voltage level on its Vcc pin. If you connect the bridge’s Vcc pin and the voltage is different, a current will flow which may damage the device.

An alternative is to disconnect the device from the power supply and supply power through the USB to UART bridge. However, most bridges can only supply up to 100 mA or so, which is not enough for most devices.

Finding the baud rate

A common way is to try the standard baud rates until the output looks legible. Alternatively, the baud rate can be determined by measuring the length of the shortest pulse. With a baud rate of 9600, one bit takes 19600 of a second. So if we measure the duration of one bit we can determine the baud rate.

This is easiest with a logic analyzer, which just shows the timing in the interface:

Alternatively, it is possible with a microcontroller by using input capture to measure pulse widths. I created an autobaud program that works on Arduino Uno and can determine baud rates up to 200,000 bps reliably.

Using an incorrect baud rate will typically show gibberish, although it is also possible that you see nothing at all.

Troubleshooting

The first step is to pinpoint where the problem is: is it between your computer and the bridge or between the bridge and the device you want to connect to?

Locating the problem

  • Does your computer get an extra COM or tty device when plugging the bridge in? If not, you have a driver problem.
  • Check the LEDs on the bridge.
    • Is the Tx LED lighting up when you are sending data? Then the connection between your computer and the bridge is OK.
    • Is the Rx LED lighting up but you don’t see anything in your terminal application? Then the the connection between the bridge and the device is OK and the problem is between your computer and the bridge.
  • Disconnect the bridge from the device and connect the Rx and Tx of the bridge together. Is your typing reflected in the terminal? Then the connection to the bridge is OK.

USB problems

  • Check whether your operating system recognizes the USB device.
    • On Linux: lsusb
    • On macOS: ioreg -p IOUSB
    • On Windows: check device manager.
  • View the logs (using dmesg) when putting the device into your computer.
  • Unplug the bridge, list all devices (ls /dev), plug the bridge in again, and compare the two.
  • Try another known good USB cable.
  • Retry what you are doing a couple of times, to rule out a temporary problem.

Remote problems

  • Is the baud rate correct?
  • Is the bridge using the baud rate you think it is?
  • Does the device use an inverted data line?
  • Does the device need to have serial communication enabled? Does it have a data request line?
  • Is ground correctly connected to the device?

Conclusion

Using a USB to UART bridge can be pretty simple if it works, or it can be painful if it doesn’t. I am surprised that there is so much to tell about UART’s.

Read more

Chips

  • Atmel ATMEGA8U2 or 16U2 with Arduino USBSerial Firmware
  • Cypress CY7C65211 or CY7C65213

Isolated adapters

Articles

Tweets

You should make sure that your modem is correctly set up and that youknow which serial port it is connected to.

Remember:-

  • DOS com1: = Linux /dev/cua0 (and /dev/ttyS0)

  • DOS com2: = Linux /dev/cua1 (and /dev/ttyS1)et cetera

It is also worth remembering that if you have 4 serial ports, thestandard PC set up is to have com1 and com3 share IRQ4 and com2 and com4share IRQ3.

If you have devices on standard serial ports that share an IRQ with yourmodem you are going to have problems. You need to make sure that yourmodem serial port is on its own, unique IRQ. Many modern serial cards(and better quality motherboard serial ports) allow you to move the IRQof the serial ports around.

If you are running Linux kernel 2, you can check the in-use IRQs usingcat /proc/interrupts, which will produce output like

This shows a serial port on IRQ4 (a mouse) and a serial porton IRQ15 (the permanent modem based PPP link to the Internet. (There isalso a serial port on com2, IRQ3 and com4 is on IRQ14, but as they arenot in use, they do not show up).

Be warned - you need to know what you are doing if you are going to playwith your IRQs! Not only do you have to open up you computer, pull outcards 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 onmotherboard 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 totell Linux which IRQ each port is using. This is done usingsetserial and is best done as part of the boot process inrc.local or rc.serial which is called from rc.local or aspart of the SysV initialisation. For the machine illustrated above, thecommands used are

However, if you are using serial modules dynamically loaded whenrequired by the kerneld process, you cannot set and forget the IRQetc 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 toreconfigure the IRQs etc each time the module is loaded.

A note about serial ports and speed capabilities

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 thatsuch a modem is capable of producing, particularly when the modems arecompressing the data.

This requires your serial port to use a modern UART (UniversalAsynchronous Receiver Transmitter) such as a 16550(A). If you are usingan old machine (or old serial card), it is quite possible that yourserial port has only an 8250 UART, which will cause you considerableproblems when used with a high speed modem.

Use the command

to get Linux to report to you the type of UART you have. If youdo not have a 16550A type UART, invest in a new serial card (availablefor under $50). When you purchase a new card, make sure you canmove the IRQs around on it!

Note: the first versions of the 16550 UART chip had an error. This wasrapidly discovered and a revision of the chip was released - the 16550AUART. A relatively small number of the faulty chips did however get intocirculation. It is unlikely that you will encounter one of these but youshould look for a response that says 16550A, particularly on serialcards of some vintage.

Serial Port Names

Historically, Linux used cuaX devices for dial out and ttySxdevices for dial in.

The kernel code that required this was changed in kernel version 2.0.xand you should now use ttySx for both dial in and dial out. Iunderstand that the cuaX device names may well disappear in futurekernel versions.

Configuring your modem

You will need to configure your modem correctly for PPP - to do this READYOUR MODEM MANUAL! Most modems come with a factory default settingthat selects the options required for PPP. The minimum configurationspecifies:-

  • Hardware flow control (RTS/CTS) (&K3 on many Hayes modems)

Other settings (in standard Hayes commands) you should investigate are:-

  • E1 Command/usr/src/linux-2.0.27/include/linux/serial.h Echo ON (required for chat to operate)

  • Q0 Report result codes (required for chat to operate)

  • S0=0 Auto Answer OFF (unless you want your modem to answer the phone)

  • &C1 Carrier Detect ON only after connect

  • &S0 Data Set Ready (DSR) always ON

    Mortal kombat trilogy mame rom. There are over 56 characters to choose from including multiple versions of the same character that came from different versions of the MK series.Only 1-Player Mode is available.Click inside the screen to activate controls.ControlsArrow Keys – MovementSpace – ModeEnter – Start“Z” key – A“X” key – B“C” key – C“A” key – X“S” key – Y“D” key – ZTo save your game: hover over the emulator screen and use the icons to save your progress.Down arrow icon (save), Up arrow icon (load).There have been 1934 likes from 2414 votes on this game.

  • (depends) Data Terminal Ready

There is a site offering modem setups for a growing variety of modemmakes and models at Modem setup information which may assist you in this.

It is also worth while investigating how the modem's serial interfacebetween your computer and modem operates. Most modern modems allow youto run the serial interface at a FIXED speed whilst allowing thetelephone line interface to change its speed to the highest speed it andthe 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 outabout your modem configuration and set it to what is required for PPP.Many modems report their current settings in response toAT&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 includeall 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 modemnon-volatile memory so they can be recalled by issuing the appropriateAT command. Alternatively you can pass the correct settings to yourmodem as part of the PPP dialing process.

If you only use your modem from Linux to call into your ISP or corporateserver, the simplest set up will have you save your modem configurationin non-volatile RAM.

If on the other hand, you modem is used by other applications andoperating systems, it is safest to pass this information to the modem aseach call is made so that the modem is guaranteed to be in the correctstate for the call. (This has the added advantage also of recording the modemsetup string in case the modem looses the contents of its NV-RAM, whichcan indeed happen).

Note on Serial Flow Control

When data is traveling on serial communication lines, it can happenthat data arrives faster than a computer can handle it (the computer maybe 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), somemethod of controlling the flow of data is necessary.

There are two ways of doing this on serial lines:-

  • Using hardware signals (Clear To Send/Request to Send - CTS/RTS)

  • Using software signals (control S and control Q, also known as XON/XOFF).

Whilst the latter may be fine for a terminal (text) link, data on aPPP link uses all 8 bits - and it is quite probable that somewhere inthe data there will be data bytes that translate as control S andcontrol Q. So, if a modem is set up to use software flow control, thingscan rapidly go berserk!

For high speed links using PPP (which uses 8 bits of data) hardware flowcontrol is vital and it is for this reason that you must use hardwareflow control.

Testing your modem for dial out

Now that you have sorted out the serial port and modem settings it is agood idea to make sure that these setting do indeed work by dialing youISP and seeing if you can connect.

Using you terminal communications package (such as minicom), set up themodem initialisation required for PPP and dial into the PPP server youwant 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 findout exactly what the server sends to us in order to get logged in andstart PPP).

During this process, either capture (log to a file) the entire loginprocess or carefully (very carefully) write down exactly whatprompts the server gives to let you know it is time to enter youruser name and password (and any other commands needed to establish thePPP connection).

If your server uses PAP, you should not see a login prompt, but shouldinstead see the (text representation) of the link control protocol(which looks like garbage) starting on your screen.

A few words of warning:-

  • some servers are quite intelligent: you can log inusing text based user name/passwords OR using PAP. So if your ISP orcorporate site uses PAP but you do not see the garbage start upimmediately, this may not mean you have done something wrong.

  • some servers require you to enter some text initially and thenstart a standard PAP sequence.

  • Some PPP servers are passive - that is they simply sit theresending nothing until the client that is dialing in sends them a validlcp packet. If the ppp server you are connecting to operates in passivemode, you will never see the garbage!

  • Some servers do not start PPP until you press ENTER - so it isworth trying this if you correctly log in and do not see the garbage!

It is worth dialing in at least twice - some servers change theirprompts (e.g. with the time!) every time you log in. The two criticalprompts your Linux box needs to be able to identify every time you dialin are:-

  • the prompt that requests you to enter your user name;

  • the prompt that requests you to enter your password;

If you have to issue a command to start PPP on the server, you will alsoneed to find out the prompt the server gives you once you are logged into 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 serversending your machine information to start up and configure the PPPconnection.

This should look something like this :-

(and it just keeps on coming!)

On some systems PPP must be explicitly started on the server. Thisis usually because the server has been set up to allow PPP logins andshell 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 thegarbage as the server end of the PPP connection starts up.

If you do not see this immediately after connecting (and logging in andstarting the PPP server if required), press Enter to see if thisstarts 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 withOK).

If you can't get your modem to work, read your modem manual, the manpages for your communications software and the Serial HOWTO! Once youhave this sorted out, carry on as above.

PrevHomeNextGetting the Information you need about the PPP serverSetting up Name to Address Resolution (DNS)