Serial Line Networking in LINUX

SLIP, CSLIP and also PPP are low-level transfer protocols for serial lines, which are considered beeing a part of so called Network Interface from the TCP/IP model point of view. Technical description of these protocols is beyond the scope of this text and can be found in RFCs.

Before serial line can be used as network medium for IP traffic, it's neccessary to make both ends of the link understanding the things going through. ( typically that means starting some daemon) and to configure serial Network Interfaces and routing tables on both ends of the link. Both ends of the link must be converted to the same mode, so for example it's impossible to use SLIP on one side and CSLIP or PPP on the second one.


Slattach is an easy utility, which can be used to convert serial line to SLIP or CSLIP mode. It is really simple and doesn't offer any extended features of other similar tools like automatical network interface and routing table configuration or modem dialing. All these steps must be done explicitly using other tools (ifconfig, route...). That's why slattach is used especially for fixed connections, which are established at boot time from rc.inet2 script.

slattach -s 38400 -p slip /dev/ttyS1 &

converts the /dev/ttyS1 to SLIP mode with given baud rate

slattach -s 38400 -p cslip /dev/ttyS0 &

converts the /dev/ttyS0 to CSLIP mode.

Then it is neccessary to configure the network interface and routing table (see

Dip is an other utility, but it already offers some functions slattach doesn't. Dip can be used for as fixed as modem lines as either dip-client or dip-server. Dip-client allows user to log in to a remote system via terminal line or via modem, perform neccessary things there and then converts client's end of link to appropriate mode and configures client's network interface and routing table. Process of "doing neccessary things" can be made more user-friendly by using dip-server as login shell for slip/cslip client in the peer's system. Dip-server then makes all the job on peer for you including network interface and routing table configuration.
Dip consists of only one executable, which can serve as both the client (dip) and the server (symlink diplogin).

Diplogin works the following way: first it tries to find the calling user's record in /etc/diphosts file and performs some additional authentication if requested. When the record is found and the authentication is O.K. diplogin sends contents of the record to standard output and then converts the current line to appropriate mode (SLIP,CSLIP) and configures network interface and routing table depending on contents of the record.

/etc/diphosts format:

< login name >:< password >:< remote IP/name >:< local IP/name >:< netmask >:< comment >:< protocol >,< MTU > Dip can be used as either an interactive tool or a command interpreter for establishing SLIP/CSLIP connections. Following example shows using dip in interactive mode for setting SLIP connection on a fixed line assuming diplogin to be used as the login shell on remote site.

$ dip -t

DIP> port ttyS1
DIP> speed 38400
DIP> term

< login to remote system and eventual additional authentication >

Your address is, server address is
mode is SLIP

< now press ctrl-] to get back to your local dip >

DIP> get $local
DIP> get $remote
DIP> mode SLIP
port, speed
set up the port you want to use
switches the line to terminal mode

get $local, get $remote, mode
set up your site for SLIP/CSLIP
switches the line to appropriate mode
In this example dip automaticaly configures network interface and adds a route to the remote site to the routing table at the local site. It wouldn't do so if we left out the get and mode commands, which specify the informations used by dip to do this job for us.

In case of modem line we'd also need to use commands send ATZ\r and dial < number > before switching to terminal mode.

As for script mode of dip, there are several examples and readmes in the dip package, so I won't describe the scrip part in this document.


Using pppd for establishing PPP links is quite similar to using
dip for SLIP/CSLIP links. It's possible to use it as login shell so it may be used for both initiating PPP from local site and for automatic handling incomming PPP requests on remote site. It also provides much better authentication and line parameters negotiation than dip.
There is quite big number of options in pppd syntax, which can be complicated sometimes, but it's not neccessary to use all of them to etstablish PPP link successfuly. Here is an example how to use pppd as a client to initiate PPP connection supposing pppd's beeing used as login shell on remote side:

pppd /dev/ttyS1 38400 connect 'chat "" "" "login:" "username" "Password:" "password"'
/dev/ttyS1 38400
specify the port and baud rate we want to use
specifies an executable we want to use for handling communication exchange with the remote computer.
Chat program is typicaly used in the connect option, however it's not required. It's possible to understand its arguments as pairs of "wait for" and "send" sequences, so if we substitute "username" and "password" with some real user identifications, it should be clear that chat automaticaly handles login to the remote system in accordance with its arguments.

For explanation how pppd works as a server, it's neccessary to know about some files in /etc/ppp/, which are used by pppd implicitly:
contains default options, which are used by every pppd call automaticaly
contains device specific options, tty stands for some real device
executed, when the link is available for IP traffic
executed, when the link is no longer available for IP traffic
for authentication
for authentication
Based on the mentioned facts, pppd server could be configured for example this way: If we want pppd to configure network interface and routing table automaticaly, we have to ensure both ends of link to know at least its IP addresses. It's possible either to specify the address explicitly as a command line option or to allow pppd to negotiate the address with the peer (peer has to have both addresses specified in this case) or to use the authentication mechanisms of pppd, which allow to store the addresses in pppd's authentication files. The second and the third methods are the most common, especially in case of internet providers.

As for other options of pppd and its authentication issues it's possible to find the neccessary informations either in pppd's man page or in HOWTOs distributed together with pppd's package.

Table of contents