RedHat Linux Free Tutorial

Web based School

Red Hat Linux rhl42

Previous Page TOC Next Page

42


Networking


In this chapter, you will look at the world of networking. In particular, you will learn the following:

  • What is TCP/IP?

  • How do you set up Linux to use TCP/IP and Ethernet?

  • What changes are necessary to your configuration files?

  • How can you test and troubleshoot Ethernet connections?

  • What is necessary for a SLIP and PPP connection?

Linux offers a complete implementation of Transmission Control Protocol/Internet Protocol (TCP/IP), the protocol used extensively on the Internet and that is commonly found in local area networks involving UNIX machines. All you need to create a network, or to add your existing machine to a TCP/IP network, is a network card or network interface and some modifications to files already on your Linux system.

Whether you are setting up two machines in your room to talk to each other, or adding your Linux machine to an existing network of 5,000 workstations, the process is the same.

What Is TCP/IP?


TCP/IP is an open networking protocol, which simply means that the technical description of all aspects of the protocol have been published. They are available for anyone to implement on their hardware and software. This open nature has helped make TCP/IP very popular. Versions of TCP/IP are now available for practically every hardware and software platform in existence, which has helped make TCP/IP the most widely used networking protocol in the world. The advantage of TCP/IP for a network operating system is simple: Interconnectivity is possible for any type of operating system and hardware platform that you might want to add.

TCP/IP is not a single protocol but a set of more than a dozen protocols. Each protocol within the TCP/IP family is dedicated to a different task. All the protocols that make up TCP/IP use the primary components of TCP/IP to send packets of data.

Transmission Control Protocol and Internet Protocol are two of the primary protocols in the TCP/IP family. The different protocols and services that make up the TCP/IP family can be grouped according to their purposes. The groups and their protocols are the following:

Transport: These protocols control the movement of data between two machines.

      TCP (Transmission Control Protocol): A connection-based service, meaning that the sending and receiving machines communicate with each other through a stream of messages. TCP has message delivery assurance routines incorporated into it.

      UDP (User Datagram Protocol): A connectionless service, meaning that the data is sent without the sending and receiving machines being in contact with each other. It's like sending snail-mail (regular postal service) with an address but no guarantee it will arrive.

Routing: These protocols handle the addressing of the data and determine the best routing to the destination. They also handle the way large messages are broken up and reassembled at the destination.

      IP (Internet Protocol): Handles the actual transmission of data.

      ICMP (Internet Control Message Protocol): Handles status messages for IP, such as errors and network changes that can affect routing.

      RIP (Routing Information Protocol): One of several protocols that determine the best routing method.

      OSPF (Open Shortest Path First): An alternative protocol for determining routing.

Network Addresses: These services handle the way machines are addressed, both by a unique number and a more common symbolic name.

      ARP (Address Resolution Protocol): Determines the unique network hardware addresses of machines on the network based on their IP address.

      DNS (Domain Name System): Determines numeric addresses from machine names.

      RARP (Reverse Address Resolution Protocol): Determines IP addresses of machines on the network based on their network address (the opposite of ARP).

      BOOTP (Boot Protocol): This starts up a network machine by reading the boot information from a server. BOOTP is commonly used for diskless workstations.

User Services: These are applications users have access to.

      FTP (File Transfer Protocol): This protocol efficiently transfers files from one machine to another. FTP uses TCP as the transport.

      TFTP (Trivial File Transfer Protocol): A simple file transfer method that uses UDP as the transport.

      TELNET: Allows remote logins so that a user on one machine can connect to another machine and behave as though they are sitting at the remote machine's keyboard.

Gateway Protocols: These services help the network communicate routing and status information, as well as handle data for local networks.

      EGP (Exterior Gateway Protocol): Transfers routing information for external networks.

      GGP (Gateway-to-Gateway Protocol): Transfers routing information between Internet gateways.

      IGP (Interior Gateway Protocol): Transfers routing information for internal networks.

Others: These are services that don't fall into the categories just mentioned but that provide important services over a network.

      NFS (Network File System): Allows directories on one machine to be mounted on another, and then accessed by users as though the directories were on the local machine.

      NIS (Network Information Service): Maintains user accounts across networks, simplifying logins and password maintenance.

      RPC (Remote Procedure Call): Allows remote applications to communicate with each other using function calls.

      SMTP (Simple Mail Transfer Protocol): A protocol for transferring electronic mail between machines.

      SNMP (Simple Network Management Protocol): An administrator's service that sends status messages about the network and devices attached to it.

All the TCP/IP protocol definitions are maintained by a standards body that is part of the Internet organization. Although changes to the protocols occasionally occur when new features or better methods of performing older functions are developed, the new versions are almost always backward compatible.

Hardware Requirements


You can actually configure Linux to use TCP/IP without any network card or connection to a network, using a technique called loopback. Loopback is a method of instruction that enables part of TCP/IP to talk to another part without leaving the machine. Essentially, you are creating a loop between a software exit and a software entry. Loopbacks are frequently used to test TCP/IP configurations, and some software requires a loopback to be in place for proper operation.

If you want to connect your Linux machine to a network, you need a network card. Linux uses Ethernet, a network system that was designed to provide TCP/IP support. A term you'll see often is packet, which is the bundle of data and routing instructions that is assembled by TCP/IP and Ethernet to be sent over the network cables. All messages are broken into packets, then reassembled properly at the destination.

Linux requires an Ethernet card that is compatible with one of the network cards in the following list:

      3Com 3C505

      3Com 3C503/16

      Novell NE1000

      Novell NE2000

      Western Digital WD8003

      Western Digital WD8013

      Hewlett-Packard HP27245

      Hewlett-Packard HP27247

      Hewlett-Packard HP27250

Most Ethernet cards available are compatible with one of these cards, but you should carefully check the documentation with the card to ensure you don't buy a network card that won't work properly.

If you plan to do your networking over the telephone (using a serial port and a modem), you don't need a network card, but you will need a fast modem compatible with the service you are planning to use. For example, to use SLIP (Serial Line Interface Protocol), you generally need a modem supporting at least V.32bis speeds (14.4kbps).

Configuring Linux Files


Let's assume you have a typical PC and an Ethernet card, and you want to set up your machine to run TCP/IP over the network. In most cases, the procedure described next will work. However, because there are many versions of Linux, many potential conflicts with other cards and software, and unique software requirements for some systems, this should be considered a guide.

If, after following these instructions, your TCP/IP network doesn't work properly, it's time to carefully scan all the configuration files and error messages for a clue to the problem. Also, don't forget about the Linux UseNet newsgroups, Linux User Groups, and other sources of information about Linux from which you can get help.

To configure the TCP/IP files, you must have installed the networking software on your system. If you haven't installed the networking portions of the distribution, you must do so before proceeding. Your kernel must also have been configured and recompiled with network support added. This is usually done during the installation process, although some users will have to force the kernel recompilation manually if they installed their software in a nonstandard manner.

First we'll deal with the use of a network card, and then look at how to change the basic process to handle SLIP over a serial port and modem.

What You Need Before You Start


Before you start modifying system files, take a few minutes to determine a few basic pieces of information you'll need. It is advisable to write these down somewhere so that they will be handy when you need them, and also so that you won't enter two different values in two files, thereby causing major problems for the system.

IP Address

First you need an IP address, a unique number for your machine. Every machine on the network has to be identified uniquely to allow proper routing. TCP/IP-based networks use 32-bit addresses to uniquely identify networks and all the devices that reside within that network. These addresses are called Internet addresses or IP addresses.

The 32 bits of the IP address are broken into four 8-bit parts. Each 8-bit part can then have valid numbers ranging from 0 to 255. In IP addresses, the four 8-bit numbers are separated by a period, a notation called dotted quad. Examples of dotted quad IP addresses are 255.255.255.255 and 147.14.123.8.

For convenience, IP addresses are divided into two parts: the network number and the device number within that network. This separation into two components allows devices on different networks to have the same host number. However, because the network number is different, the devices are still uniquely identified.

For connection to the Internet, IP addresses are assigned by the Internet Network Information Center (NIC) based on the size of the network. Anyone who wants to connect to the Internet must register with the NIC to avoid duplication of network addresses. If you don't plan to connect to the Internet, you are free to create your own numbering scheme, although future expansion and integration with Internet-using networks can cause serious problems.

For maximum flexibility, IP addresses are assigned according to network size. Networks are divided into three categories: Class A, Class B, and Class C. The three network classes break the 32-bit IP addresses into different sizes for the network and host identifiers.

A Class A address uses one byte for the network address and three bytes for the device address, allowing more than 16 million different host addresses. Class B networks use two bytes for the network and two bytes for the host. Because 16 bits allows more than 65,000 hosts, only a few large companies will be limited by this type of class. Class C addresses have three bytes for the network and one for the number of hosts. This provides for a maximum of 254 hosts (the numbers 0 and 255 are reserved) but many different network IDs. The majority of networks are Class B and Class C.

You do have a limitation as to the first value. A Class A network's first number must be between 0 and 127, Class B addresses are between 128 and 191, and Class C addresses are between 192 and 223. This is because of the way the first byte is broken up, with a few of the bits at the front saved to identify the class of the network. Also, you can't use the values 0 and 255 for any part, because they are reserved for special purposes.

Messages sent using TCP/IP use the IP address to identify sending and receiving devices, as well as any routing information put within the message headers. If you are going to connect to an existing network, you should find out what their IP addresses are and what numbers you can use. If you are setting up a network for your own use but plan to connect to the Internet at some point, contact the Network Information Center for an IP address. On the other hand, if you are setting up a network for your own use and don't plan to have more than a telephone connection to other networks (including the Internet), you can make up your own IP addresses.

If you are only setting up a loopback driver, you don't even need an IP address. The default value for a loopback driver is 127.0.0.1.

Network Mask

Next, you need a network mask. This is pretty easy if you have picked out an IP address. The network mask is the network portion of the IP address set to the value 255, and it's used to blank out the network portion to determine routing.

If you have a Class C IP address (three bytes for network and one for devices), your network mask is 255.255.255.0. A Class B network has a network mask of 255.255.0.0, and a Class A network mask is 255.0.0.0.

If you are configuring only a loopback driver, your network mask is 255.0.0.0 (Class A). If you have a complex network setup with subnets or shared IP addresses, you should consult your network administrator for more information about setting your network mask and IP address.

Network Address

The network address is, strictly speaking, the IP address bitwise-ANDed to the netmask. In English, what this means is that it's the network portion of your IP address, so if your IP address is 147.120.46.7 and it's a Class B network, the network address is 147.120.0.0.

To get your own network address, just drop the device-specific part of the IP address and set it to zero. A Class C network with an IP address of 201.12.5.23 has a network address of 201.12.5.0.

If you're only working with a loopback address, you don't need a network mask.

Broadcast Address

The broadcast address is used when a machine wants to send the same packet to all devices on the network. To get your broadcast address, you set the device portion of the IP address to 255. Therefore, if you have the IP address 129.23.123.2, your broadcast address will be 129.23.123.255. Your network address will be 129.23.123.0.

If you are configuring only a loopback driver, you needn't worry about the broadcast address.

Gateway Address

The gateway address is the IP address of the machine that is the network's gateway out to other networks (such as the Internet). You need a gateway address only if you have a network that has a dedicated gateway out. If you are configuring a small network for your own use and don't have a dedicated Internet connection, you don't need a gateway address.

Normally, gateways have the same IP address as your machines, but they have the digit 1 as the device number. For example, if your IP address is 129.23.123.36, chances are that the gateway address is 129.23.123.1. This convention has been used since the early days of TCP/IP.

Loopback drivers do not require a gateway address, so if you are configuring your system only for loopback, ignore this address.

Nameserver Address

Many larger networks have a machine whose purpose is to translate IP addresses into English-like names, and vice versa. It is a lot easier to call a machine bobs_pc instead of 123.23.124.23. This translation is done with a system called the Domain Name System (DNS). If your network has a name server, that's the address you need. If you want to have your own machine act as a name server (which requires some extra configuration not mentioned here), use the loopback address 127.0.0.1.

Loopback drivers don't need a name server because the machine only talks to itself. Therefore, you can ignore the nameserver address if you are only configuring a loopback driver.

Setting Up the Dummy Interface


What's a dummy interface? It's a bit of a trick to give your machine an IP address to work with when it uses only SLIP and PPP interfaces. A dummy interface solves the problem of a stand-alone machine (no network cards connecting it to other machines) whose only valid IP address to send data to is the loopback driver (127.0.0.1). While SLIP and PPP may be used for connecting your machine to the outside world, when the interface is not active you have no internal IP address that applications can use.

The problem arises with some applications that require a valid IP address to work. Some word processors and desktop layout tools, for example, require the TCP/IP system to be operational with an IP address for the target machine. The dummy interface essentially sets an IP address for your local machine that is valid as far as TCP/IP is concerned, but doesn't really get used except to fool applications.

Creating a dummy interface is very simple. If your machine has an IP address already assigned for it in the /etc/hosts file, all you need to do is set up the interface and create a route. The two commands required are 


ifconfig dummy machine_name

route add machine_name

where machine_name is your local machine's name (such as darkstar). This will create a link to your own IP address. If you do not have an IP address for your machine in the /etc/hosts file, add one before you create the dummy interface.

Configuration Files


Configuring Linux for TCP/IP is not difficult because only a few configuration files need to have the information about IP address and such added to them. You can do this with any editor as long as it saves the files in ASCII format. It is advisable to make copies of the configuration files before you modify them, just in case you damage the format in some way.

Many of these files are similar in every version of UNIX, including most versions of Linux, except for one or two slight naming variations. If you've ever set up a UNIX system (or snooped around one in detail), these files and steps might seem familiar. If you haven't done anything with Linux or UNIX before, just take it one step at a time and follow the instructions!

rc Files

Linux reads the rc (run command) files when the system boots. The init program initiates the reading of these files, and they usually serve to start processes such as mail, printers, cron, and so on. They are also used to initiate TCP/IP connections. Most Linux systems have the rc command files in the directory /etc/rc.d.

The files of interest to TCP/IP, at least as far as Red Hat Linux is concerned, are under the /etc/rc.d/rc2.d directory. The files in this directory start different TCP/IP services. The names of most of the files identify their purposes. For example, the file K20nfs deals with starting the NFS service.

If you want to change services that are started when Red Hat Linux boots, you can edit these files with as ASCII editor. Identify the file that is involved with the service you need to modify (you can often use grep to find the right file, or you can look through them all with more). Whichever file is involved, look for a line that refers to the service. In some cases, this line or lines will be commented out (have a pound sign as the first character) to prevent the system from trying to run them. If the lines are commented out, remove the comment symbol.

/etc/hosts

The /etc/hosts file is a simple list of IP addresses and the hostnames to which they correspond. This is a good location to list all your favorite machines so that you can use the name and have the system look up the IP address. On very small networks, you can add all the machines in the network here and avoid the need to run the nameserver.

Every /etc/hosts file will have an entry for localhost (also called loopback, IP address 127.0.0.1) and probably one for your machine if you named it when you installed the software. If you didn't supply a name and there is no line other than localhost, you can add it now. Use an editor and set your IP address and machine name. Don't bother adding too many other machines until you're sure the network works properly! Here's a sample /etc/hosts file: 


127.0.0.1 localhost

147.12.2.42 merlin.tpci merlin

You will notice that the format is quite simple: an IP address in one column and the name in another column, separated by tabs. If the machine may have more than one name, supply them all. In the example, which uses random numbers for the IP address, the machine 147.12.2.42 has the name merlin. Since it is also part of a larger network called tpci, the machine can be addressed as merlin.tpci. Both names on the line ensure that the system can resolve either name to the same address.

You can expand the file a little if you want by adding other machines on your local network, or those you will communicate with regularly: 


127.0.0.1 localhost

147.12.2.42 merlin.tpci merlin

147.12.2.43 wizard.tpci wizard

147.12.2.44 arthur.tpci arthur bobs_machine

147.12.2.46 lancelot.tpci lancelot

In this example, there are several machines from the same network (the same network mask). One has three different names.

If you are only using the loopback driver, the only line that should be in the file is for the IP address 127.0.0.1 with the name localhost and your machine's name after it.

/etc/networks

The /etc/networks file lists names and IP address of your own network and other networks you connect to frequently. This file is used by the route command. One advantage of this file is that it lets you call remote networks by name, so instead of typing 149.23.24, you can type eds_net.

The /etc/networks file should have an entry for every network that will be used with the route command if you plan on using the network name as an identifier. If there is no entry, errors will be generated, and the network won't work properly. On the other hand, if you don't need to use a network name instead of its IP address, then you can skip the /etc/networks file.

A sample /etc/networks file using random IP addresses is shown next. Remember that you need only the network mask and not the device portion of a remote machine's IP address, although you must fill in the rest with zeroes. 


loopback 127.0.0.0

localnet 147.13.2.0

eds_net 197.32.1.0

big_net 12.0.0.0

At a minimum, you should have a loopback and localnet address in the file.

/etc/host.conf

The system uses the host.conf file to resolve hostnames. It usually contains two lines that look like this: 


order hosts, bind

multi on

These tell the system to first check the /etc/hosts file, then check the nameserver (if one exists) when trying to resolve a name. The multi entry lets you have multiple IP addresses for a machine in the /etc/hosts file (which happens with gateways and machines on more than one network).

If your /etc/host.conf file looks like these two lines, you don't need to make any changes at all.

resolv.conf

The resolv.conf file is used by the name resolver program. It gives the address of your name server (if you have one) and your domain name (if you have one). You will have a domain name if you are on the Internet.

A sample resolv.conf file for the system merlin.tpci.com has an entry for the domain name, which is tpci.com (merlin is the name of an individual machine): 


domain tpci.com

If a name server is used on your network, you should add a line that gives its IP address: 


domain tpci.com

nameserver 182.23.12.4

If there are multiple name servers, which is not unusual on a larger network, each name server should be specified on its own line.

If you don't have a domain name for your system, you can safely ignore this file for the moment.

/etc/protocols

UNIX systems use the /etc/protocols file to identify all the transport protocols available on the system and their respective protocol numbers. (Each protocol supported by TCP/IP has a special number, but that's not really important at this point.) Usually, this file is not modified but is maintained by the system and updated automatically as part of the installation procedure when new software is added.

The /etc/protocols file contains the protocol name, its number, and any alias that may be used for that protocol. A sample /etc/protocols file looks like this: 


# Internet protocols (IP)

ip 0 IP

icmp 1 ICMP

ggp 3 GGP

tcp 6 TCP

egp 8 EGP

pup 12 PUP

udp 17 UDP

hello 63 HELLO

If your entries don't match this, don't worry. You shouldn't have to make any changes to this file at all, but you should know what it does.

/etc/services

The /etc/services file identifies the existing network services. This file is maintained by software as it is installed or configured.

This file consists of the service name, a port number, and the protocol type. The port number and protocol type are separated by a slash, following the conventions mentioned in previous chapters. Any optional service alias names follow. Here's a short extract from a sample /etc/services file: 


# network services

echo 7/tcp

echo 7/udp

discard 9/tcp sink null

discard 9/udp sink null

ftp 21/tcp

telnet 23/tcp

smtp 25/tcp mail mailx

tftp 69/udp

# specific services

login 513/tcp

who 513/udp whod

You shouldn't change this file at all, but you do need to know what it is and why it is there to help you understand TCP/IP a little better.

/etc/hostname or /etc/HOSTNAME

The file /etc/HOSTNAME is used to store the name of the system you are on. (Red Hat Linux uses the uppercase version of the name.) This file should have your local machine's name in it: 


merlin.tpci

That's all it needs. The host name is used by most protocols on the system and many applications, so it is important for proper system operation. The host name can be changed by editing the system file and rebooting the machine, although many operating systems provide a utility program to ensure that this process is performed correctly.

Linux systems have a utility called hostname, which displays the current setting of the system name, as well as the uname program, which can give the node name with the command uname -n. When issued, the hostname and uname commands echo the local machine name, as the following sample session shows: 


$ hostname

merlin.tpci.com

$ uname -n

merlin

All the configuration files necessary for TCP/IP to function have now been set properly, so you should be able to reboot the machine and see what happens.

Testing and Troubleshooting


To try out TCP/IP, reboot your machine and carefully watch the messages displayed on-screen. If you see any error messages, they may help guide you to the faulty file or process. Otherwise, you will see the TCP/IP daemons load one after another.

The netstat Command


Probably the best approach to checking on TCP/IP is to use the netstat command, which gives you many different summaries of all network connections and their status. The netstat program provides comprehensive information. It's the program most commonly used by administrators to quickly diagnose a problem with TCP/IP.

There are many more netstat options than the ones mentioned in the next sections. For more information on netstat, start with the man page on the Linux system, then check a good UNIX networking guide.

Communications End Points

The netstat command with no options shows information on all active communications end points (where data is actually being transferred or communications are established). To display all end points (active and passive), netstat uses the -a option.

The netstat output is formatted in columns that show the protocol (Proto), the amount of data in the receive and send queues (Recv-Q and Send-Q), the local and remote addresses, and the current state of the connection. Here's a truncated sample output: 


merlin> netstat -a

Active Internet connections (including servers)

Proto Recv-Q Send-Q Local Address Foreign Address (state)

ip 0 0 *.* *.*

tcp 0 2124 tpci.login oscar.1034 ESTABL.

tcp 0 0 tpci.1034 prudie.login ESTABL.

tcp 11212 0 tpci.1035 treijs.1036 ESTABL.

tcp 0 0 tpci.1021 reboc.1024 TIME_WAIT

tcp 0 0 *.1028 *.* LISTEN

tcp 0 0 *.* *.* CLOSED

udp 0 0 localhost.1036 localhost.syslog

udp 0 0 *.1034 *.*

udp 0 0 *.* *.*

udp 0 0 *.* *.*

This excerpt has three active TCP connections, as identified by the state ESTABL., with one that has data being sent (as shown in the Send-Q column). An asterisk means that no end point is yet associated with that address.

Network Interface Statistics

The behavior of the network interface (such as the network interface card) can be shown with the netstat -i option. This quickly shows administrators whether there are major problems with the network connection. The meaning of each column in the netstat command output is intuitive from the title, but if you need clarification check the man page on netstat.

Routing tables are continually updated to reflect connections to other machines. To obtain information about the routing tables (if there are any on your system), the netstat -r option is used.

ping


The ping (Packet Internet Groper) program is used to query another system and ensure a connection is active. The ping program operates by sending a request to the destination machine for a reply. If the destination machine's IP software receives the request, it issues a reply immediately.

The sending machine will continue to send requests until the ping program is terminated with a break sequence. After termination, ping displays a set of statistics. A sample ping session is shown as follows: 


prudie> ping merlin

PING merlin: 64 data bytes

64 bytes from 142.12.130.12: icmp_seq=0 time=20.0 ms

64 bytes from 142.12.130.12: icmp_seq=1 time=10.1 ms

64 bytes from 142.12.130.12: icmp_seq=2 time=10.3 ms

64 bytes from 142.12.130.12: icmp_seq=3 time=20.2 ms

64 bytes from 142.12.130.12: icmp_seq=4 time=10.1 ms

64 bytes from 142.12.130.12: icmp_seq=5 time=10.2 ms

64 bytes from 142.12.130.12: icmp_seq=6 time=10.1 ms

— merlin PING Statistics —

7 packets transmitted, 7 packets received, 0% packet loss

round-trip (ms) min/avg/max = 10/12/20

If ping was unable to reach the remote machine, it will display error messages. You can also ping the localhost, which will show if there is an error in the loopback driver configuration files.

The ping program is useful because it provides four important pieces of information: whether the TCP/IP software is functioning correctly, whether a local network device can be addressed (validating its address), whether a remote machine can be accessed (again validating the address and testing the routing), and verifying the software on the remote machine.

SLIP Connections


SLIP connections are configured in much the same manner as the TCP/IP connections described earlier. SLIP is one method of using a modem (or other serial port device) to communicate instead of a network card. SLIP is especially useful for connecting to the Internet through service providers such as UUNET Technologies or NetCom.

For SLIP connections, two Linux programs are involved: dip and slattach. Both programs are used to initiate the SLIP connection. One of the two must be used to initiate the connection. You cannot dial into a SLIP line with a standard communications program because of the special system calls SLIP uses.

dip and slattach have different purposes. The slattach program, which simply connects to the serial device, is used when there is a permanent connection to the SLIP server (no modem or setup handshaking is required). The dip program handles the initiation of the connection, the login, and connection handshaking. If you use a modem to connect to a SLIP server, you should use dip. The dip program can also be used to configure your own system as a SLIP server, allowing others to call in to it.

SLIP is a fairly simple network protocol because only two devices are involved: yours and the server's. When the connection is established, SLIP sends an IP address that will be used for that connection. Some systems use the same IP address (static), while others will have a different IP address each time a connection is made (dynamic). The configuration is slightly different for each type.

Static IP Addresses


A static connection requires that the IP addresses be included in the same files as for an Ethernet network connection. Your machine's IP address should be in the files /etc/hosts, host.conf, and resolv.conf. The gateway address should be the IP address of the SLIP server. The SLIP device files used are sl0, sl1, sl2, and so on.

The only difference in configuration between Ethernet and SLIP is that you only want to execute the ifconfig and route programs for the loopback driver with SLIP. If you use dip to establish the SLIP connection, it will probably take care of this for you, although some problems are occasionally encountered. In these cases, manual changes to the file should be made to allow ifconfig and route to be executed manually from the shell, or from inside a shell script.

The ifconfig routine might need to be modified with the argument pointopoint. SLIP is a variation of Point-to-Point Protocol (PPP). The line would look like this: 


ifconfig sl0 147.123.12.2 pointopoint 121.12.234.2

The first IP address (147.123.12.2) is your machine's IP address, and the numbers following the argument (121.12.234.2) are the IP address of the SLIP server.

Dynamic IP Addresses


If the SLIP server you are connecting to allocates IP addresses dynamically, you can't put an IP address in the configuration files, because it will change each time. Most SLIP servers display a message with the IP address when you connect, and dip can capture these numbers and use them to alter the system parameters appropriately.

dip


The dip program greatly simplifies the connection to a SLIP server. To use it, you need a chat script that contains all the commands used to establish communications with the SLIP server during login. The chat script usually includes your login and password too, automating the login process.

A sample dip chat script is included in the man pages for dip, so you should display the man page and read the contents, then save the file (by redirection or copying the man page source) and edit the script. Here's a sample chat script that you can enter by hand if necessary, making sure you put in your own data: 


# Connection script for SLIP

# Fetch the IP address of our target host.

main:

# Set the desired serial port and speed.

port /dev/cua0

speed 38400

# Reset the modem and terminal line.

reset

# Prepare for dialing.

send ATZ1\r

wait OK 4

if $errlvl != 0 goto error

dial 666-0999 ## Change to your server's number!

if $errlvl != 0 goto error

wait CONNECT 60

if $errlvl != 0 goto error

# We are connected. Log in to the system.

login:

sleep 3

send \r\n\r\n

wait merlin> 20 ## Change to your server's prompt

if $errlvl != 0 goto error

send login\n

wait name: 10 ## Wait username: prompt

if $errlvl != 0 goto erro

send login_name\n ## Change to your own

wait ord: 10 ## Wait password prompt

if $errlvl != 0 goto error

send my_password\n ## Change to your own!

wait merlin> 10

if $errlvl != 0 goto error

send slip\n ## Change to suit your server

wait SLIP 30 ### Wait for SLIP prompt

if $errlvl != 0 goto error

get $local remote 10 ## Assumes the server sends your IP..

if $errlvl != 0 goto error ## address as soon as you enter slip.

get $remote merlin ## slip server address from /etc/hosts

done:

print CONNECTED to $remote with address $rmtip we are $local

default

mode SLIP

goto exit

error:

print SLIP to $host failed.

exit:

# End dip script

Several different variations of the chat scripts are currently available, including a few on most CD-ROM distributions. If you have access to the Internet, you can find them on some FTP sites or posted on a Linux newsgroup.

Setting Up PPP


PPP is a more talented and faster protocol than SLIP and is preferable for most uses. The configuration, however, is a little more complex than SLIP's. Linux divides the PPP functions into two parts: one for the High-Level Data Link Control (HLDC) protocol which helps define the rules for sending PPP datagrams to between the two machines, and one for the PPP daemon, called pppd, which handles the protocol once the HLDC system has established communications parameters. In addition, Linux includes a program called chat that can be used to call a remote system, although there are several other applications that make use of PPP for the same reason. One popular communications package for this purpose is Kermit.

As with SLIP, PPP establishes a modem link between the two machines, and then hands over the control of the line to PPP. As the user, you never get to see a shell prompt or login, as PPP handles it all for you. Both HLDC and pppd are complex utilities with many options available to fine-tune their behavior. Because you will never use most of these options, we can safely ignore all but the most important aspects necessary to get a PPP connection up and running properly.

Prior to establishing a PPP link, you must have a loopback driver established. You should also have a name resolution system in operation, even if it's the /etc/hosts file or a simple DNS cache-only name server.

Setting Up a PPP Account


It is best to use PPP with a special user account called PPP for optimum protection and behavior. This is not necessary, and you can easily use PPP from any user account, but for more secure operation, you should consider creating a ppp user. The process is simple. First, you need to add a new user to the /etc/passwd file. You can use whatever script your system normally uses to add new users, or edit the /etc/passwd file yourself.

A sample /etc/passwd entry for the ppp account (with UID set to 201 and GID set to 51) looks like this: 


ppp:*:201:51:PPP account:/tmp:/etc/ppp/pppscript

In this case, the account is set with no password (so that no one can log into the account) and a home directory of /tmp (because no files are created). The startup program is set to /etc/ppp/pppscript, a file you create with the configuration information in it (you can use any filename, of course). A sample contents for the pppscript file looks like this: 


#!/bin/sh

mesg n

stty -echo

exec pppd -detach silent modem crtscts

The first line forces execution of the script into the Bourne shell. The second command turns off all attempts to write to the ppp account's tty. The stty command is necessary to stop everything the remote sends being echoed again. Finally, the exec command runs the pppd daemon (which handles all PPP traffic). You will see the pppd daemon and the options later in this section.

Dialing Out chat


PPP requires you to establish a modem connection to the remote machine before it can take over and handle the communications. Several utilities are available to do this, the most commonly used of which is chat. The chat program is popular because it uses a scripting style similar to that used by UUCP (see Chapter 43, "UUCP").

To use chat, you have to assemble a command line that looks almost the same as a UUCP /etc/Systems file entry. For example, to call a remote machine with a Hayes-compatible modem (using the AT command set) at the number 555-1234, you use the following command, which is all formatted as a "chat script," UUCP style: 


chat "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1

If you read the UUCP chapter, this may look familiar. If not, all the entries are in a "send-expect" format, with what you send to the remote specified after what you receive from it. The chat script always starts with an expect string, which we must set to be empty because the modem won't talk to us without any signal to it. After the empty string, we send the ATZ (reset) command, wait for an "OK" back from the modem, and then send the dial command. Once a CONNECT message is received back from the modem, the login script for the remote machine is executed: we send a blank character, wait for the ogin: (login) prompt, send the login name ppp, wait for word: (password) prompt, and then send our password. After the login is complete, chat terminates but leaves the line open.

If you want to see all the activity that goes on with the chat program, you can force all messages to the syslog daemon for future study. The -v option forces the messages to syslog, so the command would be: 


chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1

If the other end of the connection doesn't answer with a login script as soon as their modem answers, you may have to force a BREAK command down the line to jog the remote end. This is done in the same way as with UUCP: 


chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin:-BREAK-ogin: ppp word: secret1

There's a security problem with this type of chat entry, as any user doing a ps -ef command will see the entire command line (with its passwords). If you are the only user of your system, this isn't a concern, but to save yourself any problems you can embed the script portion of the command in a file and read the file into chat. The script will not appear on a ps output, then. To call a file for use with chat, use the -f option: 


chat -f chat_file

The chat_file will contain the string: 


"" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1

The chat script can help you detect common error conditions such as a line busy or no connection established. The messages from your modem (Hayes uses BUSY and NO CARRIER) are embedded in the chat script with the ABORT option, which allows you to exit gracefully from the chat script if one of these error conditions occurs.

To handle these abort conditions, you embed the chat keyword ABORT, followed by the message that should trigger an abort, prior to your normal chat script. For example, to modify the chat script above to abort on a BUSY or NO CARRIER message from the modem, the script would look like this: 


ABORT BUSY ABORT 'NO CARRIER' "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1

We needed two ABORT commands, as each takes only one argument. The rest of the chat script is as usual. Note the need to put quotation marks around the NO CARRIER message as the space in the middle would confuse the script otherwise.

Running pppd


To set up a PPP connection, you need to invoke the pppd daemon. If you have a PPP connection already established and your machine is logged into a remote using the ppp account, you can start the pppd daemon. If we assume your local machine is using the device /dev/cua1 for its PPP connection at 38,400 baud, you would start up the pppd daemon with this command: 


pppd /dev/cua1 38400 crtscts defaultroute

This command tells the Linux kernel to switch the interface on /dev/cua1 to PPP, and to establish an IP link to the remote machine. The crtscts option, which is usually used on any PPP connection about 9,600 baud, switches on hardware handshaking. The IP address the local system will use is taken from the local hostname unless one is specified on the pppd command line (which you will seldom need to do, as the local host IP address should be correct for the PPP line).

Other than the machine's default values, you can add the addresses with an option to pppd. The general format is to specify the local IP address, a colon, and then the remote IP address. For example, the option 


147.23.43.1:36.23.1.34

when added to the pppd command line sets the local IP address as 147.23.43.1 and the remote IP address to 36.23.1.34, regardless of that the local values are. If you only want to modify one IP address, leave the other portion blank. The command 


147.23.43.1:

sets the local IP address and accepts the remote IP address as whatever the machine sends.

Because you need chat to establish the connection in the first place, you can embed the chat command as part of the pppd command. This is best done when reading the contents of the chat script from a file (using the -f option). For example, you could issue the following pppd command: 


pppd connect "chat -f chat_file" /dev/cua1 38400 -detach crtscts modem defaultroute

You will notice a few modifications to the pppd command other than the addition of the chat command in quotation marks. The connect command specifies the dialup script that pppd should start with, while the -detach command tells pppd not to detach from the console and move to background. The modem keyword tells pppd to monitor the modem port (in case the line drops prematurely) and hang up the line when the call is finished.

The pppd daemon begins setting up the connection parameters with the remote by exchanging IP addresses, then setting communications values. Once that is done, pppd sets the network layer on your Linux kernel to use the PPP link by setting the interface to /dev/ppp0 (if it's the first PPP link active on the machine). Finally, pppd establishes a kernel routing table entry to point to the machine on the other end of the PPP link.

If you want to change the default behavior of the pppd daemon, you can do it through command line options or a control file. The file is a better approach if you want to change the parameters for every connection established using PPP.

Before completing the command line, pppd scans a number of possible options files. The more common file is /etc/ppp/options, which usually is used to set global defaults. An example of a /etc/ppp/options file looks like this: 


# /etc/ppp/options: global definitions

domain merlin.com

auth # force authentication

usehostname # use local hostname for authentication

lock # use file locking UUCP-style

The domain is established with the domain keyname followed by the full domain name (minus the machine name). The next two lines above (auth and usehostname) deal with authentication of the PPP line, preventing unwanted usage and access. We will look at authentication later in this section. The lock keyword tells pppd to use UUCP-style file locking to prevent device clashes. Locking should be used on all PPP systems to prevent problems.

Checking Problems


The pppd daemon echoes all warnings and error messages to the syslog facility. If you used the -v option with the chat script, chat's messages are also sent to syslog. If you are having trouble with your PPP connections, you can check the syslog for details and try to isolate the problem.

Unless there is an entry in the /etc/syslog.conf file that redirects incoming error and warning messages to another file, the messages are discarded by syslog. To save the messages from pppd and chat, add this line to the /etc/syslog.conf file: 


daemon.* /tmp/ppp-log

This entry tells syslog to save any incoming messages from a daemon to the /tmp/ppp-log file. You can use any filename you want instead of /tmp/ppp-log. Many Linux versions of the syslog.conf file insist on tabs to separate the columns instead of spaces. Once your script is working, remember to remove this line or the log file will grow quite large!

If you really want to watch what is going on with pppd, you can invoke a debugging option with the kdebug command followed by a number. There are three values for debugging, which are:

  1. 1. general debug messages

  2. 2. display incoming HLDC data

  3. 3. display outgoing HLDC data

The numbers are added together to give the debug level you want. For example, the command kdebug 5 will display all general debug messages and all outgoing HLDC data. A value of 7 displays everything (this display gets very long!). You can send the output to a file or the console.

PPP Authentication


PPP is a wonderful protocol for modem-based communications, but it has one major problem: it has security holes large enough to drive a bus through. If even slightly incorrectly configured, anyone can use the PPP line to get into your machine, or use the PPP line to get out to other systems. To help prevent this, authentication is often used. Authentication essentially makes sure that each end of the connection is who they say they are and are allowed to use the link. Authentication can also be used with SLIP, but not many systems support it.

There are two authentication schemes used by PPP: the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). PAP is much like a login procedure. When one machine sends the login name and password to the other, the receiving machine verifies the information with a database on its end. While simple, PAP has the problem that anyone can tap into the line and monitor the passwords being sent.

CHAP solves this problem, and hence is the most favored form of authentication for PPP links. CHAP allows one machine to send a random string to the other, along with its hostname. The other end uses the hostname to look up the proper reply, combine it with the first string, encrypt it, then resend it to the first machine along with its hostname. The first machine performs the same sort of manipulation on the random string it first sent, and if the two replies match, the authentication is complete. CHAP doesn't authenticate only a start time, but at random intervals throughout the connection, which adds to its power.

When two machines connect they don't use authentication unless explicitly instructed to do so (see the auth entry in the /etc/ppp/options file, discussed earlier). When authentication is active, one end will try to use CHAP first, then, if that fails because the other end doesn't support CHAP, it will use PAP. If neither authentication scheme is supported by the other end, the connection is terminated. If you are going to use authentication for all your PPP connections, put the auth entry in the /etc/ppp/options file. If not all your connections support authentication, then those connections will fail if auth is specified.

The information needed for both CHAP and PPP are kept in two files called /etc/ppp/chap-secrets and /etc/ppp/ppp-secrets respectively. When authentication is active, one end will check the other for these files, trying CHAP first. If you are going to use authentication for all your connections (which is a very good idea), you can build up the chap-secrets and pap-secrets files. If you configure both chap-secrets and pap-secrets and specify the auth option in /etc/ppp/options, no unauthenticated host can connect to your machine.

The /etc/ppp/chap-secrets file consists of four columns for the client name, the server name, the secret password string, and an optional list of IP addresses. The behavior of the system is different depending on whether the local machine is being challenged to authenticate itself, or is issuing a challenge to the remote. When the local machine has to authenticate itself, pppd examines the /etc/ppp/chap-secrets file for an entry in the client field that matches the local host name and the server field equal to the remote hostname, then uses the string to build the authentication message. Such as entry in the /etc/ppp/chap-secrets file looks like this: 


# client server string addresses

merlin.tpci.com big_guy.big_net.com "I hate DOS"

This entry will use the string "I hate DOS" to build an authentication message back to big_guy.big_net.com. The quotations are necessary to surround the string in the file. (We will look at the addresses column in a moment.) If you are setting up your system to connect to three different PPP remotes, you will want an entry for each server, so your file may look like this: 


# client server string addresses

merlin.tpci.com big_guy.big_net.com "I hate DOS"

merlin.tpci.com chatton.cats.com "Meow, Meow, Meow"

merlin.tpci.com roy.sailing.ca "Hoist the spinnaker"

When your machine is sending the challenge, the process is reversed. The pppd daemon looks for the remote hostname in the client field, the local hostname in the server field, and uses the string to compare the encryption results with the string sent back by the remote. Entries in the /etc/ppp/chap-secrets file for this purpose look like this: 


# client server string addresses

big_guy.big_net.com merlin.tpci.com "Size isn't everything"

Again, you will have an entry for each remote machine you may need to authenticate. You can see that you will end up having mirror image entries for the client and server fields for each machine you connect to (as either end may require authentication at any time). A simple /etc/ppp/chap-secrets file really looks like this: 


# client server string addresses

merlin.tpci.com big_guy.big_net.com "I hate DOS"

big_guy.big_net.com merlin.tpci.com "Size isn't everything"

merlin.tpci.com chatton.cats.com "Meow, Meow, Meow"

chatton.cats.com merlin.tpci.com "Here, Kitty, Kitty"

merlin.tpci.com roy.sailing.ca "Hoist the spinnaker"

roy.sailing.ca merlin.tpci.com "Man overboard"

The size of the file could get quite large, so CHAP allows you to use a wildcard match, usually only for your local machine. For example, in the /etc/ppp/chap-secrets file below: 


# client server string addresses

merlin.tpci.com big_guy.big_net.com "I hate DOS"

big_guy.big_net.com merlin.tpci.com "Size isn't everything"

merlin.tpci.com chatton.cats.com "Meow, Meow, Meow"

chatton.cats.com merlin.tpci.com "Here, Kitty, Kitty"

merlin.tpci.com roy.sailing.ca "Hoist the spinnaker"

* merlin.tpci.com "Man overboard"

The last entry allows any other machine connecting to the local host and requiring authentication to use the same string. Of course, the remote must have the same string in its chap-secrets file. This is a little less secure that a dedicated string for each remote, but can be a handy time-saver when using a number of machines only rarely.

The addresses field, which wasn't used in the samples above, lets you list either symbolic names or IP addresses for the clients. This is necessary if the remote wants to use another IP address than its normal one, which would cause the authentication to fail normally. If the addresses field is empty (as they all are in the samples), any IP address is allowed. A hyphen in the field disallows all IP addresses with that client.

The /etc/ppp/pap-secrets file is much the same as the chap-secrets file. The fields in the pap-secrets file are the client (called a user in the pap-secrets format) and server names, a secret string, and valid address aliases. However, the look of the file is different because the client and server names are not full domain names and the secret string is a single block of text. A sample pap-secrets file looks like this: 


# /etc/ppp/pap-secrets

# user server string addresses

merlin darkstar yG55Sj29 darkstar.big_net.com

darkstar merlin 5Srg7S merlin.tpci.com

merlin chatton MeowMeow chatton.cats.com

chatton merlin 73wrh6s merlin.tpci.com

In this example, the first two lines show a connection to the machine darkstar. The first line is how we authenticate a request from darkstar, and the second how we authenticate a request from us to them. The user name in the first column is the name we send to the remote, while the server field is their identification to us. This poses a problem: The pppd daemon has no way of knowing the remote hosts name, as all it gets is an IP address. You can put the IP address in the addresses column of the file, or you can specify the remote host name at the end of the pppd command line like this: 


pppd ..... remotename chatton user merlin

This shows that the remote is called chatton, and our local host is merlin. The last portion giving the local host name override the default values, if specified.

Summary


In this chapter, you've seen how to install, configure, and test Ethernet connections to your Linux machine. You've also seen how to set up a SLIP or PPP connection. The only other networking process usually found on a Linux box uses UUCP (UNIX-to-UNIX Copy), which is described in Chapter 43, "UUCP."

If you want to install a network to connect several of your machines (assuming you have more than one), you will find it quite easy and useful. If you have two machines, it is fast and efficient to connect a Linux machine and a DOS machine, as long as the DOS machine is running TCP/IP. There are shareware versions of TCP/IP for Windows and many commercial implementations for both DOS and Windows, and TCP/IP is built into both Windows 95 and Windows NT.

Previous Page Page Top TOC Next Page

Mobile News

New Huawei Phones

3 new phones from "Huawei" .. here is the date of its launch

Samsung phone 2020

According to the experts ... this is the best Samsung phone for 2020

Tech News

Moto G8 Power phone

5.0 New

Motorola unveils the Lite version of its Moto G8 Power phone!

New IPhone SE

5.0 New

The announcement of the low-spec iPhone SE is imminent!