Written by Bill Parker on 2004-01-02 with
Assistance Provided by Kurt Wall and users rezidew and jgaddis on Undernet IRC #Linux channel.
Kurt provided initial source for info on this subject, since the PPP HOW-TO on sunsite.unc.edu/LDP is very out of date
Rezidew provided the ipchains line needed for ppp0 to surf from a MS
DUN connection using an IP of your actual class C, instead of a masq'd
private IP address.
System Tested: OpenLinux 2.2 & 3.1
How to run PPP Server on Linux (using a 2.2.x or 2.4.x based Kernel)
This document describes how to set up a Linux box that is on a network
for dial in (modem) access (so far tested with win 95 client only), but
should work for Win98/ME/XP, etc.
1. Things to ensure you have installed first:
mgetty (version 1.1.22_Aug17-9 is what I use)
- ppp (version 2.3.5 or better, I currently run ppp 2.4.0-7)
- ppp-devel (version 2.3.5 or better, same as above version)
- modem attached to either COM1 (ttyS0) or COM2 (ttyS1) (can be
internal or external, do NOT use a winmodem) (should be 28.8K or faster
IMPORTANT: The following commands below require ROOT access in order to be executed
Now on my machine, I have dual NIC's, and a(n) assigned class C for use
in the office and the connection to the internet is a permanent one via
a CISCO 3640 router (this is on eth0). eth0 has a(n) assigned
address of xxx.xxx.xxx.25 (Part of my Class C, the gateway for eth0 is
the IP address of the router described above).
eth1 has a(n) assigned address of 192.168.3.1 (for IP masq client's in
the office). ppp0 has a(n) assigned address of xxx.xxx.xxx.150
(assigned in /etc/ppp/options.server).
The client logging into the linux box is assigned an address of
xxx.xxx.xxx.151. Note that the xxx.xxx.xxx.151, .150, and .25 are
part of my assigned Class C.
2. Configuring mgetty to work with your system:
in /etc/mgetty+sendfax/mgetty.config, you should have the following options enabled (i.e. uncommented):
# US Robotics 28.8 External Data/Fax Modem on COM2 (ttyS1) no fax
init-chat "" AT&F1&C1&D2
debug 3 <--- I used debug 9 when testing, lotsa stuff gets logged
(this applies if your modem is on COM2, if it is on COM1/ttyS0) change the port line to ttyS0).
In /etc/inittab, you should have the following line, if not, then add it:
# Run gettys in standard runlevels
1:12345:respawn:/sbin/getty tty1 VC linux
2:2345:respawn:/sbin/getty tty2 VC linux
3:2345:respawn:/sbin/getty tty3 VC linux
4:2345:respawn:/sbin/getty tty4 VC linux
5:2345:respawn:/sbin/getty tty5 VC linux
6:2345:respawn:/sbin/getty tty6 VC linux
s1:2345:respawn:/usr/sbin/mgetty ttyS1 <---- This is the line I am talking about
Remember, ttyS0 = COM1, ttyS1 = COM2, ttyS2 = COM3, and ttyS3 = COM4
After making sure this file has the following information in it, issue the following command:
/sbin/init q <cr>
To make mgetty re-read the /etc/inittab
file (i'm not sure if this needs to be done, but I did it
anyways). A good test to run first is to see if you can get
access to your linux box via a terminal program (Hyperterm for windows
is a good choice):
If you are able to connect to your linux box and get the login: prompt,
proceed to step 3 "making sure pppd is set up properly".
Otherwise, go back and check your mgetty.config file in /etc/mgetty.config
Also another file to check is /etc/pam.d/login and make sure the following line is commented out:
auth required pam_dialup.so
insert a # in front of the line to comment out.
3. making sure pppd is set up properly:
PPPD will not run for regular users unless the sticky bit is set!!! To set the sticky bit use (as root):
chmod u+s /usr/sbin/pppd <enter>
If you are running Red Hat Linux, pppd is under /sbin rather than /usr/sbin
ls -al of /usr/sbin/pppd (or /sbin/pppd) should look like this:
-r-sr-x--- 1 root root 138724 Sep 16 23:15 /usr/sbin/pppd
3.1 next the following information should be in /etc/mgetty+sendfax/login.config:
# Automatic PPP startup on receipt of LCP configure request (AutoPPP).
# mgetty has to be compiled with "-DAUTO_PPP" for this to work.
# Warning: Case is significant, AUTOPPP or autoppp won't work!
# Consult the "pppd" man page to find pppd options that work for you.
# NOTE: for *some* users, the "-detach" option has been necessary, for
# others, not at all. If your pppd doesn't die after hangup, try it.
/AutoPPP/ - @ /usr/sbin/pppd file /etc/ppp/options.server
The /AutoPPP line is the
section to be concerned about, as there are other sections which do not
apply to this HOW-TO...the file that pppd will read it's information
from is in /etc/ppp/options.server. On OpenLinux 2.x
distributions mgetty is already compiled with -DAUTO_PPP, so it should be ok for use right out of the box.
3.2 in /etc/ppp/options.server the following information should be included:
# Auto Login for callin users
# Address of ppp0 on server side is xxx.xxx.xxx.150
# Address of ppp on client side is xxx.xxx.xxx.151
Now as you might notice, there is a small difference from the PPP
HOW-TO document in terms of setting up PPP server...you will note that
the proxyarp line in the file is commented out. This is due to
the fact that IP masq (via IPchains/IPtables) is being run on this box
(and with the proper ipchains/iptables entry, proxyarp is not needed).
These options tell pppd to use PAP for authentication (which most
95/98/NT clients use). The ms-dns entries should point to
whatever primary and secondary DNS servers that you use on your box
(the entries above are for UUnet, but don't use them unless you get
your permanent net access from UUnet).
3.3 in /etc/ppp/pap-secrets the following information should be present:
# Secrets for authentication using PAP
# client server secret IP addresses
* * "" *
The last line allows any user in /etc/passwd (shadow or non-shadow password) to log in and use PPP
4. At this stage a user should
be able to log in and connect to a system like the one which I have
described above (2 NIC's, IP masq, single modem)...however, you may
find that the remote client (in my case I used a win95 machine to make
the remote connection) is unable to surf the web or ping addresses on
the internet (except for xxx.xxx.xxx.150 or .151 or .25). If this
happens, don't panic, but look at the next section below (this took me
a week to solve with the help of several people):
After logging in, if you issue the following commands (one at a time):
w <enter> (you should get output which may look something like you see below)
5:03pm up 31 days, 5:06, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
/AutoPPP ttyS1 31200/ARQ/V34/LA 4:03pm 1:00m 0.05s 0.05s pppd file /etc/ppp/options.server
billp ttyp1 192.168.3.4 1:39pm 0.00s 0.35s 0.05s w
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:234378 errors:0 dropped:0 overruns:0 frame:0
TX packets:234378 errors:0 dropped:0 overruns:0 carrier:0
eth0 Link encap:Ethernet HWaddr 00:A0:C9:E3:F8:8D
inet addr:xxx.xxx.xxx.25 Bcast:xxx.xxx.xxx.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12096640 errors:0 dropped:0 overruns:0 frame:0
TX packets:10929152 errors:0 dropped:0 overruns:0 carrier:0
Interrupt:11 Base address:0x6000
eth1 Link encap:Ethernet HWaddr 00:A0:C9:67:EE:E5
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10964114 errors:0 dropped:0 overruns:0 frame:1
TX packets:10149109 errors:0 dropped:0 overruns:0 carrier:0
Interrupt:10 Base address:0x6100
ppp0 Link encap:Point-to-Point Protocol
inet addr:xxx.xxx.xxx.150 P-t-P:xxx.xxx.xxx.151 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:237 errors:0 dropped:0 overruns:0 frame:0
TX packets:203 errors:0 dropped:0 overruns:0 carrier:0
Do NOT let the NOARP entry on ppp0 disturb you at this point.
/sbin/route -n <enter>
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
xxx.xxx.xxx.151 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
xxx.xxx.xxx.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 xxx.xxx.xxx.128 0.0.0.0 UG 1 0 0 eth0
Note that where you see xxx.xxx.xxx entries, this should correspond to
your Class C that you were assigned, and the last entry in the table
under "Gateway" should be the IP address of your router. In order
to get the remote client to work, an addition to ipchains/iptables was
needed since my machine uses IP masq for clients inside the office:
/sbin/ipchains -A forward -s xxx.xxx.xxx.151 -d 0.0.0.0/0 -j ACCEPT
or if you are using iptables (most everyone is these days):
/sbin/iptables -A FORWARD -s xxx.xxx.xxx.151 -d 0.0.0.0/0 -j ACCEPT
This allows information to go back and forth over the ppp0 interface
which would have come up when the connection was made (the above entry
is only needed if you are assigning IP's to your clients which are part
of your actual class C, if you are assigning an IP address which is
already being masq'd on a NIC (i.e. eth1 as listed above in the routing
table, you do not need the above line). At this point, if you are
logged into the box from a win 95/98 or NT client,
you should be able to ping some sites on the internet (i.e. www.ibm.com, etc). If you are able to do this, you have dial in PPP Server working on your machine.
I almost forgot, when you bring down the ppp connection, there is a
chance that the ppp0 interface may NOT be removed, and in addition, the
route for ppp0 may NOT be removed. To insure the interface and route
are removed each time ppp0 is brought down, add the following lines
below to the bottom of 'if-down' in /etc/ppp:
/sbin/route del $5
/sbin/ifconfig $1 down
This should insure that the route and interface configuration are
removed each time a ppp connection is broken. If not, then re-check all
of the information presented above.
Be advised, I have not tried this with a machine which only has a
single NIC installed as eth0 and getting pppd running, but the process
should be very similar to what has been described above.
Advanced information for PPP Server:
In doing additional research on my own, I have found that the
/dev/ttySx line in section 3.2 does not appear to be needed, as I
commented the line out on my system, and dial in access continues to
The other issue is with security, if you have a machine like mine using
Dual NIC's, and you don't want to assign parts of your actual Class C
block (costs the company $$$ mind you), you can use ipchains to allow
the use of private ip addresses in the range of 192.168.x.x.
As an example, if I were to use private ip addresses on the host and client side, it would look something like this:
192.168.2.150:192.168.2.151 (where 150 is what ppp<n> is assigned on your linux box),
and 151 is what the machine dialing into your box receives as an actual ip address.
If you are planning to connect more than one modem to your computer, I believe the following will work in /etc/inittab:
Add entry which looks like this for 2nd modem (assume 1st modem is on com1)
and then issue /sbin/init q to respawn.
Also, if you are using more than one modem, you will want to set up
individual /etc/ppp/options.ttySx files which contain the host and
client ip addresses (for example):
in /etc/ppp/options.ttyS0 I have
and in /etc/ppp/options.ttyS1 I have
so in the event a user dials in on com1, he is assigned the ip address
192.168.3.151 and if another user dials in on com2, they are assigned
ip address 192.168.3.153 (be advised that this requires a 2nd NIC, and
proper setup of
gateways, etc for use with ipchains/iptables).
I have not tried this dual modem monster as com1 on my production box is broken, but it should work w/o any problems.
Logins that are idle for long period's of time:
In some cases, where you have a limited number of modems, you may wish
to log users off who are idle for a specified period of time (say an
hour or more). However, in trying to use the idle command in the /etc/ppp/options file, I have not been able to get it to work on a consistent basis. I recommend instead the use of IDLED instead of idle in PPP options, as it runs and can disconnect any logged in user, not just dial in connections.