PPP and SLIPIf your connection to the Internet is through a modem, or you wish
to provide other people with dialup connections to the Internet using
FreeBSD, you have the option of using PPP or SLIP. Furthermore, two
varieties of PPP are provided: user (sometimes
referred to as iijppp) and kernel. The
procedures for configuring both types of PPP, and for setting up SLIP
are described in this chapter.Setting up User PPPUser PPP was introduced to FreeBSD in release 2.0.5 as an
addition to the existing kernel implementation of PPP. So, what is
different about this new PPP that warrants its addition? To quote
from the manual page:
This is a user process PPP software package. Normally, PPP
is implemented as a part of the kernel (e.g. as managed by pppd)
and it is thus somewhat hard to debug and/or modify its
behavior. However, in this implementation PPP is done as a user
process with the help of the tunnel device driver (tun).
In essence, this means that rather than running a PPP daemon,
the ppp program can be run as and when desired. No PPP interface
needs to be compiled into the kernel, as the program can use the
generic tunnel device to get data into and out of the kernel.From here on out, user ppp will be referred to simply as ppp
unless a distinction needs to be made between it and any other PPP
client/server software such as pppd. Unless otherwise stated, all
commands in this section should be executed as root.Before you startThis document assumes you are in roughly this position:You have an account with an Internet Service Provider (ISP)
which lets you use PPP. Further, you have a modem (or other
device) connected and configured correctly which allows you to
connect to your ISP.You are going to need the following information to
hand:Your ISPs phone number(s).Your login name and password. This can be either a
regular unix style login/password pair, or a PPP PAP or CHAP
login/password pair.The IP address of your ISP's gateway. The gateway is
the machine to which you will connect and will be set up as
your “default route”. If your
ISP hasn't given you this number, don't worry. We can make
one up and your ISP's PPP server will tell us when we
connect.This number is known from now on as
HISADDR.Your ISP's netmask setting. Again, if your ISP hasn't
given you this information, you can safely use a netmask of
255.255.255.0.The IP addresses of one or more nameservers. Normally,
you will be given two IP numbers. You
must have this information unless you run
your own nameserver.If your ISP allocates you a static IP address and
hostname then you will need this information too. If not,
you will need to know from what range of IP addresses your
allocated IP address will belong. If you haven't been given
this range, don't worry. You can configure ppp to accept any
IP number (as explained later).If you do not have any of the required information, contact
your ISP and make sure they provide it to you.Building a ppp ready kernelAs the description states, ppp uses the kernel tun
device. It is necessary to make sure that your kernel has support
for this device compiled in.To check this, go to your kernel compile directory
(/sys/i386/conf or
/sys/pc98/conf) and examine your kernel
configuration file. It needs to have the line
pseudo-device tun 1
in it somewhere. The stock GENERIC kernel
has this as standard, so if you have not installed a custom kernel
or you do not have a /sys directory, you do not have to change
anything.If your kernel configuration file does not have this line in
it, or you need to configure more than one tun device (for
example, if you are setting up a server and could have 16 dialup
ppp connections at any one time then you will need to use 16
instead of 1), then you should add the line, re-compile,
re-install and boot the new kernel. Please refer to the
section for more information on kernel
configuration.You can check how many tunnel devices your current kernel has
by typing the following:&prompt.root; ifconfig -a
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff
tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576
tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff
tun3: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500This case shows four tunnel devices, two of which are
currently configured and being used.If you have a kernel without the tun device, and you can not
rebuild it for some reason, all is not lost. You should be able
to dynamically load the code. Refer to the appropriate modload8
and lkm4 pages for further details.You may also wish to take this opportunity to configure a
firewall. Details can be found in the section.Check the tun deviceMost users will only require one tun device (/dev/tun0). If you
have used more (i.e., a number other than 1 in the pseudo-device
line in the kernel configuration file) then alter all references
to tun0 below to reflect whichever device number you are
using.The easiest way to make sure that the tun0 device is
configured correctly is to re-make it. To do this, execute the
following commands:&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tun0If you require 16 tunnel devices in your kernel, you will need
to create more than just tun0:&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tun15Also, to confirm that the kernel is configured correctly, the
following command should give the indicated output:&prompt.root; ifconfig tun0
tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500Name Resolution ConfigurationThe resolver is the part of the system that turns IP addresses
into hostnames and vice versa. It can be configured to look for
maps that describe IP to hostname mappings in one of two places.
The first is a file called /etc/hosts
(man 5 hosts). The second is the
Internet Domain Name Service (DNS), a distributed data base, the
discussion of which is beyond the scope of this document.This section describes briefly how to configure your
resolver.The resolver is a set of system calls that do the name
mappings, but you have to tell them where to find their
information. You do this by first editing the file
/etc/host.conf. Do not call this file
/etc/hosts.conf (note the extra s) as the
results can be confusing.Edit the <filename>/etc/host.conf</filename> fileThis file should contain the following two lines:
hosts
bindThese instructs the resolver to first look in
the file /etc/hosts, and then to consult
the DNS if the name was not found.Edit the <filename>/etc/hosts</filename>(5) fileThis file should contain the IP addresses and names of
machines on your network. At a bare minimum it should contain
entries for the machine which will be running ppp. Assuming that
your machine is called foo.bar.com
with the IP address 10.0.0.1,
/etc/hosts should contain:
127.0.0.1 localhost
10.0.0.1 foo.bar.com fooThe first line defines the alias localhost as a synonym
for the current machine. Regardless of your own IP address, the
IP address for this line should always be 127.0.0.1. The second
line maps the name foo.bar.com (and the shorthand foo)
to the IP address 10.0.0.1.If your provider allocates you a static IP address and name,
then use these in place of the 10.0.0.1 entry.Edit the <filename>/etc/resolv.conf</filename> file/etc/resolv.conf tells the resolver how
to behave. If you are running your own DNS, you may leave this
file empty. Normally, you will need to enter the following
line(s):
nameserver x.x.x.x
nameserver y.y.y.y
domain bar.comThe x.x.x.x and
y.y.y.y addresses are those given to you
by your ISP. Add as many nameserver lines as your ISP
provides. The domain line defaults to your hostname's
domain, and is probably unnecessary. Refer to the resolv.conf
manual page for details of other possible entries in this
file.<command>ppp</command> ConfigurationBoth user ppp and pppd (the kernel level implementation of
PPP) use configuration files located in the
/etc/ppp directory. The sample configuration
files provided are a good reference for user ppp, so don't delete
them.Configuring ppp requires that you edit a number of files,
depending on your requirements. What you put in them depends to
some extent on whether your ISP allocates IP addresses statically
(i.e., you get given one IP address, and always use that one) or
dynamically (i.e., your IP address can be different for each PPP
session).PPP and Static IP addressesYou will need to create a configuration file called
/etc/ppp/ppp.conf. It should look similar
to the example below.Lines that end in a : start in the first column, all
other lines should be indented as shown using spaces or
tabs.
1 default:
2 set device /dev/cuaa0
3 set speed 115200
4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT"
5 provider:
6 set phone "(0123) 456 7890"
7 set login "TIMEOUT 10 gin:-BREAK-gin: foo word: bar col: ppp"
8 set timeout 300
9 deny lqr
10 set ifaddr x.x.x.xy.y.y.y
11 delete ALL
12 add 0 0 HISADDRDo not include the line numbers, they are
just for reference in this discussion.Line 1:Identifies the default entry. Commands in this
entry are executed automatically when ppp is run.Line 2:Identifies the device to which the modem is
connected. COM1: is /dev/cuaa0 and
COM2: is /dev/cuaa1.Line 3:Sets the speed you want to connect at. If 115200
doesn't work (it should with any reasonably new modem),
try 38400 instead.Line 4:The dial string. User PPP uses an expect-send
syntax similar to the chat8
program. Refer to the manual page for information on
the features of this language.Line 5:Identifies an entry for a provider called
“provider”.Line 6:Sets the phone number for this provider. Multiple
phone numbers may be specified using the
: or |
character as a separator. The difference between these
spearators is described in the ppp manual page. To
summarize, if you want to rotate through the numbers,
use the :. If you want to always attempt to dial
the first number first and only use the other numbers if
the first number fails, use the |. Always quote the
entire set of phone numbers as shown.Line 7:The login string is of the same chat-like syntax as
the dial string. In this example, the string works for
a service whose login session looks like this:J. Random Provider
login: foo
password: bar
protocol: pppYou will need to alter this script to suit your own
needs. If you're using PAP or CHAP, there will be no
login at this point, so your login string can be left
blank. See
for further details.Line 8:Sets the default timeout (in seconds) for the
connection. Here, the connection will be closed
automatically after 300 seconds of inactivity. If you
never want to timeout, set this value to zero.Line 9:ppp can be configured to exchange Link Quality
Report (LQR) packets. These packets describe how good
the physical link is. ppp's LQR strategy is to close
the connection when a number of these packets are
missed. This is useful when you have a direct serial
link to another machine and the DSR modem signal is not
available to indicate that the line is up. When data
saturates the line, LQR packets are sometimes
“missed”, causing ppp to close the connection
prematurely. Refusing to negotiate lqr is sometimes
prudent (if you are going through a modem) as it avoids
this whole mess. By default, ppp will not attempt to
negotiate LQR, but will accept LQR negotiation from the
peer.Line 10:Sets the interface addresses. The string x.x.x.x
should be replaced by the IP address that your provider
has allocated to you. The string y.y.y.y should be
replaced by the IP address that your ISP indicated for
their gateway (the machine to which you connect). If
your ISP hasn't given you a gateway address, use
10.0.0.2/0. If you need
to use a “guessed” address, make sure that you create
an entry in /etc/ppp/ppp.linkup as
per the instructions for
. If this line is omitted, ppp cannot
run in or
mode.Line 11:Deletes all existing routing table entries for the
acquired tun device. This should not normally be
necessary, but will make sure that ppp is starting with
a clean bill of health.Line 12:Adds a default route to your ISPs gateway. The
special word HISADDR is replaced with
the gateway address specified on line 9. It is
important that this line appears after line 9, otherwise
HISADDR will not yet be
initialized.It is not necessary to add an entry to
ppp.linkup when you have a static IP
address as your routing table entries are already correct before
you connect. You may however wish to create an entry to invoke
programs after connection. This is explained later with the
sendmail example.Example configuration files can be found in the
/etc/ppp directory.PPP and Dynamic IP addressesIf your service provider does not assign static IP numbers,
ppp can be configured to negotiate
the local and remote addresses. This is done by “guessing” an
IP number and allowing ppp to set it up correctly using the IP
Configuration Protocol (IPCP) after connecting. The
ppp.conf configuration is the same as , with the following change:
10 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0Again, do not include the line numbers, they are just for
reference in this discussion. Indentation of at least one space
is required.Line 10:The number after the / character is the number
of bits of the address that ppp will insist on. You may
wish to use IP numbers more appropriate to your
circumstances, but the above example will almost always
work. If it fails, you may be able to defeat some
broken ppp implementations by supplying an additional
0.0.0.0 argument:
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0This tells ppp to negotiate using address 0.0.0.0 rather than 10.0.0.1. Do not use 0.0.0.0/0 as the first argument
to set ifaddr as it
prevents ppp from setting up an initial route in
and
mode.You will also need to create an entry in
/etc/ppp/ppp.linkup.
ppp.linkup is used after a connection has
been established. At this point, ppp will know what IP
addresses should really be used.
The following entry will delete the existing bogus routes, and
create correct ones:
1 provider:
2 delete ALL
3 add 0 0 HISADDRLine 1:On establishing a connection, ppp will look for an
entry in ppp.linkup according to
the following rules: First, try to match the same label
as we used in ppp.conf. If that
fails, look for an entry for the IP number of our
gateway. This entry is a four-octet IP style label. If
we still haven't found an entry, look for the
MYADDR entry.Line 2:This line tells ppp to delete all existing routes
for the acquired tun interface (except the direct route
entry).Line 3:This line tells ppp to add a default route that
points to HISADDR.
HISADDR will be replaced with the IP
number of the gateway as negotiated in the IPCP.See the pmdemand entry in the files
/etc/ppp/ppp.conf.sample and
/etc/ppp/ppp.linkup.sample for a detailed
example.Receiving incoming calls with <command>ppp</command>This section describes setting up ppp in a server
role.When you configure ppp to
receive incoming calls, you must decide whether you wish to
forward packets for just PPP
connections, for all interfaces, or not at all. To forward for
just PPP connections, include the line
enable proxy
in your ppp.conf file. If you wish to
forward packets on all interfaces, use the
gateway=YES
option in /etc/rc.conf (this file used
to be called /etc/sysconfig).Which getty? provides a good description on enabling
dialup services using getty.An alternative to getty is mgetty, a smarter version of getty designed with dialup lines in mind.The advantages of using mgetty is that it actively
talks to modems, meaning if port is
turned off in /etc/ttys then your modem
won't answer the phone.Later versions of mgetty (from 0.99beta onwards) also
support the automatic detection of PPP streams, allowing your
clients script-less access to your server.Refer to for more information on mgetty.PPP permissionsppp must normally be run as user id 0. If however you
wish to allow ppp to run in server mode as a normal user by
executing ppp as described below, that user must be given
permission to run ppp by adding them to the
network group in
/etc/group.Setting up a PPP shell for dynamic-IP usersCreate a file called
/etc/ppp/ppp-shell containing the
following:
#!/bin/sh
IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'`
CALLEDAS="$IDENT"
TTY=`tty`
if [ x$IDENT = xdialup ]; then
IDENT=`basename $TTY`
fi
echo "PPP for $CALLEDAS on $TTY"
echo "Starting PPP for $IDENT"
exec /usr/sbin/ppp -direct $IDENTThis script should be executable. Now make a symbolic
link called ppp-dialup to this script
using the following commands:&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-dialupYou should use this script as the
shell for all your dialup ppp users.
This is an example from /etc/password for
a dialup PPP user with username pchilds. (remember don't
directly edit the password file, use vipw)
pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialupCreate a /home/ppp directory that is
world readable containing the following 0 byte files
-r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin
-r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts
which prevents /etc/motd from being
displayed.Setting up a PPP shell for static-IP usersCreate the ppp-shell file as above
and for each account with statically assigned IPs create a
symbolic link to ppp-shell.For example, if you have three dialup customers fred, sam,
and mary, that you route class C networks for, you would type
the following:&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred
&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam
&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-maryEach of these users dialup accounts should have their
shell set to the symbolic link created above. (ie. mary's
shell should be
/etc/ppp/ppp-mary).Setting up ppp.conf for dynamic-IP usersThe /etc/ppp/ppp.conf file should
contain something along the lines of
default:
set debug phase lcp chat
set timeout 0
ttyd0:
set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255
enable proxy
ttyd1:
set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255
enable proxyThe indenting is important.The default: section is
loaded for each session. For each dialup line enabled in
/etc/ttys create an entry similar to the
one for ttyd0: above. Each line
should get a unique IP address from your pool of IP addresses for
dynamic users.Setting up <filename>ppp.conf</filename> for static-IP usersAlong with the contents of the sample
/etc/ppp/ppp.conf above you should add a
section for each of the statically assigned dialup users. We
will continue with our fred, sam, and mary example.
fred:
set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255
sam:
set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255
mary:
set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255The file /etc/ppp/ppp.linkup should
also contain routing information for each static IP user if
required. The line below would add a route for the 203.14.101.0 class C via the client's
ppp link.
fred:
add 203.14.101.0 netmask 255.255.255.0 HISADDR
sam:
add 203.14.102.0 netmask 255.255.255.0 HISADDR
mary:
add 203.14.103.0 netmask 255.255.255.0 HISADDRMore on <command>mgetty</command>, AutoPPP, and MS extensions<command>mgetty</command> and AutoPPPConfiguring and compiling mgetty with the AUTO_PPP
option enabled allows mgetty to detect the LCP phase of PPP
connections and automatically spawn off a ppp shell.
However, since the default login/password sequence does not
occur it is necessary to authenticate users using either PAP
or CHAP.This section assumes the user has successfully
configured, compiled, and installed a version of mgetty with
the AUTO_PPP option (v0.99beta or later)Make sure your
/usr/local/etc/mgetty+sendfax/login.config file has the following in it:
/AutoPPP/ - - /etc/ppp/ppp-pap-dialupThis will tell mgetty to run the
ppp-pap-dialup script for detected PPP
connections.Create a file called
/etc/ppp/ppp-pap-dialup containing the
following (the file should be executable):
#!/bin/sh
TTY=`tty`
IDENT=`basename $TTY`
exec /usr/sbin/ppp -direct pap$IDENTFor each dialup line enabled in
/etc/ttys create a corresponding entry
in /etc/ppp/ppp.conf. This will
happily co-exist with the definitions we created
above.
papttyd0:
enable pap
set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255
enable proxy
papttyd1:
enable pap
set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255
enable proxyEach user logging in with this method will need to have
a username/password in
/etc/ppp/ppp.secret file, or
alternatively add the
enable passwdauthoption to authenticate users via pap from the
/etc/passwordd file(*) Note this option only available in 2.2-961014-SNAP
or later, or by getting the updated ppp code for 2.1.x. (see
MS extensions below for details).MS extentionsFrom 2.2-961014-SNAP onwards it is possible to allow the
automatic negotiation of DNS and NetBIOS name servers with
clients supporting this feature (namely Win95/NT clients).
See RFC1877 for more details on the protocol.An example of enabling these extensions in your
/etc/ppp/ppp.conf file is illustrated
below.
default:
set debug phase lcp chat
set timeout 0
enable msext
set ns 203.14.100.1 203.14.100.2
set nbns 203.14.100.5This will tell the clients the primary and secondary
name server addresses, and a netbios nameserver host.PAP and CHAP authenticationSome ISPs set their system up so that the authentication
part of your connection is done using either of the PAP or CHAP
authentication mechanisms. If this is the case, your ISP will
not give a login: prompt when you
connect, but will start talking PPP immediately.PAP is less secure than CHAP, but security is not normally
an issue here as passwords, although being sent as plain text
with PAP, are being transmitted down a serial line only.
There's not much room for hackers to “eavesdrop”.Referring back to the or sections, the following alterations must be
made:
7 set login
…
13 set authname MyUserName
14 set authkey MyPasswordAs always, do not include the line numbers, they are just
for reference in this discussion. Indentation of at least one
space is required.Line 7:Your ISP will not normally require that you log into
the server if you're using PAP or CHAP. You must
therefore disable your "set login" string.Line 13:This line specifies your PAP/CHAP user name. You
will need to insert the correct value for MyUserName.Line 14:This line specifies your PAP/CHAP password. You
will need to insert the correct value for MyPassword. You may want to add an
additional line
15 accept PAP or
15 accept CHAP to make it obvious that this is the
intention, but PAP and CHAP are accepted by
default.Your authkey will be logged
if you have command logging turned on (set log
+command). Care should be taken when deciding the
ppp log file permissions.Changing your <command>ppp</command> configuration on the flyIt is possible to talk to the ppp program while it is
running in the background, but only if a suitable password has
been set up.By default, ppp will listen to a TCP port of 3000 +
tunno, where tunno is the number of the tun device
acquired, however, if a password for the local machine is not
set up in /etc/ppp/ppp.secret, no server
connection will be created. To set your password, put the
following line in
/etc/ppp/ppp.secret:fooMyPasswordfoo is your local
hostname (run hostname -s to determine the
correct name), and MyPassword is
the unencrypted password that you wish to use.
/etc/ppp/ppp.secret should
not be accessable by anyone without user id
0. This means that /,
/etc and /etc/ppp
should not be writable, and ppp.secret
should be owned by user id 0 and have permissions 0600.It is also possible to select a specific port number or to
have ppp listen to a local unix domain socket rather than to a
TCP socket. Refer to the set
socket command in manual page for further
details.Once a socket has been set up, the
pppctl8 program may be used in scripts that
wish to manipulate the running program.Final system configurationYou now have ppp configured, but there are a few more things
to do before it is ready to work. They all involve editing the
/etc/rc.conf file (was
/etc/sysconfig).Working from the top down in this file, make sure the
hostname= line is set, e.g.:
hostname=foo.bar.comIf your ISP has supplied you with a static IP address and
name, it's probably best that you use this name as your host
name.Look for the network_interfaces variable. If you want to
configure your system to dial your ISP on demand, make sure the
tun0 device is added to the list, otherwise remove it.
network_interfaces="lo0 tun0" ifconfig_tun0=The ifconfig_tun0 variable should be empty,
and a file called /etc/start_if.tun0 should
be created. This file should contain the line
ppp -auto mysystemThis script is executed at network configuration time,
starting your ppp daemon in automatic mode. If you have a LAN
for which this machine is a gateway, you may also wish to use
the switch. Refer to the manual page
for further details.Set the router program to NO with the line
router_enable=NO (/etc/rc.conf)
router=NO (/etc/sysconfig)It is important that the routed
daemon is not started (it's started by default) as routed tends to delete the default routing
table entries created by ppp.It is probably worth your while ensuring that the
sendmail_flags line does not include the option,
otherwise sendmail will attempt to do a network lookup every now
and then, possibly causing your machine to dial out. You may
try:
sendmail_flags="-bd"The upshot of this is that you must force sendmail to
re-examine the mail queue whenever the ppp link is up by
typing:&prompt.root; /usr/sbin/sendmail -qYou may wish to use the !bg
command in ppp.linkup to do this
automatically:
1 provider:
2 delete ALL
3 add 0 0 HISADDR
4 !bg sendmail -bd -q30mIf you don't like this, it is possible to set up a “dfilter”
to block SMTP traffic. Refer to the sample files for further
details.All that is left is to reboot the machine.After rebooting, you can now either type&prompt.root; pppand then dial provider to start the PPP session, or, if
you want ppp to establish sessions automatically when there is
outbound traffic (and you haven't created the start_if.tun0
script), type&prompt.root; ppp -auto providerSummaryTo recap, the following steps are necessary when setting up
ppp for the first time:Client side:Ensure that the tun device is built into your
kernel.Ensure that the tunX device file is
available in the /dev directory.Create an entry in
/etc/ppp/ppp.conf. The pmdemand example should suffice for
most ISPs.If you have a dynamic IP address, create an entry in
/etc/ppp/ppp.linkup.Update your /etc/rc.conf (or
sysconfig) file.Create a start_if.tun0 script if you require demand
dialing.Server side:Ensure that the tun device is built into your
kernel.Ensure that the tunX device file is
available in the /dev directory.Create an entry in /etc/passwd
(using the vipw8 program).Create a profile in this users home directory that runs
ppp -direct direct-server or similar.Create an entry in
/etc/ppp/ppp.conf. The direct-server example should
suffice.Create an entry in
/etc/ppp/ppp.linkup.Update your /etc/rc.conf (or
sysconfig) file.AcknowledgmentsThis section of the handbook was last updated on Sun Sep 7,
1997 by &a.brian;Thanks to the following for their input, comments &
suggestions:&a.nik;&a.dirkvangulik;&a.pjc;Setting up Kernel PPPContributed by &a.gena;.Before you start setting up PPP on your machine make sure that
pppd is located in /usr/sbin and directory
/etc/ppp exists.pppd can work in two modes:as a “client”, i.e. you want to connect your machine to
outside world via PPP serial connection or modem line.as a “server”, i.e. your machine is located on the
network and used to connect other computers using PPP.In both cases you will need to set up an options file
(/etc/ppp/options or
~/.ppprc if you have more then one user on your
machine that uses PPP).You also will need some modem/serial software (preferably
kermit) so you can dial and establish connection with remote
host.Working as a PPP clientI used the following /etc/ppp/options to
connect to CISCO terminal server PPP line.
crtscts # enable hardware flow control
modem # modem control line
noipdefault # remote PPP server must supply your IP address.
# if the remote host doesn't send your IP during IPCP
# negotiation , remove this option
passive # wait for LCP packets
domain ppp.foo.com # put your domain name here
:<remote_ip> # put the IP of remote PPP host here
# it will be used to route packets via PPP link
# if you didn't specified the noipdefault option
# change this line to <local_ip>:<remote_ip>
defaultroute # put this if you want that PPP server will be your
# default routerTo connect:Dial to the remote host using kermit (or other modem
program) enter your user name and password (or whatever is
needed to enable PPP on the remote host)Exit kermit (without hanging up the line).enter:&prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty0119200Use the appropriate speed and device name.Now your computer is connected with PPP. If the connection
fails for some reasons you can add the option to the
/etc/ppp/options file and check messages on
the console to track the problemFollowing /etc/ppp/pppup script will make
all 3 stages automatically:
#!/bin/sh
ps ax |grep pppd |grep -v grep
pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
if [ "X${pid}" != "X" ] ; then
echo 'killing pppd, PID=' ${pid}
kill ${pid}
fi
ps ax |grep kermit |grep -v grep
pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
if [ "X${pid}" != "X" ] ; then
echo 'killing kermit, PID=' ${pid}
kill -9 ${pid}
fi
ifconfig ppp0 down
ifconfig ppp0 delete
kermit -y /etc/ppp/kermit.dial
pppd /dev/tty01 19200/etc/ppp/kermit.dial is kermit script
that dials and makes all necessary authorization on the remote
host. (Example of such script is attached to the end of this
document)Use the following /etc/ppp/pppdown script
to disconnect the PPP line:
#!/bin/sh
pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
if [ X${pid} != "X" ] ; then
echo 'killing pppd, PID=' ${pid}
kill -TERM ${pid}
fi
ps ax |grep kermit |grep -v grep
pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
if [ "X${pid}" != "X" ] ; then
echo 'killing kermit, PID=' ${pid}
kill -9 ${pid}
fi
/sbin/ifconfig ppp0 down
/sbin/ifconfig ppp0 delete
kermit -y /etc/ppp/kermit.hup
/etc/ppp/ppptestCheck if PPP is still running
(/usr/etc/ppp/ppptest):
#!/bin/sh
pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'`
if [ X${pid} != "X" ] ; then
echo 'pppd running: PID=' ${pid-NONE}
else
echo 'No pppd running.'
fi
set -x
netstat -n -I ppp0
ifconfig ppp0Hangs up modem line
(/etc/ppp/kermit.hup):
set line /dev/tty01 ; put your modem device here
set speed 19200
set file type binary
set file names literal
set win 8
set rec pack 1024
set send pack 1024
set block 3
set term bytesize 8
set command bytesize 8
set flow none
pau 1
out +++
inp 5 OK
out ATH0\13
echo \13
exitHere is an alternate method using chat instead of kermit.Contributed by &a.rhuff;.The following two files are sufficient to accomplish a pppd
connection./etc/ppp/options:
/dev/cuaa1 115200
crtscts # enable hardware flow control
modem # modem control line
connect "/usr/bin/chat -f /etc/ppp/login.chat.script"
noipdefault # remote PPP serve must supply your IP address.
# if the remote host doesn't send your IP during
# IPCP negotiation, remove this option
passive # wait for LCP packets
domain <your.domain> # put your domain name here
: # put the IP of remote PPP host here
# it will be used to route packets via PPP link
# if you didn't specified the noipdefault option
# change this line to <local_ip>:<remote_ip>
defaultroute # put this if you want that PPP server will be
# your default router/etc/ppp/login.chat.script:(This should actually go into a single line.)
ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number>
CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id>
TIMEOUT 5 sword: <password>Once these are installed and modified correctly, all you need
to do is&prompt.root; pppdThis sample based primarily on information provided
by: Trev Roydhouse
<Trev.Roydhouse@f401.n711.z3.fidonet.org> and used by
permission.Working as a PPP server/etc/ppp/options:
crtscts # Hardware flow control
netmask 255.255.255.0 # netmask ( not required )
192.114.208.20:192.114.208.165 # ip's of local and remote hosts
# local ip must be different from one
# you assigned to the ethernet ( or other )
# interface on your machine.
# remote IP is ip address that will be
# assigned to the remote machine
domain ppp.foo.com # your domain
passive # wait for LCP
modem # modem lineFollowing /etc/ppp/pppserv script will
enable ppp server on your machine:
#!/bin/sh
ps ax |grep pppd |grep -v grep
pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
if [ "X${pid}" != "X" ] ; then
echo 'killing pppd, PID=' ${pid}
kill ${pid}
fi
ps ax |grep kermit |grep -v grep
pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
if [ "X${pid}" != "X" ] ; then
echo 'killing kermit, PID=' ${pid}
kill -9 ${pid}
fi
# reset ppp interface
ifconfig ppp0 down
ifconfig ppp0 delete
# enable autoanswer mode
kermit -y /etc/ppp/kermit.ans
# run ppp
pppd /dev/tty01 19200Use this /etc/ppp/pppservdown script to
stop ppp server:
#!/bin/sh
ps ax |grep pppd |grep -v grep
pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
if [ "X${pid}" != "X" ] ; then
echo 'killing pppd, PID=' ${pid}
kill ${pid}
fi
ps ax |grep kermit |grep -v grep
pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
if [ "X${pid}" != "X" ] ; then
echo 'killing kermit, PID=' ${pid}
kill -9 ${pid}
fi
ifconfig ppp0 down
ifconfig ppp0 delete
kermit -y /etc/ppp/kermit.noansFollowing kermit script will enable/disable autoanswer mode
on your modem (/etc/ppp/kermit.ans):
set line /dev/tty01
set speed 19200
set file type binary
set file names literal
set win 8
set rec pack 1024
set send pack 1024
set block 3
set term bytesize 8
set command bytesize 8
set flow none
pau 1
out +++
inp 5 OK
out ATH0\13
inp 5 OK
echo \13
out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable
; autoanswer mod
inp 5 OK
echo \13
exitThis /etc/ppp/kermit.dial script is used
for dialing and authorizing on remote host. You will need to
customize it for your needs. Put your login and password in this
script, also you will need to change input statement depending on
responses from your modem and remote host.
;
; put the com line attached to the modem here:
;
set line /dev/tty01
;
; put the modem speed here:
;
set speed 19200
set file type binary ; full 8 bit file xfer
set file names literal
set win 8
set rec pack 1024
set send pack 1024
set block 3
set term bytesize 8
set command bytesize 8
set flow none
set modem hayes
set dial hangup off
set carrier auto ; Then SET CARRIER if necessary,
set dial display on ; Then SET DIAL if necessary,
set input echo on
set input timeout proceed
set input case ignore
def \%x 0 ; login prompt counter
goto slhup
:slcmd ; put the modem in command mode
echo Put the modem in command mode.
clear ; Clear unread characters from input buffer
pause 1
output +++ ; hayes escape sequence
input 1 OK\13\10 ; wait for OK
if success goto slhup
output \13
pause 1
output at\13
input 1 OK\13\10
if fail goto slcmd ; if modem doesn't answer OK, try again
:slhup ; hang up the phone
clear ; Clear unread characters from input buffer
pause 1
echo Hanging up the phone.
output ath0\13 ; hayes command for on hook
input 2 OK\13\10
if fail goto slcmd ; if no OK answer, put modem in command mode
:sldial ; dial the number
pause 1
echo Dialing.
output atdt9,550311\13\10 ; put phone number here
assign \%x 0 ; zero the time counter
:look
clear ; Clear unread characters from input buffer
increment \%x ; Count the seconds
input 1 {CONNECT }
if success goto sllogin
reinput 1 {NO CARRIER\13\10}
if success goto sldial
reinput 1 {NO DIALTONE\13\10}
if success goto slnodial
reinput 1 {\255}
if success goto slhup
reinput 1 {\127}
if success goto slhup
if < \%x 60 goto look
else goto slhup
:sllogin ; login
assign \%x 0 ; zero the time counter
pause 1
echo Looking for login prompt.
:slloop
increment \%x ; Count the seconds
clear ; Clear unread characters from input buffer
output \13
;
; put your expected login prompt here:
;
input 1 {Username: }
if success goto sluid
reinput 1 {\255}
if success goto slhup
reinput 1 {\127}
if success goto slhup
if < \%x 10 goto slloop ; try 10 times to get a login prompt
else goto slhup ; hang up and start again if 10 failures
:sluid
;
; put your userid here:
;
output ppp-login\13
input 1 {Password: }
;
; put your password here:
;
output ppp-password\13
input 1 {Entering SLIP mode.}
echo
quit
:slnodial
echo \7No dialtone. Check the telephone line!\7
exit 1
; local variables:
; mode: csh
; comment-start: "; "
; comment-start-skip: "; "
; end:Setting up a SLIP ClientContributed by &a.asami;8 Aug
1995.The following is one way to set up a FreeBSD machine for SLIP on
a static host network. For dynamic hostname assignments (i.e., your
address changes each time you dial up), you probably need to do
something much fancier.First, determine which serial port your modem is connected to. I
have a symbolic link to /dev/modem from
/dev/cuaa1, and only use the modem name in my configuration
files. It can become quite cumbersome when you need to fix a bunch
of files in /etc and
.kermrc's all over the system!/dev/cuaa0 is COM1,
cuaa1 is COM2, etc.Make sure you have
pseudo-device sl 1 in your kernel's config file. It is included in
the GENERIC kernel, so this will not be a
problem unless you deleted it.Things you have to do only onceAdd your home machine, the gateway and nameservers to
your /etc/hosts file. Mine looks like
this:
127.0.0.1 localhost loghost
136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia
136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway
128.32.136.9 ns1.Berkeley.edu ns1
128.32.136.12 ns2.Berkeley.edu ns2By the way, silvia is
the name of the car that I had when I was back in Japan (it
is called 2?0SX here in U.S.).Make sure you have before in your
/etc/host.conf. Otherwise, funny things
may happen.Edit the file /etc/rc.conf. Note
that you should edit the file
/etc/sysconfig instead if you are
running FreeBSD previous to version 2.2.2.Set your hostname by editing the line that says:
hostname=myname.my.domainYou should give it your full Internet hostname.Add sl0 to the list of network interfaces by
changing the line that says:
network_interfaces="lo0"to:
network_interfaces="lo0 sl0"Set the startup flags of sl0 by adding a line:
ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up"Designate the default router by changing the line:
defaultrouter=NOto:
defaultrouter=slip-gatewayMake a file /etc/resolv.conf which
contains:
domain HIP.Berkeley.EDU
nameserver 128.32.136.9
nameserver 128.32.136.12As you can see, these set up the nameserver hosts. Of
course, the actual domain names and addresses depend on your
environment.Set the password for root and toor (and any other
accounts that does not have a password). Use passwd, do not
edit the /etc/passwd or
/etc/master.passwd files!Reboot your machine and make sure it comes up with the
correct hostname.Making a SLIP connectionDial up, type slip at the prompt, enter your machine
name and password. The things you need to enter depends on
your environment. I use kermit, with a script like this:
# kermit setup
set modem hayes
set line /dev/modem
set speed 115200
set parity none
set flow rts/cts
set terminal bytesize 8
set file type binary
# The next macro will dial up and login
define slip dial 643-9600, input 10 =>, if failure stop, -
output slip\x0d, input 10 Username:, if failure stop, -
output silvia\x0d, input 10 Password:, if failure stop, -
output ***\x0d, echo \x0aCONNECTED\x0a(of
course, you have to change the hostname and password to fit
yours). Then you can just type slip from the kermit
prompt to get connected.Leaving your password in plain text anywhere in the
filesystem is generally a BAD idea. Do it at your own
risk. I am just too lazy.Leave the kermit there (you can suspend it by z) and
as root, type:&prompt.root; slattach -h -c -s 115200 /dev/modemIf you are able to ping hosts
on the other side of the router, you are connected! If it
does not work, you might want to try instead of as
an argument to slattach.How to shutdown the connectionType
&prompt.root; kill -INT `cat /var/run/slattach.modem.pid`(as root)
to kill slattach. Then go back to kermit (fg if you suspended
it) and exit from it (q).The slattach man page says you have to use ifconfig sl0 down
to mark the interface down, but this does not seem to make any
difference for me. (ifconfig sl0 reports the same
thing.)Some times, your modem might refuse to drop the carrier (mine
often does). In that case, simply start kermit and quit it again.
It usually goes out on the second try.TroubleshootingIf it does not work, feel free to ask me. The things that
people tripped over so far:Not using or in slattach (I have no idea why
this can be fatal, but adding this flag solved the problem
for at least one person)Using instead of (might be hard to see the
difference on some fonts).Try ifconfig sl0 to see your
interface status. I get:&prompt.root; ifconfig sl0
sl0: flags=10<POINTOPOINT>
inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00Also, netstat -r will give the
routing table, in case you get the "no route to host"
messages from ping. Mine looks like:&prompt.root; netstat -r
Routing tables
Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks:
(root node)
(root node)
Route Tree for Protocol Family inet:
(root node) =>
default inr-3.Berkeley.EDU UG 8 224515 sl0 - -
localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438
inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - -
silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438
(root node)(this is after transferring a bunch
of files, your numbers should be smaller).Setting up a SLIP ServerContributed by &a.ghelmer;. v1.0, 15 May
1995.This document provides suggestions for setting up SLIP Server
services on a FreeBSD system, which typically means configuring your
system to automatically startup connections upon login for remote
SLIP clients. The author has written this document based on his
experience; however, as your system and needs may be different, this
document may not answer all of your questions, and the author cannot
be responsible if you damage your system or lose data due to
attempting to follow the suggestions here.This guide was originally written for SLIP Server services on a
FreeBSD 1.x system. It has been modified to reflect changes in the
pathnames and the removal of the SLIP interface compression flags in
early versions of FreeBSD 2.X, which appear to be the only major
changes between FreeBSD versions. If you do encounter mistakes in
this document, please email the author with enough information to
help correct the problem.PrerequisitesThis document is very technical in nature, so background
knowledge is required. It is assumed that you are familiar with
the TCP/IP network protocol, and in particular, network and node
addressing, network address masks, subnetting, routing, and
routing protocols, such as RIP. Configuring SLIP services on a
dial-up server requires a knowledge of these concepts, and if you
are not familiar with them, please read a copy of either Craig
Hunt's TCP/IP Network Administration
published by O'Reilly & Associates, Inc. (ISBN Number
0-937175-82-X), or Douglas Comer's books on the TCP/IP
protocol.It is further assumed that you have already setup your
modem(s) and configured the appropriate system files to allow
logins through your modems. If you have not prepared your system
for this yet, please see the tutorial for configuring dialup
services; if you have a World-Wide Web browser available, browse
the list of tutorials at http://www.freebsd.org/;
otherwise, check the place where you found this document for a
document named dialup.txt or something
similar. You may also want to check the manual pages for
sio4 for information on the serial
port device driver and ttys5,
gettytab5,
getty8, & init8 for
information relevant to configuring the system to accept logins on
modems, and perhaps stty1 for information on
setting serial port parameters (such as clocal for directly-connected serial
interfaces).Quick OverviewIn its typical configuration, using FreeBSD as a SLIP server
works as follows: a SLIP user dials up your FreeBSD SLIP Server
system and logs in with a special SLIP login ID that uses
/usr/sbin/sliplogin as the special user's
shell. The sliplogin program
browses the file /etc/sliphome/slip.hosts to
find a matching line for the special user, and if it finds a
match, connects the serial line to an available SLIP interface and
then runs the shell script
/etc/sliphome/slip.login to configure the
SLIP interface.An Example of a SLIP Server LoginFor example, if a SLIP user ID were
Shelmerg, Shelmerg's entry in
/etc/master.passwd would look something
like this (except it would be all on one line):
Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliploginWhen Shelmerg logs in,
sliplogin will search
/etc/sliphome/slip.hosts for a line that
had a matching user ID; for example, there may be a line in
/etc/sliphome/slip.hosts that reads:
Shelmerg dc-slip sl-helmer 0xfffffc00 autocompsliplogin will find that
matching line, hook the serial line into the next available SLIP
interface, and then execute
/etc/sliphome/slip.login like this:
/etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocompIf all goes well,
/etc/sliphome/slip.login will issue an
ifconfig for the SLIP interface to
which sliplogin attached itself
(slip interface 0, in the above example, which was the first
parameter in the list given to slip.login)
to set the local IP address (dc-slip), remote
IP address (sl-helmer), network mask for the SLIP
interface (0xfffffc00), and any additional
flags (autocomp). If something
goes wrong, sliplogin usually logs
good informational messages via the daemon syslog facility,
which usually goes into /var/log/messages
(see the manual pages for syslogd8 and
syslog.conf5, and perhaps check
/etc/syslog.conf to see to which files
syslogd is logging).OK, enough of the examples — let us dive into setting up
the system.Kernel ConfigurationFreeBSD's default kernels usually come with two SLIP
interfaces defined (sl0 and
sl1); you can use netstat -i to see whether these interfaces
are defined in your kernel.Sample output from netstat -i:Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133
ed0 1500 138.247.224 ivory 291311 0 174209 0 133
lo0 65535 <Link> 79 0 79 0 0
lo0 65535 loop localhost 79 0 79 0 0
sl0* 296 <Link> 0 0 0 0 0
sl1* 296 <Link> 0 0 0 0 0The sl0 and sl1 interfaces shown in netstat -i's output indicate that there are
two SLIP interfaces built into the kernel. (The asterisks after
the sl0 and sl1 indicate that the interfaces are
“down”.)However, FreeBSD's default kernels do not come configured to
forward packets (ie, your FreeBSD machine will not act as a
router) due to Internet RFC requirements for Internet hosts (see
RFC's 1009 [Requirements for Internet Gateways], 1122
[Requirements for Internet Hosts — Communication Layers], and
perhaps 1127 [A Perspective on the Host Requirements RFCs]), so if
you want your FreeBSD SLIP Server to act as a router, you will
have to edit the /etc/rc.conf file (called
/etc/sysconfig in FreeBSD releases prior to
2.2.2) and change the setting of the gateway variable to .
If you have an older system which predates even the
/etc/sysconfig file, then add the following
command:
sysctl -w net.inet.ip.forwarding = 1 to your /etc/rc.local
file.You will then need to reboot for the new settings to take
effect.You will notice that near the end of the default kernel
configuration file (/sys/i386/conf/GENERIC)
is a line that reads:
pseudo-device sl 2This is the line that defines the number of SLIP devices
available in the kernel; the number at the end of the line is the
maximum number of SLIP connections that may be operating
simultaneously.Please refer to for help in
reconfiguring your kernel.Sliplogin ConfigurationAs mentioned earlier, there are three files in the
/etc/sliphome directory that are part of the
configuration for /usr/sbin/sliplogin (see
sliplogin8 for the actual manual page for
sliplogin):
slip.hosts, which defines the SLIP users
& their associated IP addresses;
slip.login, which usually just configures the
SLIP interface; and (optionally) slip.logout,
which undoes slip.login's effects when the
serial connection is terminated.<filename>slip.hosts</filename> Configuration/etc/sliphome/slip.hosts contains lines
which have at least four items, separated by whitespace:SLIP user's login IDLocal address (local to the SLIP server) of the SLIP
linkRemote address of the SLIP linkNetwork maskThe local and remote addresses may be host names (resolved
to IP addresses by /etc/hosts or by the
domain name service, depending on your specifications in
/etc/host.conf), and I believe the network
mask may be a name that can be resolved by a lookup into
/etc/networks. On a sample system,
/etc/sliphome/slip.hosts looks like
this:
#
# login local-addr remote-addr mask opt1 opt2
# (normal,compress,noicmp)
#
Shelmerg dc-slip sl-helmerg 0xfffffc00 autocompAt the end of the line is one or more of the options. — no header
compression — compress
headers — compress
headers if the remote end allows it — disable ICMP
packets (so any “ping” packets will be dropped instead
of using up your bandwidth)Note that sliplogin under
early releases of FreeBSD 2 ignored the options that FreeBSD 1.x
recognized, so the options ,
, , and
had no effect until support was
added in FreeBSD 2.2 (unless your
slip.login script included code to make use
of the flags).Your choice of local and remote addresses for your SLIP
links depends on whether you are going to dedicate a TCP/IP
subnet or if you are going to use “proxy ARP” on your SLIP
server (it is not “true” proxy ARP, but that is the
terminology used in this document to describe it). If you are
not sure which method to select or how to assign IP addresses,
please refer to the TCP/IP books referenced in the section
and/or consult your IP network manager.If you are going to use a separate subnet for your SLIP
clients, you will need to allocate the subnet number out of your
assigned IP network number and assign each of your SLIP client's
IP numbers out of that subnet. Then, you will probably either
need to configure a static route to the SLIP subnet via your
SLIP server on your nearest IP router, or install gated on your FreeBSD SLIP server and
configure it to talk the appropriate routing protocols to your
other routers to inform them about your SLIP server's route to
the SLIP subnet.Otherwise, if you will use the “proxy ARP” method, you
will need to assign your SLIP client's IP addresses out of your
SLIP server's Ethernet subnet, and you will also need to adjust
your /etc/sliphome/slip.login and
/etc/sliphome/slip.logout scripts to use
arp8 to manage the proxy-ARP entries in the
SLIP server's ARP table.<filename>slip.login</filename> ConfigurationThe typical /etc/sliphome/slip.login
file looks like this:
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# generic login file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 inet $4 $5 netmask $6This slip.login file merely ifconfig's
the appropriate SLIP interface with the local and remote
addresses and network mask of the SLIP interface.If you have decided to use the “proxy ARP” method (instead
of using a separate subnet for your SLIP clients), your
/etc/sliphome/slip.login file will need to
look something like this:
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# generic login file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 inet $4 $5 netmask $6
# Answer ARP requests for the SLIP client with our Ethernet addr
/usr/sbin/arp -s $5 00:11:22:33:44:55 pubThe additional line in this slip.login,
arp -s $5 00:11:22:33:44:55 pub, creates
an ARP entry in the SLIP server's ARP table. This ARP entry
causes the SLIP server to respond with the SLIP server's
Ethernet MAC address whenever a another IP node on the Ethernet
asks to speak to the SLIP client's IP address.When using the example above, be sure to replace the
Ethernet MAC address (00:11:22:33:44:55) with the MAC address of
your system's Ethernet card, or your “proxy ARP” will
definitely not work! You can discover your SLIP server's
Ethernet MAC address by looking at the results of running
netstat -i; the second line of the output
should look something like:ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116
This indicates that this particular system's Ethernet MAC
address is 00:02:c1:28:5f:4a —
the periods in the Ethernet MAC address given by
netstat -i must be changed to colons and
leading zeros should be added to each single-digit hexadecimal
number to convert the address into the form that
arp8 desires; see the manual page on
arp8 for complete information on
usage.When you create
/etc/sliphome/slip.login and
/etc/sliphome/slip.logout, the
“execute” bit (ie, chmod 755
/etc/sliphome/slip.login
/etc/sliphome/slip.logout) must be set, or
sliplogin will be unable to execute
it.<filename>slip.logout</filename> Configuration/etc/sliphome/slip.logout is not
strictly needed (unless you are implementing “proxy ARP”), but
if you decide to create it, this is an example of a basic
slip.logout script:
#!/bin/sh -
#
# slip.logout
#
# logout file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 downIf you are using “proxy ARP”, you will want to have
/etc/sliphome/slip.logout remove the ARP
entry for the SLIP client:
#!/bin/sh -
#
# @(#)slip.logout
#
# logout file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 down
# Quit answering ARP requests for the SLIP client
/usr/sbin/arp -d $5The arp -d $5 removes the ARP entry
that the “proxy ARP” slip.login added
when the SLIP client logged in.It bears repeating: make sure
/etc/sliphome/slip.logout has the execute
bit set for after you create it (ie, chmod
755 /etc/sliphome/slip.logout).Routing ConsiderationsIf you are not using the “proxy ARP” method for routing
packets between your SLIP clients and the rest of your network
(and perhaps the Internet), you will probably either have to add
static routes to your closest default router(s) to route your SLIP
client subnet via your SLIP server, or you will probably need to
install and configure gated on your
FreeBSD SLIP server so that it will tell your routers via
appropriate routing protocols about your SLIP subnet.Static RoutesAdding static routes to your nearest default routers can be
troublesome (or impossible, if you do not have authority to do
so...). If you have a multiple-router network in your
organization, some routers, such as Cisco and Proteon, may not
only need to be configured with the static route to the SLIP
subnet, but also need to be told which static routes to tell
other routers about, so some expertise and
troubleshooting/tweaking may be necessary to get
static-route-based routing to work.Running <command>gated</command>An alternative to the headaches of static routes is to
install gated on your FreeBSD SLIP
server and configure it to use the appropriate routing protocols
(RIP/OSPF/BGP/EGP) to tell other routers about your SLIP subnet.
You can use gated from the
or retrieve and
build it yourself from the GateD anonymous ftp site; I believe the current version as of this writing is gated-R3_5Alpha_8.tar.Z, which includes support for FreeBSD “out-of-the-box”. Complete information and documentation on gated is available on the Web starting at the Merit GateD Consortium. Compile and install it, and then write a /etc/gated.conf file to configure your gated; here is a sample, similar to what the author used on a FreeBSD SLIP server:
#
# gated configuration file for dc.dsu.edu; for gated version 3.5alpha5
# Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface
#
#
# tracing options
#
traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ;
rip yes {
interface sl noripout noripin ;
interface ed ripin ripout version 1 ;
traceoptions route ;
} ;
#
# Turn on a bunch of tracing info for the interface to the kernel:
kernel {
traceoptions remnants request routes info interface ;
} ;
#
# Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP
#
export proto rip interface ed {
proto direct {
xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections
} ;
} ;
#
# Accept routes from RIP via ed Ethernet interfaces
import proto rip interface ed {
all ;
} ;The above sample gated.conf file
broadcasts routing information regarding the SLIP subnet
xxx.xxx.yy via RIP onto the
Ethernet; if you are using a different Ethernet driver than the
ed driver, you will need to change
the references to the ed interface
appropriately. This sample file also sets up tracing to
/var/tmp/gated.output for debugging
gated's activity; you can
certainly turn off the tracing options if gated works OK for you. You will need to
change the xxx.xxx.yy's into the
network address of your own SLIP subnet (be sure to change the
net mask in the proto direct
clause as well).When you get gated built and
installed and create a configuration file for it, you will need
to run gated in place of routed on your FreeBSD system; change the
routed/gated startup parameters in
/etc/netstart as appropriate for your
system. Please see the manual page for gated for information on gated's command-line parameters.AcknowledgmentsThanks to these people for comments and advice regarding this
tutorial:&a.wilko;Piero SeriniPiero@Strider.Inet.IT