Chapter 22
Configuring Dial-in networking
|
|
|
| |
|  |
| In this chapter: |
| |
| | |
 |
Connecting modems to the system
|
|
Configuring mgetty
|
|
The authentification process
|
|
Uncovering the PPP daemon's most important options
|
|
Configuring dial-in for selected users
|
|
Arranging dial-in access by using the system user database for authentification
|
|
| |
|
|
| |
A Linux machine not only provides TCP/IP services in a LAN set up or
on the Internet; you can also set it up as a dial-in-server for
clients who connect to the server over a modem connection. This
feature can also be used to provide remote access for maintenance on
machines not connected to the Internet. Imagine that you install a
Linux machine at a client's location and that you would like the
ability to monitor or change certain settings, or that you want to
provide access to your local network for employees or customers. These
possibilities increase productivity and ease access to critical
information.
This service allows a wide range of scalability. You can have just one
modem hooked up to your machine, or entire modem-racks connected to the
Linux box. The configuration is pretty much the same, no matter how
many dial-in lines you are going to support.
There are two aspects of dial-in configuration. First, we have to make the
modems known to the machine and ensure that incoming calls are
recognized. Finally, we have to specify parameters for the PPP
(Point-to-Point-Protocol) sessions, which connect the client machines
to your server.
|
| 22.1 | Hooking up modems |
| |
There are two steps in making the machine aware of the modem. One is
involves making the physical connection, and the other is starting
getty to enable dial-in on this modem. A
getty ("get tty") is an application which "listens"
in on the modem, waiting for a connection. As soon as it recognizes a
connection attempt, it asks for a login name, then gives control to
the login program to log the user onto the system. This
is the simplest instance of dial-in networking. We'll learn more about
more complex operations later on.
It should be fairly obvious that the modem connected to your machine
is set to enable dial-in.
|
| 22.1.1 | Which modem to use |
| |
Speed and brands aside, there are two kinds of modems -- internal and
external. Internal modems are the most popular (at least in the US),
while external modems have certain features that make them more
suitable dial-in access. External modems usually have a set of LEDs
indicating the modem's staus. This makes it easy to see if the modem
is online and if traffic is going through the modem. This is handy if
you want to debug your setup. Internal modems don't provide you with
this kind of information, which makes it harder to see if the problem
is on the software side or on the hardware side. Another point is that
external modems connect to any serial port, what makes it simple to
connect the modem to the machine. Internal modems are often
Plug-And-Play and require a special setup before they work, which can
be a hassle. Even worse, there are so called 'Win-Modems' which
require special drivers that are not available under Linux, so there
is no possibility to operate these modems using Linux .
|
 |
From what we've just discussed, this tip will be fairly
obvious: if you have to buy a new modem, I strongly recommend getting
an external one, as these have a reputation for offereing a flawless
set up and are easier to use than their internal counterparts. This
doesn't mean that internal modems can't be used at all, but that
experience shows that they are much more likely to be the source of
problems, rather than external ones.
|
| |
|
| 22.1.2 | Testing the modem |
| |
Once you have made the physical connection, you should test that you
can access the modem. An easy way to do this is to use a terminal
emulation and try to access the modem. The program minicom is a
friendly serial communication program and can be used for this
purpose. Start minicom, then go to the setup screen and enter
the right device for your modem. Then try to send AT-commands to
it. You should see what you type and get response codes from the
modem. If not, something is wrong. It maybe that you chose the wrong
device, or that the modem hasn't been detected by the system at all.
Check all modem related settings and cabling and try again.
|
| 22.1.3 | Enabling general dial-in |
| |
As said earlier, you'll need to start a getty process on the
modem device to enable dial-in connections. There are several
getty implementations that come with SuSE Linux that we can choose from:
| | |
|
mingetty - minimal getty for consoles
|
|
agetty - alternative Linux getty
|
|
mgetty - smart modem getty
|
|
| |
The brief descriptions given should make it clear which one we'll
choose for our purposes: Mgetty The other two gettys are
much more limited than mgetty. The first,
mingetty is only useful for console
logins. Agetty would work well if we only wanted shell
logins, but since our primary objective is to act as a dial-in server
for IP connections, we'll ignore it and use mgetty.
Mgetty fairly easy to enable. All you need to do is to
make an entry in /etc/inittab, that instructs
init to start mgetty for each modem line. In
a real-world situation, a line would look like this:
| | | # modem getty.
m0:23:respawn:/usr/sbin/mgetty -s 38400 ttyS1
|
| |
We've discussed this file in chapter 6. The four fields
are divided by colons (:). Let's review their meanings:
| | |
|
m0
Indicates the identifier for the process. If you want to start more than one
instance of mgetty, choose a seperate identifier for each
line, i.e. m1, m2, m3 and so on.
|
|
23
Activates the process in runlevels two and three.
|
|
respawn
Restarts the process whenever it dies. This assures that once the
connection is terminated, a new mgetty is started.
|
|
/usr/sbin/mgetty -s 38400 ttyS1
The application to start with all it's commandlien options. In this
case mgetty set to listen on /dev/ttyS1 and expecting
connections at 38000Bps. More on the mgetty options later.
|
|
| |
|
 |
After you have added one or more of these lines
to /etc/inittab, you should have init reread it, then
start the process(es). This is easily done by sending the signal
SIGHUP to the init process:
| | | # killall -HUP init
|
| |
Init rereads the inittab and starts all processes that are not
yet running, such as mgetty on the modem.
|
| |
|
|
You can check if mgetty is running by looking into the
process table. Run ps ax and grep for mgetty in the
output. You get something like this:
| | | # ps ax | grep mgetty
2579 ? S 0:00 /usr/sbin/mgetty -s 38400 ttyS1
|
| |
|
| |
Now you are able to dial into your machine, and get a login prompt
once you are connected. If you have problems at this point, you can
review the mgetty's lockfile to see what's going on in
the modem line. You'll find the log file in /var/log. Its
name depends on the device you set mgetty to listen
to. The name is mgetty.device.
In there, you'll find the communication between mgetty and your
modem. Here is an example of the modem initialization and a
successful login attempt:
| | | 03/03 22:40:15 check for lockfiles
03/03 22:40:15 locking the line
03/03 22:40:16 lowering DTR to reset Modem
03/03 22:40:16 send: \d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
03/03 22:40:20 waiting for "OK" ** found **
03/03 22:40:20 send: ATS0=0Q0&D3&H3&N0&K4[0d]
03/03 22:40:20 waiting for "OK" ** found **
03/03 22:40:20 send: AT+FCLASS=0[0d]
03/03 22:40:20 waiting for "OK" ** found **
03/03 22:40:20 send: AT+FAA=1;+FBOR=0;+FCR=1[0d]
03/03 22:40:20 waiting for "OK" ** found **
03/03 22:40:20 send: AT+FLID="49 89 3243328"[0d]
03/03 22:40:20 waiting for "OK" ** found **
03/03 22:40:20 send: AT+FDCC=1,5,0,2,0,0,0[0d]
03/03 22:40:20 waiting for "OK" ** found **
03/03 22:40:20 fax_command: send 'AT+FLPL=1'
03/03 22:40:20 fax_wait_for(OK)** found **
03/03 22:40:21 waiting...
03/03 22:41:28 waiting for "RING" ** found **
03/03 22:41:28 send: ATA[0d]
03/03 22:41:28 waiting for "CONNECT" ** found **
03/03 22:41:42 send:
03/03 22:41:42 waiting for "" ** found **
03/03 22:41:43 ##### data dev=ttyS1, pid=6470, caller=none,
conn='38400/ZyX 16800/V42b', name='',
cmd='/bin/login', user='bb'
|
| |
A word about device names before we continue with more
mgetty options and the actual PPP setup. Usually, you
have more than one device file for each of you serial ports. The first
serial port i.e. (COM1 in the Windows world) can be
accessed by using the device /dev/cua0 or
/dev/ttyS0. You even may have a link to one of those
files called /dev/modem. Traditionally, the separation in
cuas and ttys was made to have outgoing
(cua) and incoming (tty) devices. The Linux kernel handles both device
type equally, so there is no longer a reason to use one device rather
than the other. One important point is that you should always use the
same device name, no matter what you do. I recommend using the
/dev/ttyS* devices. The reason for this is that device
locking is based on the device file name. If any application uses a
serial device, it creates the file
/var/lock/LCK..devicename.
|
|
This works fine as long as everybody uses the same name
for this device. It can lead to trouble if, for example,
minicom uses /dev/modem and mgetty uses
/dev/ttyS1. In this instance /dev/modem is a link
to /dev/ttyS1. So please make sure that there is consistency in
device name to avoid this problem.
|
| |
|
| 22.2 | Mgetty configuration |
| |
Our review on enabling mgetty is fine for most situations. If
you find that these are limiting, read on for other ways to fine tune
its configuration.
There are four configuration files for mgetty in
/etc/mgetty+sendfax:
| | |
|
dialin.config
|
|
login.config
|
|
mgetty.config
|
|
voice.conf
|
|
| |
Of interest to us is mgetty.config and
login.config. The file dialin.config
controls caller ID based services, and voice.config is
used for setting up voice mail boxes based on mgetty. We
don't need either one to setup dial-in. To learn more about these
features, you can find the complete documentation for
mgetty at its homepage:
http://www.leo.org/~doering/mgetty.
|
| 22.2.1 | mgetty.config |
| |
Usually mgetty works quite well with the compiled-in
defaults (it has been the only way to configure it for a long time),
but this way is quite inflexible, especially if you use different
modem types. The built-in defaults can be modified by command line
options. Even this is not a perfect solution since it makes
/etc/inittab entries very long and difficult to read.
That's why mgetty was extended to use the configuration
file /etc/mgetty+sendfax/mgetty.config, which makes
dynamic setup far easier. Its format is very simple. Each line
contains one keyword, and possibly arguments for it, separated by
white space. Empty lines, and comment lines (those lines starting with
#) are allowed and ignored.
|
|
If your modem works fine after setting up mgetty as
described earlier, there is no real reason to change the settings. If,
however, something is not as it should be, read on and for tips on revising
the settings to get a perfect setup.
|
| |
The config file is grouped into port-specific sections, separated by
port TTY-NAME lines. Everything before
the first port line specifies global defaults, and
everything between the two port statements specifies
configuration items valid only for exactly this device. Let's look at
an example:
| | | # global defaults:
# fax station id is always the same
fax-id ++1 510 835 7875
# per port settings
port tty1a
# This modem can't fax
modem-type data
port tty2a
# more verbose logging for this modem
debug 9
|
| |
The data part of each line, following the keyword, can be a string (in
most cases), a chat sequence (a series of strings, separated by white
space, that specify the "modem talk" to do. It starts with an
expect string, then send, another
expect string, and so on), an integer (interpreted as
decimal, octal or hexadecimal, depending on the leading character
1-9/0/0x ), or boolean (y(es) or
t(rue) vs. n(o) or
f(alse)). If no argument is specified, this will
be considered value not set (if allowed) or
error (if a value is mandatory), except for boolean
values. In that case, it's interpreted as true.
Many of those configuration items can be overriden from the command
line. Command line options take precedence over configuration file
settings (and those take precedence over built-in
defaults). The configuration items useful for our focus are (command
line options, if available, given in brackets):
| | |
|
speed [-s] PORT SPEED
Specifis, as an integer value, the port speed to use. Default is
19200bps. If the given speed is not valid, mgetty
complains loudly and exits.
|
|
blocking YES/NO [-b]
Tells mgetty to open the device in blocking mode, that is, the
open() system call won't succeed until [a/the] carrier detect is set.
This is set if mgetty is called as getty. Default is no.
|
|
toggle-dtr YES/NO
Tells mgetty whether it should lower the DTR line upon startup to
reset modem. Default is yes, but a few modems have "allergic" reactions to
that and crash.
|
|
toggle-dtr-waittime MSECS
Specifies the time to hold the DTR line low. Default is 500
milliseconds.
|
|
data-only YES/NO [-D]
Tells mgetty to forget about faxing and only use the data part of
the modem. Default is false. You need this if your modem can't
distinguish between incoming fax and data calls.
|
|
modem-type [-C] MTYPE
Specifies the kind of modem connected to the port. Valid options are:
| | |
|
auto
Mgetty will detect the modem type itself (which occasionally may
not be desirable, or it may fail to recognize old modem equipment).
Mgetty will use the ATI command to find out the modem type, and
select the proper fax class accordingly. If that fails (unknown modem
type), mgetty will try class 2.0 and then class 2.
|
|
c2.0
Modem is a CLASS 2.0 fax modem. Works better than class 2, if
both are available, because it has better standardization. Known to
work with USR, ZyXEL 1496 and 2864 series, and ELSA modems.
|
|
cls2
Modem is a CLASS 2 fax modem, mgetty will not try class 2.0.
|
|
data
Do not try fax initialization, same as if '-D' given.
|
|
| |
|
|
init-chat [-m] EXPECT SEND EXPECT SEND ...
Tells mgetty the chat sequence to use for initializing the
modem.
|
 |
Warning: the sequence starts with expect,
which will in most cases be "" (which indicates nothing). This
ordering was chosen because UUCP does it this way, and Gert Doering
(the main author of mgetty) wanted to avoid confusion here.
|
| |
Example:
| | | init-chat "" ATQ0E1V1H0 OK ATL0M0S0=0 OK AT&K3 OK
|
| |
|
|
This is a parameter you may have to change to adopt mgetty
for your modem. Refer to your modem's manual to see how to
initialize it properly.
|
| |
|
|
force-init-chat EXPECT SEND EXPECT SEND ...
In some cases, the modem can get stuck in a mode where it won't react
to a simple AT command. Usually this happens because the modem is
set to ignore a DTR drop and still has a data connection to the other
side. If you use a voice modem, it could be stuck in voice mode.
In these situations, the normal init-chat will time out, because
the modem won't send the proper responses back.
To get the modem back into a "sane" state, you can use the
force-init-chat chat sequence. The default setup will send the
DLE ETX characters, to revive voice modems, then the
(pause)+++(pause)ATH0 sequence to pull the modem
from data mode to command mode.
You could append this sequence to init-chat (it wouldn't do any harm),
but the pauses around the +++ sequence makes this
undesirably slow.
|
|
post-init-chat EXPECT SEND EXPECT SEND ...
Some modems forget parts of their settings when going from data to fax
mode and back again during modem initialization. For example, some USR
models forget the settings of Caller ID delivery
(AT#CID=1), and some ELSA modems forget their current DTE port
speed when going from voice to data mode, thus leading to RING
messages being delivered with the wrong baud rate.
For those modems, you can use this command to set up
AT commands that are executed after all other fax and voice
initialization has been completed.
|
|
Be careful when revising these files! If you
send an ATZ (modem reset) or similar instruction here, all your
settings will be lost.
|
| |
|
|
modem-check-time' SECONDS
Some modems have the nasty tendency to silently crash . With this
option, you tell mgetty to check every SECONDS seconds
with a simple AT...OK sequence that will show whether the modem still reacts. If
not, mgetty will restart itself and do a full modem reset.
|
|
rings [-n] NNN
Sets the number of RING messages to wait for before mgetty picks
up the phone. Default is 1.
|
|
Warning: if your modem auto-answers, for
whatever reason, set this to something other than the value set with
ATS0=mmm, otherwise the modem's auto-answer and mgetty's
manual answer will collide (most modems hang up if a command is
received during auto-answer).
|
| |
|
|
answer-chat CHAT SEQUENCE
This is the command sequence that is used to answer a phone call.
Usually you can leave it at the default "" ATA CONNECT
\c, but for some modems you need ATS0=1 in place of
ATA, where ATA is not allowed.
|
|
answer-chat-timeout SECS
During the answer-chat, each expect string must be
seen in the time specified here. Default is 80 seconds. This time
should be at least 5 seconds longer than the time set with the
ATS7=... modem setup command.
|
|
ignore-carrier
If your modem does not assert the DCD (carrier detect) line, or the
serial port or cable or serial driver is broken, it is possible that
mgetty or login will block after a successful
CONNECT (that means that everything seems to work, yet suddenly
nothing is sent to the port).
|
|
To work around this, you can switch off the carrier
detection: set ignore-carrier true. Default is false.
|
| |
|
|
Warning: If you use this, your system won't be able to detect
when a caller simply hangs up instead of cleanly logging out. This may
result in hanging modems, etc.
|
| |
|
|
debug [-x] DEBUG LEVEL
This sets the amount of logging mgetty will do. A good value is
4, more details are seen when the setting is '5', but a setting of '9'
is really noisy. Try it! The log data is written to the file
/var/log/mgetty.device.
|
|
| |
Remember, this is only a selection of the possible
parameters that can be specified in this file.
If you are interested in using mgetty for faxing or voice
mail, you'll find the complete list of options on
http://www.leo.org/~doering/mgetty.
|
| 22.2.2 | login.config |
| |
This file is a sample login dispatcher. You can launch certain
programs based on the caller's login name. Default is to start
/bin/login, which will start a standard shell session. However, for UUCP
dialins or PPP connections, this may not be desirable; you may want to
start uucico to handle UUCP, or pppd to establish the
PPP connection.
Since we're covering PPP, let's concentrate on this issue. There are
three ways to power up PPP once the modem connection is
established. You can have the user log in via /bin/login and
start pppd as his login-shell. This is not eht most elegant
method, and is not recommended. The second option is to start
pppd by adding the username in this file:
| | | startppp ppp ppp /usr/sbin/pppd auth
|
| |
The first entry is the login name startppp. The second entry
gives the user ID (must be listed in /etc/passwd), the third is
the utmp entry to be made (what you see when you run the command
who) and the last entry is the application to be started. But
what does this line mean? It says, whenever somebody logs on with the
name startppp, the program /usr/sbin/pppd auth will be
started, and the user will be listed as ppp.
This method is better than the first one, but is still not optimal. We want
to bypass the login: prompt at all, and use PPP's abilities to
authenticate the caller (in the LCP chat) and take over control as
soon as possible.
This can be achieved with mgetty's special ability to recognize a PPP
connection by parsing the first few characters sent on the line. This
is configured by using the special name /AutoPPP/ as login
name:
| | | /AutoPPP/ - a_ppp /usr/sbin/pppd auth
|
| |
|
|
This line tells mgetty to start /usr/sbin/pppd auth as soon as
it recognizes a LCP configure request on the modem line. With this
setting, you'll be able to connect (for instance) Windows machines with their
native dial-up networking setup to your machine, without needing
login scripts or similar scripts on the client side.
|
| |
|
| 22.3 | Configuring PPP dial-in |
| |
Now we are at the point where the PPP daemon pppd gets started,
and of course you're eager to know how to configure it. But first a
brief intro on what PPP is:
The Point-to-Point Protocol (PPP) provides a method for transmitting
datagrams over serial point-to-point links. PPP is composed of three
parts: a method for encapsulating datagrams over serial links, an
extensible Link Control Protocol (LCP), and a family of Network
Control Protocols (NCP) for establishing and configuring different
network-layer protocols.
The encapsulation scheme is provided by a driver code in the kernel.
The PPP daemon (pppd) provides the basic LCP, authentication
support, a NCP for establishing and configuring the Internet
Protocol (IP) (called the IP Control Protocol, IPCP), and the PIX protocol (IPXCP).
|
| 22.3.1 | Authentification |
| |
The most important thing we have to take care of is the proper
authentification of the calling machine. Authentication is the process
whereby one machine convinces the other of its identity. This
involves the first machine sending its name to the other, together
with some kind of secret information which could only come from the
genuine authorized user of that name. In such an exchange, we will
call the first machine the client and the other the
server. The client has a name by which it identifies itself
to the server, and the server also has a name by which it identifies
itself to the client. Generally the genuine client shares some secret
(or password) with the server, and authenticates itself by proving
that it knows that secret. Very often, the names used for
authentication correspond to the Internet hostnames of the peers, but
this is not essential.
|
|
As of this writing, pppd supports two authentication protocols: the
Password Authentication Protocol (PAP) and the Challenge Handshake
Authentication Protocol (CHAP). PAP involves the client sending its
name and a cleartext password to the server to authenticate itself.
In contrast, the server initiates the CHAP authentication exchange by
sending a challenge to the client (the challenge packet includes the
server's name). The client must respond with a response which includes
its name plus a hash value derived from the shared secret and the
challenge, in order to prove that it knows the secret.
|
| |
The PPP protocol, being symmetrical, allows both peers to require the
other to authenticate itself. In that case, two separate and
independent authentication exchanges will occur. The two exchanges
could use different authentication protocols, and in principle,
different names could be used in the two exchanges.
The default behavior of pppd is to agree to authenticate if
requested, and to not require authentication from the peer. However,
pppd will not agree to authenticate itself with a particular
protocol if it has no secrets which could be used to do so.
Pppd stores secrets for use in authentication in secrets
files (/etc/ppp/pap-secrets for PAP,
/etc/ppp/chap-secrets for CHAP). Both secrets files have the
same format. The secrets files can contain secrets for pppd to
use in authenticating itself to other systems, as well as secrets for
pppd to use when authenticating other systems to itself.
Each line in a secrets file contains one secret. A given secret is
specific to a particular combination of client and server - it can
only be used by that client to authenticate itself to that server.
Thus, each line in a secrets file has at least 3 fields: the name of
the client, the name of the server, and the secret. These fields may
be followed by a list of the IP addresses that the specified client
may use when connecting to the specified server.
A secrets file is parsed into words just like an options file, so the
client name, server name, and secrets fields must each be one word,
with any embedded spaces or other special characters quoted or
escaped. Any subsequent words on the same line are taken to be a list
of acceptable IP addresses for that client.
|
|
If there are only 3 words on the line, or if the first word is
"-", then all IP addresses are disallowed.
To allow any address, use "*". A word starting with
"!" indicates that the specified address is not
acceptable. An address may be followed by "/" and a number
n, to indicate a whole subnet, i.e. all addresses
which have the same value in the most significant n
bits. Note that case is significant in the client and server names and
in the secret.
|
| |
If the secret starts with an at-sign (@), what follows is
assumed to be the name of a file from which to read the secret. A
* as the client or server name matches any name. When
selecting a secret, pppd takes the best match, meaning
the match with the fewest wildcards.
Thus a secrets file contains both secrets for use in authenticating
other hosts, plus secrets which we use for authenticating ourselves to
others. When pppd is authenticating the peer (checking
the peer's identity), it chooses a secret with the peer's name in the
first field and the name of the local system in the second field. The
name of the local system defaults to the hostname, with the domain
name appended if the domain option is used. This default
can be overridden with the name option, except when the
usehostname option is used.
When pppd is choosing a secret to use in authenticating
itself to the peer, it first determines what name it is going to use
to identify itself to the peer. This name can be specified by the user
with the user option. If this option is not used, the
name defaults to the name of the local system, determined as described
in the previous paragraph. Then pppd looks for a secret
with this name in the first field and the peer's name in the second
field. Pppd will know the name of the peer if CHAP
authentication is being used, because the peer will have sent it in
the challenge packet. However, if PAP is being used, pppd
will have to determine the peer's name from the options specified by
the user. The user can specify the peer's name directly with the
remotename option. Otherwise, if the remote IP address
was specified by a name (rather than in numeric form), that name will
be used as the peer's name. Failing that, pppd will use
the null string as the peer's name.
When authenticating the peer with PAP, the supplied password is first
compared with the secret from the secrets file. If the password
doesn't match the secret, the password is encrypted using
crypt() and checked against the secret again. Thus
secrets for authenticating the peer can be stored in encrypted form if
desired. If the papcrypt option is given, the first
(unencrypted) comparison is omitted, for better security.
Furthermore, if the login option was specified, the
username and password are also checked against the system password
database. Thus, the system administrator can set up the pap-secrets
file to allow PPP access only to certain users, and to restrict the
set of IP addresses that each user can use. Typically, when using the
login option, the secret in
/etc/ppp/pap-secrets would be "", which will match any
password supplied by the peer. This avoids the need to have the same
secret in two places.
Authentication must be satisfactorily completed before IPCP (or any
other Network Control Protocol) can be started. If the peer is
required to authenticate itself, and fails to do so, pppd
will terminate the link by closing LCP. If IPCP negotiates an
unacceptable IP address for the remote host, IPCP will be closed. IP
packets can only be sent or received when IPCP is open.
In some cases it is desirable to allow some hosts which can't
authenticate themselves to connect and use one of a restricted set of
IP addresses, even when the local host generally requires
authentication. If the peer refuses to authenticate itself when
requested, pppd takes that as equivalent to
authenticating with PAP using the empty string for the username and
password. Thus, by adding a line to the pap-secrets file which
specifies the empty string for the client and password, it is possible
to allow restricted access to hosts which refuse to authenticate
themselves.
|
| 22.3.2 | Options for pppd |
| |
We talked about authentification, what else do we need to know? The
PPP daemon pppd has several places where it looks for
parameters and options. The options are used to tell pppd
what to do which each connection.
|
|
Options can be taken from files as well as the command line.
Pppd reads options from the files
/etc/ppp/options, ~/.ppprc and
/etc/ppp/options.ttyname (in that order)
before processing the options on the command line. (In fact, the
command-line options are scanned to find the terminal name before the
options.ttyname file is read.) In forming the
name of the options.ttyname file, the initial
/dev/ is removed from the terminal name, and any
remaining slashes (/) are replaced with dots.
|
| |
An options file is parsed into a series of words, delimited by white
space. White space can be included in a word by enclosing the word in
double-quotes ("). A backslash
quotes the following character. A hash (#) starts a
comment, which continues until the end of the line.
If you look into /etc/ppp/options on a standard SuSE
installation, you will see that they preset quite a few parameters for
you. We will go over these options briefly, then see an
example with a working set of options for a dial-in server.
| | |
|
name name
Sets the name of the local system for authentication purposes to
name. This is a privileged option. With this option,
pppd will use lines in the secrets files which have
name as the second field when looking for a secret to use in
authenticating the peer. In addition, unless overridden with the
user option, name will be used as the name to send to
the peer when authenticating the local system to the peer.
|
|
Note that pppd does not append the domain name to name.
|
| |
|
|
usehostname
Enforces the use of the hostname (with domain name appended, if given)
as the name of the local system for authentication purposes (overrides
the name option).
|
|
noipdefault
Disables the default behavior when no local IP address is specified,
which is to determine (if possible) the local IP address from the
hostname. With this option, the peer will have to supply the local IP
address during IPCP negotiation (unless it specified this explicitly on the
command line or in an options file).
|
|
debug
Enables connection debugging facilities. If this option is given,
pppd will log the contents of all control packets sent or received in
a readable form. The packets are logged through syslog with a facility
daemon and level debug. This information can be found
in the file /var/log/messages.
|
|
Be careful with
this option -- it logs passwords in clear text, so everyone who can
read the logfile has access to this information, and can use it to
log into your system.
|
| |
|
|
kdebug n
Enables debugging code in the kernel-level PPP driver. The argument n
is a number which is the sum of the following values:
| | |
|
1 to enable general debug messages,
|
|
2 to request that the contents of received packets be printed,
|
|
and 4 to request that the contents of transmitted packets be printed.
|
|
| |
The debug output is written to /var/log/messages.
|
|
Note that writing extensive debug information will slow down
your machine and eventually the PPP connection. If you set
kdebug to 7 the contents of every single IP packet will
be written into the log file. This can be a tremendous amount of
information, so be careful when choosing the debug level, and don't
forget to turn debugging off once your setup is working.
|
| |
|
|
ipcp-accept-local
With this option, pppd will accept the peer's idea of our local IP
address, even if the local IP address was specified in an option.
|
|
ipcp-accept-remote
With this option, pppd will accept the peer's idea of its (remote) IP
address, even if the remote IP address was specified.
|
|
ms-dns IP-address
If pppd is acting as a server for Microsoft Windows clients,
this option allows pppd to supply one or two DNS (Domain Name Server)
addresses to the clients. The first instance of this option specifies
the primary DNS address; the second instance (if given) specifies the
secondary DNS address.
|
|
ms-wins IP-address
If pppd is acting as a server for Microsoft Windows or Samba
clients, this option allows pppd to supply one or two WINS
(Windows Internet Name Services) server addresses to the clients.
|
|
This option is listed as wins-addr in the SuSE
configuration. This is incorrect. The appropriate option is ms-wins.
|
| |
The first instance of this option specifies the primary WINS address;
the second instance (if given) specifies the secondary WINS address.
|
|
defaultroute
Add a default route to the system routing tables, using the peer as
the gateway, when IPCP negotiation is successfully completed. This
entry is removed when the PPP connection is broken. This option is
privileged if the nodefaultroute option has been specified.
|
|
nodefaultroute
Disables the defaultroute option. The system administrator who
wishes to prevent users from creating default routes with pppd can do
so by placing this option in the /etc/ppp/options file.
|
|
This option is important if your machine acts as an dial-in
server. You don't want to set your default route to the client dialing in.
|
| |
|
|
disconnect script
Runs the executable or shell command specified by script, after
pppd has terminated the link. This script could, for example, issue
commands to the modem to cause it to hang up if hardware modem control
signals were not available. The disconnect script is not run if the
modem has already hung up. This option is privileged if the
noauth option is used.
|
|
noauth
Does not require the peer to authenticate itself. This option is
privileged if the auth option is specified in
/etc/ppp/options.
|
|
require-pap
Requires the peer to authenticate itself using PAP (Password
Authentication Protocol) authentication.
|
|
refuse-chap
With this option, pppd will not agree to authenticate itself to the
peer using CHAP.
|
|
crtscts
Uses hardware flow control (i.e. RTS/CTS) to control the flow of data
on the serial port. If neither the crtscts nor the
nocrtscts option is given, the hardware flow control setting
for the serial port is left unchanged.
|
|
lock
Specifies that pppd should create a UUCP-style lock file for the
serial device to ensure exclusive access to the device.
|
|
modem
Uses the modem control lines. This option is the default. With this
option, pppd will wait for the CD (Carrier Detect) signal from the
modem to be asserted when opening the serial device (unless a connect
script is specified), and it will drop the DTR (Data Terminal Ready)
signal briefly when the connection is terminated and before executing
the connect script.
|
|
asyncmap char
Set the async character map to char. This map describes
which control characters cannot be successfully received over the
serial line. Pppd will ask the peer to send these characters
as a 2-byte escape sequence. The argument is a 32 bit hex number with
each bit representing a character to escape. Bit 0 (00000001)
represents the character 0x00; bit 31 (80000000) represents the
character 0x1f. If multiple asyncmap options are given, the
values are ORed together. If no asyncmap option is given, no
async character map will be negotiated for the receive direction; the
peer should then escape all control characters. To escape transmitted
characters, use the escape option.
|
|
escape list
Specifies that certain characters should be escaped on transmission
(regardless of whether the peer requests them to be escaped with its
async control character map). The characters to be escaped are
specified as a list of hex numbers separated by commas. Note that
almost any character can be specified for the escape option, unlike
the asyncmap option which only allows control characters to be
specified. The characters which may not be escaped are those with hex
values 0x20 - 0x3f or 0x5e.
|
|
mru n
Sets the MRU (Maximum Receive Unit) value to n. Pppd
will ask the peer to send packets of no more than n bytes. The
minimum MRU value is 128. The default MRU value is 1500. A value of
296 is recommended for slow links (40 bytes for TCP/IP header + 256
bytes of data).
|
|
mtu n
Sets the MTU (Maximum Transmit Unit) value to n. Unless the
peer requests a smaller value via MRU negotiation, pppd will
request that the kernel networking code send data packets of no more
than n bytes through the PPP network interface.
|
|
netmask netmask
Sets the interface netmask to netmask, a 32 bit netmask in
"decimal dot" notation (e.g. 255.255.255.0). If this option is given,
the value specified is ORed with the default netmask. The default
netmask is chosen based on the negotiated remote IP address; it is the
appropriate network mask for the class of the remote IP address, ORed
with the netmasks for any non point-to-point network interfaces in the
system which are on the same network.
|
|
nodetach
Instructs not to detach from the controlling terminal. If this option is omitted, and
a serial device other than the terminal on the standard input is
specified, pppd will fork to become a background process.
|
|
remotename name
Sets the assumed name of the remote system for authentication purposes to name.
|
|
noproxyarp
Disables the proxyarp option. System administrators who wish to
prevent users from creating proxy ARP entries with pppd can do so by
placing this option in the /etc/ppp/options file.
|
|
login
Uses the system password database for authenticating the peer using
PAP, and records the user in the system wtmp file. Note that the
peer must have an entry in the /etc/ppp/pap-secrets file as well as
the system password database to be allowed access (we'll see an example for this later on).
|
|
lcp-echo-interval n
If this option is given, pppd will send an LCP echo-request frame to
the peer every n seconds. Normally the peer should respond to the
echo-request by sending an echo-reply. This option can be used with
the lcp-echo-failure option to detect that the peer is no longer
connected.
|
|
lcp-echo-failure n
If this option is given, pppd will presume the peer is dead
if n LCP echo-requests are sent without receiving a valid LCP
echo-reply. If this happens, pppd will terminate the connection. Use
of this option requires a non-zero value for the lcp-echo-interval
parameter. This option can be used to allow pppd to terminate after
the physical connection has been broken (e.g., the modem has hung
up) in situations where no hardware modem control lines are available.
|
|
idle n
Specifies that pppd should disconnect if the link is idle for n
seconds. The link is idle when no data packets (i.e. IP packets) are
being sent or received.
|
|
Note: it is not advisable to use this option
with the persist option without the demand option. If the
active-filter option is given, data packets which are rejected by the
specified activity filter also count as the link being idle.
|
| |
|
|
noipx
Disables the IPXCP and IPX protocols. This option should only be
required if the peer is buggy and gets confused by requests from pppd
for IPXCP negotiation.
|
|
novj
Disables Van Jacobson style TCP/IP header compression in both the
transmit and the receive direction.
|
|
novjccomp
Disables the connection-ID compression option in Van Jacobson style
TCP/IP header compression. With this option, pppd will not omit the
connection-ID byte from Van Jacobson compressed TCP/IP headers, nor
ask the peer to do so.
|
|
| |
These are only the options in the default SuSE
/etc/ppp/options file. Pppd allows for more
options, but these are the most important, and most frequently used.
For a complete List of options, look into the man page
pppd(8).
|
| 22.3.3 | Practical Examples |
| |
OK, we've covered quite a lot of theory-now it's time to implement
PPPs in some real world situations. Here are two examples. In our
first example, we assume that we have one modem hooked up at our
machine, and that we want to allow PPP dial-ups to this modem. This is
typical constellation if you have a machine at home and you want to
allow a friend to dial-in to exchange documents or play a death-match
Quake game without experiencing the delay of an Internet
connection. Furthermore, let's say you use the username
ppp01, with the password GeH31m for the
dial-in account and that the modem is connected to
/dev/ttyS0.
The second example will show us how to use the existing logins in
/etc/passwd for dial-up accounts. But first we'll look at the
simpler one that contains only one PPP dial-in account.
|
| | A Single Dial-In Account |
| |
The configuration files we have to take care of are:
| | |
|
/etc/mgetty+sendfax/login.config -- Mgetty has to start pppd
|
|
/etc/ppp/options -- We have to tell pppd what to do in general
|
|
/etc/ppp/options.ttyS0 -- Special pppd options for this device
|
|
/etc/ppp/pap-secrets -- Specify the username an password for the dial-in account
|
|
| |
|
| | /etc/mgetty+sendfax/login.config |
| |
All we need to do here is to make sure that the line for auto
recognition of a PPP connect is active. Open the file and look for the
following lines:
| | | #
# Automatic PPP startup on receipt of LCP configure request (AutoPPP).
#
/AutoPPP/ - a_ppp /usr/sbin/pppd auth
|
| |
|
|
Note that the first string /AutoPPP/ is case
sensitive. Every other combination of upper and lower case won't
work.
|
| |
We already discussed the other entries. a_ppp is the name
for the utmp entry, and everything following that is the
command to execute. You see that we give the parameter
auth to pppd to enforce authentification.
|
| | /etc/ppp/options |
| |
We don't need any esoteric options to finalize PPP dial in. Everything
is pretty straight forward and with few modifications to the standard
options file provided by SuSE dial-in:
| | | #
# /etc/ppp/options
#
# If no local IP address is given, pppd will use the first IP address
# that belongs to the local hostname. If "noipdefault" is given, this
# is disabled and the peer will have to supply an IP address.
noipdefault
# enables this on a server that already has a permanent default route
nodefaultroute
# Increase debugging level (same as -d). The debug output is written
# to syslog LOG_LOCAL2.
debug
# Enables you to debug code in the kernel-level PPP driver. The argument n
# is a number which is the sum of the following values: 1 to enable
# general debug messages, 2 to request that the contents of received
# packets be printed, and 4 to request that the contents of transmitted
# packets be printed.
kdebug 0
# Requires that the peer authenticate itself before allowing network
# packets to be sent or received.
# Please do not disable this setting. It is expected to be standard in
# future releases of pppd. Use the call option (see man page) to disable
# authentication for specific peers.
noauth
# authentication can either be pap or chap. As most people only want to
# use pap, you can also disable chap:
require-pap
# Uses hardware flow control (i.e. RTS/CTS) to control the flow of data
# on the serial port.
crtscts
# Specifies that pppd should use a UUCP-style lock on the serial device
# to ensure exclusive access to the device.
lock
# Uses the modem control lines.
modem
# async character map -- 32-bit hex; each bit is a character
# that needs to be escaped for pppd to receive it. 0x00000001
# represents '\x01', and 0x80000000 represents '\x1f'.
# To allow pppd to work over a rlogin/telnet connection, you should escape
# XON (^Q), XOFF (^S) and ^]: (The peer should use "escape ff".)
#asyncmap 200a0000
asyncmap 0
# Prevents [asyncmap?] from forking to become a background process
# (otherwise pppd will do so if a serial device is specified).
nodetach
# Disables the IPXCP and IPX protocols.
noipx
# Disable VJ
novj
novjccomp
|
| |
The shown example is well documented, for more details on specific
options, look at the descriptions given in the last section.
|
| | /etc/ppp/options.ttyS0 |
| |
While the /etc/ppp/options file is used by all invocations of
pppd, this file is only used if pppd is attached to
/dev/ttyS0. Here you can specify parameters for
connections on this only device, or overwrite the global parameters
from /etc/ppp/options.
All we need do in this file is to specify the IP address the caller should
use:
| | | #
# /etc/ppp/options.ttyS0
#
192.168.0.196:192.168.0.55
|
| |
You see a pair of addresses separated by a colon (:). The first
address is the server's address, the second is the one the client
gets. You don't need to use IP-addresses, names are allowed too, but
then you have to make sure that these names are resolved properly.
The scheme of having separate option files for each device is handy
when we want to have more than one dial-in line available. For the
example shown, where there is only one modem, you could write the addresses in
/etc/ppp/options too. It won't make a difference, as there is
only one device. But imagine you have four lines, and simultaneous
dial-in's. With the separate option files, you can assign one
dedicated IP address to each line, by having them assigned in the tty
specific option files.
|
| | /etc/ppp/pap-secrets |
| |
We have talked about this file in the authentification section. It
holds the passwords (secrets) for PPP authentification. For inbound
connections we need to specify the clients name, our name, the clients
password (secret) and a IP address. An asterisk (*) can
be used as wildcard for hostname and IP address, which makes sense for
us, as we have always the same hostname and assign the IP address in
the options.ttyS0 file. With the given name and password,
the secrets file will look like this:
| | | #
# Secrets for authentication using PAP
#
# INBOUND CONNECTIONS
#client hostname <password> IP-address
ppp01 * GeH31m *
|
| |
The client's name is ppp01, and the password is GeH13m.
Now that we have everything together, the client machine should
be able to dial in. You can follow this process by observing the
dial-in process in /var/log/messages. With the settings given,
you should see something like this:
| | | Apr 29 18:16:29 Homer pppd[2843]: pppd 2.3.5 started by a_ppp, uid 0
Apr 29 18:16:29 Homer pppd[2843]: Using interface ppp0
Apr 29 18:16:29 Homer pppd[2843]: Connect: ppp0 <--> /dev/ttyS0
Apr 29 18:16:29 Homer pppd[2843]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
<auth pap> <magic 0x361984f> <pcomp> <accomp>]
Apr 29 18:16:29 Homer pppd[2843]: rcvd [LCP ConfAck id=0x1 <asyncmap0x0> <auth
pap>
<magic 0x361984f> <pcomp> <accomp>]
Apr 29 18:16:32 Homer pppd[2843]: rcvd [LCP ConfReq id=0x1 <mru 1500>
<magic 0xffffd002> <pcomp> <accomp>]
Apr 29 18:16:32 Homer pppd[2843]: sent [LCP ConfAck id=0x1 <mru 1500>
<magic 0xffffd002> <pcomp> <accomp>]
Apr 29 18:16:32 Homer pppd[2843]: rcvd [PAP AuthReq id=0x1
user="ppp01" password="GeH31m"]
Apr 29 18:16:32 Homer pppd[2843]: sent [PAP AuthAck id=0x1 "Login ok"]
Apr 29 18:16:32 Homer pppd[2843]: sent [IPCP ConfReq id=0x1 <addr
192.168.0.196>]
Apr 29 18:16:32 Homer pppd[2843]: rcvd [IPCP ConfReq id=0x1 <addr 0.0.0.0>
<compress VJ 0f 01>]
Apr 29 18:16:32 Homer pppd[2843]: sent [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Apr 29 18:16:32 Homer pppd[2843]: rcvd [IPCP ConfAck id=0x1 <addr
192.168.0.196>]
Apr 29 18:16:32 Homer pppd[2843]: rcvd [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
Apr 29 18:16:32 Homer pppd[2843]: sent [IPCP ConfNak id=0x2 <addr 192.168.0.55>]
Apr 29 18:16:32 Homer pppd[2843]: rcvd [IPCP ConfReq id=0x3 <addr 192.168.0.55>]
Apr 29 18:16:32 Homer pppd[2843]: sent [IPCP ConfAck id=0x3 <addr 192.168.0.55>]
Apr 29 18:16:32 Homer pppd[2843]: local IP address 192.168.0.196
Apr 29 18:16:32 Homer pppd[2843]: remote IP address 192.168.0.55
|
| |
This output shows you how pppd gets started and how the
LCP chat negotiates the connection parameters. After this, the secret
is exchanged to verify the authentification. Then the IPCP chat
negotiates the IP parameters, like header compression (off in this
case) and the IP addresses used for both machines. In general, this is
enough information to trace problems during the dial-up process. The
log entry without the debug option is far less
informative:
| | | Apr 29 18:24:24 Homer pppd[2853]: pppd 2.3.5 started by a_ppp, uid 0
Apr 29 18:24:24 Homer pppd[2853]: Using interface ppp0
Apr 29 18:24:24 Homer pppd[2853]: Connect: ppp0 <--> /dev/ttyS0
Apr 29 18:24:27 Homer pppd[2853]: local IP address 192.168.0.196
Apr 29 18:24:27 Homer pppd[2853]: remote IP address 192.168.0.55
|
| |
This only tells you which interface and which IP addresses are
used. This is OK once you are sure that your setup is correct
and the dial-in works fine.
|
|
To add more logins, all you have to do is to add their name and
password to /etc/ppp/pap-secrets. If you want to have more than
one dial-in line, create a options.device file in
/etc/ppp for each line and assign a different IP address to
each device. You see that it's pretty easy to set up an dial-in
server after all.
|
| |
|
| | Using the System User Database For Dial-In Accounts |
| |
If you want to run a dial-in server with more than a few
users allowed to dial in, and perhaps give email accounts and Web
pages to them, you probably want to add them to the system's user
database. This way they have an email account, and you can configure
Apache in such a way that sets up user's homepages for them automatically,
once they are in the user database. If you don't want to allow
interactive logins, assign /bin/false as a login shell and all
they can do is retrieve their email and ftp into their home directories to
maintain their Web space. The latter example is of course appropriate for ISPs.
So what is there to do on the PPP side to enable this kind of setup? The
answer is easy since not very much has to be done. Basically you have to
modify the mgetty configuration a little, then exclude certain
users from using this service in /etc/pap-secrets.
|
| 22.3.4 | /etc/mgetyy+sendfax/login.config |
| |
The line where you specify how pppd is to be started has
to be changed to the setting shown below. The login
options tells pppd to refer to the user database for user
authentification. The other two options enforce PAP as method of
authentification.
| | | #
# Use the system user database for dial-in authentification
#
/AutoPPP/ - a_ppp /usr/sbin/pppd login -chap +pap
|
| |
|
| 22.3.5 | /etc/ppp/pap-secrets |
| |
Here you have to take care of two things. First, enable login for
everyone by adding a wildcard line with an empty password, then
exclude system accounts from logging in.
|
|
Be careful here, as the defaults given in the pap-secrets file
provided by SuSE don't work. They are missing the asterisk in the
fourth column.
|
| |
A valid configuration is shown below. The first line enables the user
logins, and then this service is disabled for the root
user. You may add more accounts to this list if you want to exclude
more users from this service.
| | | # Every regular user can use PPP and has to use passwords from /etc/passwd
#
# client hostname <password> IP-address
* * "" *
# User IDs that cannot use PPP at all. Check your /etc/passwd and add any
# other accounts that should not be able to use pppd. Replace hostname
# with your local hostname.
root * "*" *
|
| |
|
|
| Summary: |
| |
PPP dial is a service fairly easy to set up. After making
sure that the modem works correctly, there are only a few files to edit
to get the dial-in service working.
User authentification is an important point, since you don't want to
have people dial in and use your resources or tamper with your system.
There are two ways to specify the users allowed to dial in. You can
either list them in a separate file, including their passwords, or
you can use the system's user database for authentification.
|
|
|
| |
