Abstract v 1.3, 13 February 1999
This document is a step-by-step guide to setting up a Linux dialin server which allows SLIP and PPP connections over a phone line.
Copyright 1999 Josh Gentry
I encourage redistribution of this document, non-commercial and commercial. I would like to be notified of redistribution. You are NOT permitted to alter the contents of this document, though I do not care about changes in presentation.
Acknowledgments Much of the information in this document was originally gleaned from the following LDP HOWTOs: Linux Serial HOWTO Linux Modem HOWTO Linux Kernel HOWTO
Linux PPP HOWTO
A great deal of information was found in Gert Doering’s online documentation for mgetty+sendfax. Additionally, the following online documents were valuable in the configuration of AutoPPP in mgetty:
http://members.bellatlantic.net/~mrdennis/mgetty.html, Mick Dennis http://oh3tr.ele.tut.fi/~oh3fg/ppp/ppps.html, Kalevi Hautaniemi
Much information on PAP was learned from Olaf Kirch’s Linux Network Administrators’ Guide and the S.u.S.E. Support Data Base (http://wi-pc44.fh-konstanz.de/support-db/sdb_e/kfr_17.html).
The majority of the information in this document was originally gathered for, or derived from the process of setting up a Linux RedHat 5.1 dialin server for Mr. James Hart. He teaches at the Technical/Vocational Institute in Albuquerque, NM. Tony Lucero was my partner on that project. Their help and guidance were invaluable.
Finally, a big thank you to all those who have aided in the development of the Linux kernel and Linux applications. This document is my small contribution to their effort.
This document carries no explicit or implied warranty. Nor is there any guarantee that the information contained in this document is accurate. It is offered in the hopes of helping others, but you use it at your own risk. The author will not be liable for any damages that occur as a result of using this document.
A dialin server is a host equipped with a modem and phone line, that allows other hosts with modems and phone lines to call and connect to it. There are several reasons a person might want to do this; to use the resources on the dialin server, or, if the dialin server is on a network, to use the dialin server to access the network. Further, if this LAN is connected to the Internet, the client may be able to access the Internet via the dialin server.
1.1 Raison d’être
The majority of information needed to setup a Linux dialin server is available in LDP HOWTOs. When I used these documents to setup such a server, however, the fragmentary nature of the information was a major obstacle. This document consolidates much of the needed information and presents it as a step-by-step guide.
1.2 This Document as Guide
Setting up a dialin server is a common project, but not a simple one. This document attempts to rigorously set forth a step-by-step guide to the process. It is likely, however, that you will need to reference additional documents. The LDP HOWTOs listed above should be considered invaluable companions to this document, and should be consulted in the order listed above. Furthermore, do not neglect the documentation included with your getty and PPP packages.
1.3 Clients and Servers
The protocols used to connect two hosts via a phone line are technically peer-to-peer protocols; there is no real difference between the machine that dials and the machine that is dialed into. Conceptually, however, it is easier to think in client/server terms. « When you dial into a site to establish a PPP connection, you are a client. The machine to which you connect is the server. » (Linux PPP HOWTO, Hart) I will use this convention throughout the document.
Setting up a dialin server is the process of setting up a machine to answer the phone, participate in the setup of a connection with the client, and authenticate the client.
1.4 Differences Between Linux Distributions
My experience is with RedHat Linux 5.1. I believe most of the information in this document will apply to all distributions. Where I am aware of or suspect differences between distributions, I will note it in the text.
1.5 Software Packages Covered
Linux kernel v2.0.34–http://sunsite.unc.edu/LDP/HOWTO/INFO-SHEET.html
2 Modem Installation
For a host to be a dialin server, it must be physically possible to dial into it. This requires that the host have at least one modem and phone line. Modems are serial devices, therefor it is highly recommended that you read the Linux Serial HOWTO, as well as the Linux Modem HOWTO.
2.1 Modem Type
Plug-and -Play modems are not well supported by Linux. This means that you want a jumperable modem, or an external modem. Start by asking your vendor what brand they recommend.
Serial ports, like all I/O ports, have an address. By default, Linux initializes four serial devices. Some may be familiar with these ports as Microsoft refers to them, COM 1-4. In Linux these ports are referred to as ttyS0-ttyS3. For example, the port known to Microsoft as COM 1, would be known to Linux as ttyS0. Note that if you use use a port address other than these four, you will have to initialize that port with « setserial. » See the « setserial » man page. External modems plug into external serial ports (RS-232 ports) on your PC. These ports are automatically assigned an address by Linux. Internal modems plug into the internal PCI or ISA slots of your PC. An internal modem is actually a modem and a serial port. It carries its own, and it is the modem’s serial port that you plug into the internal slot. For these modems, you set the port address on the modem. This is why you want a jumperable modem. You use the jumpers to manually set address and IRQ. The prepriatorial modem documentation should explain how to set the jumpers for port address and IRQ.
Note, if your PC has two external serial (RS-232) ports, as most PC’s do, the Linux Modem HOW-TO recommends setting your internal modem address to ttyS2 or higher.
3 Kernel Support
This is the part of the process most likely to scare those new to Linux. It scared me. Turns out not to be as difficult as you think, and if you do make a mistake, you can usually just recompile your kernel again. You should now read the Linux Kernel HOWTO. There is an alternative to compiling the PPP driver into the kernel. You can install the driver as a loadable module. The advantages of this are that your kernel is smaller, and it is not necessary to recompile. The PPP driver is linked to the kernel and loaded into memory space only when it is needed. I believe the argument for compiling the driver into the kernel is that PPP does execute faster if it is compiled into the kernel. You can link the loadable module to the kernel by recompiling the kernel as described below, but as Matt Kressel has pointed out to me, if you have the « insmod » command installed on your system, it is not neccessary to recompile. Issue the command « insmod ppp » to install the PPP driver as a loadable module. I found that I had to « insmod slhc » before I could successfully install PPP with « insmod ppp ». I am not sure why, but « insmod ppp » would not work without the slhc module.
The command « lsmod » lists the loadable modules currently installed on the system. There is also a command for removing modules. If these commands are installed on your system, then you should also have the man pages. Do a « man insmod » for more information.
3.1 Kernel and Source Code
The kernel is a binary, an executable program. Developers do not write the kernel as an executable, they write code that is fed into a compiler, and the compiler produces the executable from that source code.
With Linux, you have the source code that is used to produce the kernel executable. This means that you can customize your kernel to include only the capabilities that you need, creating a leaner, meaner kernel. Because of this, you can not assume that a kernel includes support for specialized tasks, such as those required for networking. You will have to check and see, and if your kernel does not contain the necessary support, you will have to recompile your kernel.
3.2 Recompiling the Kernel
To compile the kernel, you create a configuration file. You can check your current configuration file to see if needed capabilities are already compiled into your kernel. Most dialin servers will be hosts on a LAN. This document assumes that the host is already configured as part of the LAN. If this is not the case, you should reference other documents at the LDP before continuing, such as the Linux Network Administrators’ Guide. I prefer to use xconfig. It is a graphical tool for viewing and modifying the kernel configuration file. It requires that you have X-windows installed and running, and that you have Tk installed. In xconfig you will find the options for SLIP and PPP support in the category « Network devices. » These have to be supported for a SLIP and PPP dialin server. If the server will provide access to a network, the kernel must include support for IP forwarding. In xconfig this is found in the category « Network options. »
If you must recompile the kernel, it is highly recommended that you read the Linux Kernel HOWTO. These are the basic steps:
1. Make a copy of your present kernel in case of emergency 2. cd /usr/src/linux-(kernel version number) 3. Issue the command « make config ». If you are running X-windows you can try « make xconfig » to use a point-and-click interface for this process. 4. Say « yes » to all the proper networking options: SLIP, PPP, IP forwarding, etc (your LAN network configuration should already be configured). 5. Save and exit 6. Issue the command « make dep » 7. Issue the command « make clean » 8. Issue the command « make zImage » 9. cd /usr/src/linux-(kernel version number)/arch/i386/boot 10. cp zImage /vmlinuz (or wherever your kernel resides)
11. Issue the command « lilo »
That should do it. The Linux Kernel HOWTO states that you should be able to issue the command « make zlilo » after you have made the zImage, and that making zlilo will copy and install the new kernel for you. This did not work on my system, however.
You will need a getty that can handle modem communications. Once started, usually from inittab, the getty runs as a background process. Your modem getty will be idle until the modem receives a call, at which point it will « answer » the phone and negotiate the specifics of modem-to-modem communication with the client. There are several gettys that can be used for this task. This document covers the usage of mgetty. You can acquire the mgetty+sendfax package and official documentation at Gert Doering’s website, http://www.leo.org/~doering/mgetty. It was included with RedHat 5.1 and lived in /sbin/mgetty and /etc/mgetty+sendfax. Note that anytime you see something like « /sbin/mgetty » that it is simply the path to the file. Files may be located in different locations in the directory structure on different machines, and possibly with different distributions. Therefor, the path to the file would be different. You will need to verify the location of the necessary files on your system. There are many options for mgetty that you can edit to your desired configuration, most importantly in /etc/mgetty+sendfax/mgetty.config. Refer to the mgetty documentation if you need to make changes to the default settings. The default settings worked for us. If you wish to enable AutoPPP, you will need to edit /etc/mgetty+sendfax/login.config. Detailed instructions on that task appear later in this section.
To start mgetty, edit /etc/inittab. Here is another point where the serial and modem HOWTOs are helpful. You must tell mgetty which serial port to monitor. In Linux these ports are numbered 0-3, and named ttyS* for dialin. For a modem we installed on the third internal port, we added this line to /etc/inittab:
S2:2345:respawn:/sbin/mgetty ttyS2 -D /dev/ttyS2
The option « -D » tells mgetty to expect data only, no faxes. After this use the command « kill -1 1 » to force initd to re-read inittab. This will cause mgetty to be started. Note that if you use a multi-port serial board, those ports might be named differently than the four ports Linux initializes by default. In his excellent document on mgetty and AutoPPP, Mick Dennis reports naming the ports on his Cyclade Cyclom 16YeP as /dev/ttyC*.
Using the default settings, mgetty negotiates a SLIP (Serial Line Internet Protocol) connection and allows authentication via /etc/passwd. This is a functional system that allows a user to login to a shell account. If desired, a mechanism can be provided to allow users to start pppd after logging in over there SLIP connection. First, make sure that all users have permission to execute pppd by issuing the command:
chmod u+s /usr/sbin/pppd
Next, add this line to /etc/bashrc:
alias ppp= »exec /usr/sbin/pppd -detach »
This way, after the user has logged in over the SLIP connection, they can start pppd by typing « ppp. » This procedure is taken from Robert Hart’s Linux PPP HOWTO.
Another option is to create a PPP account. The entry in /etc/passwd might look like this:
When a user connects they simply login as « ppp. » Once they provide the password, pppd starts automatically.
For Microsoft clients to work with this setup, the client must be configured to provide a terminal screen after connection. This is not a default setting. These are the steps to do it in Windows 95:
1. Click on My Computer 2. Click on Dial-Up Networking 3. Right-click on the icon for the connection 4. Click on Properties 5. Click on Configure 6. Click on Options
7. Click box next to « Bring up terminal window after dialing »
4.1 AutoPPP and mgetty
Most Windows users will not like the requirement to use a login screen after connecting to the server. It is possible for the system administrator to remove this annoying extra step by using mgetty’s ability to start pppd upon initiating a connection. To do this, you enable AutoPPP.
4.2 Compiling mgetty
Note: I have been told by several people, that when they chose to install mgetty from their Redhat 5.2 distribution mgetty was automatically compiled to include AutoPPP.
For AutoPPP to function, you must edit the makefile before compiling. On or near line 110 you will need this:
CFLAGS=-02 -Wall -pipe -DAUTO_PPP
After that edit, compile mgetty according to the mgetty documentation instructions.
Next, you edit /etc/mgetty+sendfax/login.config to look like this around line 50:
/AutoPPP/ – – /usr/sbin/pppd file /etc/ppp/options.server
Once you have completed this configuration, mgetty will automatically start pppd when it receives the LCP configure request. (For more on LCP read the pppd man page.) The « file » option tells pppd to read the file /etc/ppp/options.server instead of the default /etc/ppp/options. Since pppd uses /etc/ppp/options for acting as a client or server by default (remember, it is technically peer-to-peer), using this option helps keep the desired options for acting as client or server separate. Assuming that you have edited /etc/mgetty+sendfax/mgetty.config to your preferences, you are done. Note that in every instance that you change the options for a process, the process will have to be restarted before the new options can take affect.
Note: If you wish to be able to dial out with a modem that is being monitored by mgetty, you will need to pay attention to what device your communications program uses. See http://www.leo.org/~doering/mgetty/mgetty_10.html#SEC10
5 PPP (Point-to-Point Protocol)
The Point-to-Point Protocol is the most popular protocol used for connecting hosts by phone line.
5.1 Compiling pppd
Adhere to the PPP package documentation. If you will be using shadow passwords, you will need to use the following command:
To use the MS-DNS option for Windows compatibility, and shadow, use:
make USE_MS_DNS=1 HAS_SHADOW=1
For more on this, see http://oh3tr.ele.tut.fi/~oh3fg/ppp/ppps.html.
5.2 Configuring pppd
PPP is configured by editing the options files read by pppd in /etc/ppp. Remember that in this configuration pppd will read /etc/ppp/options.server when it is started by mgetty. The most complete list of pppd options I have found is in the pppd man page. If you do not use PAP or CHAP, your file /etc/ppp/options.server might look like this:
-detach asyncmap 0 modem crtscts lock proxyarp ms-dns aa.bb.cc.dd
-detach-do not fork to become a background process asyncmap 0-to allow pppd to work over a rlogin/telnet connection modem-use the modem control lines crtscts-use hardware flow control lock-specifies that pppd use the UUCP-style lock on the serial device proxyarp-adds an entry into the ARP table with the IP address of the client and the IP address of the NIC
ms-dns-specifies the address of the DNS server to be used by Microsoft clients (As far as I know, there is now equivelent option for non-Microsoft clients. A Linux client must have the address of the DNS in /etc/hosts.)
5.3 Configuring + PAP
PAP (Password Authentication Protocol) is one of the two protocols that PPP uses to authenticate peers. The other is CHAP (Challenge Handshake Authentication Protocol). CHAP is a more secure protocol, but is not as widely supported as PAP. Thus, this document addresses the use of PAP, only. For more information on both PAP and CHAP, see Olaf Kirch’s Linux Network Administrators’ Guide. Since PPP is technically a peer-to-peer protocol, PAP allows two-way authentication. This means that not only the « server » can request the « client » to authenticate itself, but the reverse is also true. The « client » can require the « server » to authenticate itself. In practice, this in not often done. Most PPP servers are not configured to authenticate themselves to clients.
It is not difficult to configure your PPP server to use PAP. To the /etc/ppp/options.server file above, simply add the following entry:
With this configuration, pppd will check client login names and passwords against the file /etc/ppp/pap-secrets. The client will be granted access only if it matches an entry I /etc/ppp/pap-secrets. Example:
#user server secret addrs
jdoe * password *
If the « server » and « addrs » fields are filled in, then the client will only be granted access if the login name and password are sent from the designated server and IP address/fully qualified domain name.
5.4 PAP using /etc/password
If you do not wish to create an entry in /etc/ppp/pap-secrets for each client allowed PPP access, you can instruct pppd to check login names and passwords against /etc/passwd instead of /etc/ppp/pap-secrets. Add the option « login » to /etc/ppp/options.server. For this configuration, your /etc/ppp/options.server file will look like this:
-detach asyncmap 0 modem crtscts lock require-pap refuse-chap login proxyarp ms-dns aa.bb.cc.dd
If the « login » option is used, the file /etc/ppp/pap-secrets need not exist. In fact, it might interfere with the proper functioning of PAP. You can remove the file, or it can contain the following line:
* * « »
The advantage of maintaining /etc/ppp/pap-secrets with this line is that it leaves you the option of denying PPP access to individual accounts that have entries in /etc/passwd. To do so, below the above line, enter the following line:
username * –
where « username » is the username of the account you wish to deny PPP access. Example:
#user server secret addrs * * « » *
jdoe * – *
5.5 IP Address Allocation with PPP
For PPP to work, the client must have an IP address. Most dialin clients will not have their own IP address, so it is necessary to assign an IP address to the serial port that the client connects through. Earlier, we created a PPP options file that specifies the configuration of PPP connections the server will provide, /etc/ppp/options.server. It is also possible to create an options file that is specific to connections made through a specified serial port. For example, to create a file for ttyS2, your create the file /etc/ppp/options.ttyS2.
One of the options that can be defined in such a file is IP address assigned to the port for PPP connections. This is the format for this option:
The first IP address, from left to right, is the IP address of the server. The second IP address is the IP address assigned to the serial port for PPP connections.
Note, it is extremely important that you verify that the IP address you assign to the serial port is a valid IP address on your subnet, and that it is not assigned to any other device on the network.
You are done.
Feed back on this document is appreciated: email email@example.com