readme.linux

unix and linux net driver

    daemon.*,kern.*				/dev/console
    daemon.*,kern.*				/usr/adm/ppplog

and HUP the syslog daemon as before.  Then, run pppd with the option
"kdebug 25".  Whatever characters arrive over the PPP terminal line
will appear in the debugging output.

Occasionally you may see a message like

   ppp_toss: tossing frame, reason = 4

The PPP code is throwing away a packet ("frame") from the remote
server because of a serial overrun.  This means your CPU isn't able to
read characters from the serial port as quickly as they arrive; the
best solution is to get a 16550A serial chip, which gives the CPU some
grace period.  Reasons other than 4 indicate other kinds of serial
errors, which should not occur.

During the initial connection sequence, you may see one or more
messages which indicate "bad fcs".  This refers to a checksum error in
a received PPP frame, and usually occurs at the start of a session
when the peer system is sending some "text" messages, such as "hello
this is the XYZ company".  Messages of "bad fcs" once the link is
established and the routes have been added are not normal and indicate
transmission errors or noise on the telephone line.


IF IT STILL DOESN'T WORK (OR, BUG REPORTS)

If you're still having difficulty, send the linux-ppp list a bug
report. It is extremely important to include as much information as
possible; for example:

 - the version number of the kernel you are using
 - the version number of Linux PPP you are using
 - the exact command you use to start the PPP session
 - log output from a session run with the 'debug' option, captured
   using daemon.*,kern.* in your syslog.conf file
 - the type of PPP peer that you are connecting to (eg, Xyzzy Corp
   terminal server, Morningstar PPP software, etc)
 - the kind of connection you use (modem, hardwired, etc...)


DYNAMIC ADDRESS ASSIGNMENT

You can use Linux PPP with a PPP server which assigns a different IP
address every time you connect. This action is automatically performed
when you don't have a local IP address.

  pppd connect 'chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: whitewater' \
      /dev/cua1 38400 noipdefault debug crtscts modem defaultroute

The noipdefault, added to the above example, suppresses the attempts
of pppd to deduce its own IP address by looking it up in the
/etc/hosts file. Since the process does not have an IP address, one
will be assigned to it from the configuration file on the remote
system.

Sometimes you may get an error message like "Cannot assign requested
address" when you use a Linux client (for example, "talk").  This
happens when the IP address given in /etc/hosts for our hostname
differs from the IP address used by the PPP interface.  The solution
is to use ifconfig ppp0 to get the interface address and then edit
/etc/hosts appropriately.



SETTING UP A MACHINE FOR INCOMING PPP CONNECTIONS

Suppose you want to permit another machine to call yours up and start
a PPP session.  This is possible using Linux PPP.

One way is to create an account named, say, 'ppp', with the login
shell being a short script that starts pppd.  For example, the passwd
entry might look like this:

  ppp:(encrypted password):102:50:PPP client login:/home/ppp:/usr/sbin/pppd

In addition, you would edit the file ~ppp/.ppprc to have the following
pieces of information:

-detach
modem
crtscts
lock
:192.1.2.33

Here we will insist that the remote machine use IP address 192.1.2.33,
while the local PPP interface will use the IP address associated with
this machine's hostname in /etc/hosts.  The '-detach' option is required
for a server. It tells the pppd process not to terminate until the modem
is disconnected. Should it fork, the init process would restart the getty
process and the this would cause a severe conflict over the port.

The 'modem' option indicates that the connection is via a switched circuit
(using a modem) and that the pppd process should monitor the DCD signal
from the modem.

The 'crtscts' option tells the pppd process to use hardware RTS/CTS flow
control for the modem.

The 'lock' option tells pppd to lock the tty device. This will use the UUCP
style locking file in the lock directory.

This setup is sufficient if you just want to connect two machines so
that they can talk to one another.  If you want to use Linux PPP to
connect a single machine to an entire network, or to connect two
networks together, then you need to arrange for packets to be routed
from the networks to the PPP link.  Setting up a link between networks
is beyond the scope of this document; you should examine the routing
options in the manual page for pppd carefully and find out about
routed, etc.

Let's consider just the first case.  Suppose you have a Linux machine
attached to an Ethernet, and you want to allow its PPP peer to be able
to communicate with hosts on that Ethernet.  To do this, you should
have the remote machine use an IP address that would normally appear
to be on the local Ethernet segment and you should give the 'proxyarp'
option to pppd on the server.  Suppose, for example, we have this
setup:

 192.1.2.33                        192.1.2.17
+-----------+      PPP link       +----------+
| chelseapc | ------------------- |  billpc  |
+-----------+		          +----------+
                                        |           Ethernet 
                            ----------------------------------- 192.1.2.x 

Here the PPP and Ethernet interfaces of billpc will have IP address
192.1.2.17.  (It's OK for one or more PPP interfaces on a machine to
share an IP address with an Ethernet interface.)  There is an
appropriate entry in /etc/passwd on billpc to allow chelseapc to call
in. It will run pppd when the user signs on to the system and pppd will
take the options from the user option file.

In addition, you would edit the file ~ppp/.ppprc to have the following
piece of information:

-detach
modem
crtscts
lock
192.1.2.17:192.1.2.33
proxyarp

When the link comes up, pppd will enter a "proxy arp" entry for
chelseapc into the arp table on billpc.  What this means effectively
is that billpc will pretend to the other machines on the 192.1.2.x
Ethernet that its Ethernet interface is ALSO the interface for
chelseapc (192.1.2.33) as well as billpc (192.1.2.17).  In practice
this means that chelseapc can communicate just as if it was directly
connected to the Ethernet.



SETTING UP A MACHINE FOR INCOMING PPP CONNECTIONS WITH DYNAMIC IP

The use of dynamic IP assignments is not much different from that
using static IP addresses. Rather than putting the IP address into the
single file ~ppp/.ppprc, you would put the IP address for each of the
incoming terminals into the /etc/ppp/options.tty files. ('tty' is the
name of the tty device. For example /etc/ppp/options.ttyS0 is used for
the /dev/ttyS0 device.)

To each of the serial devices, you would attach a modem. To the
modems, attach the telephone lines. Place all of the telephone lines
into a hunt group so that the telephone system will select the
non-busy telephone and subsequently, the modem. By selecting the
modem, the user will select a tty device and the tty device will
select the IP address. Run a getty process against the tty device such
as /dev/ttyS0.

(The general consensus among the users is that you should *not* use
the agetty process to monitor a modem. Use either getty_ps' uugetty
process or mgetty from the mgetty+sendfax package.)


SECURITY CONCERNS ABOUT INCOMING PPP CONNECTIONS

The following security should be considered with the ppp connections.

1. Never put the pppd program file into the /etc/shells file. It is not
a legal shell for the general user. In addition, if the shell is missing
from the shells file, the ftpd process will not allow the user to access
the system via ftp. You would not want Joe Hacker using the ppp account
via ftp.

2. Ensure that the directory /etc/ppp is owned by 'root' and permits
write access only to the root user.

3. The files /etc/ppp/options must be owned by root and writable only
by root.

4. The files /etc/ppp/ip-up and /etc/ppp/ip-down will be executed by the
pppd process while it is root. Ensure that these files are writable only
from the root user.

5. If you use an incoming PPP connection, you should do the following as
the root user:

a) Invalidate the files for rhosts and forward
rm -f     ~ppp/.rhosts ~ppp/.forward
touch     ~ppp/.rhosts ~ppp/.forward
chmod 444 ~ppp/.rhosts ~ppp/.forward

b) Prevent users from sending mail to the user 'ppp'.

This is best performed by creating a system alias 'ppp' and have it
point to the name "THIS_USER_CANNOT_RECEIVE_MAIL". It has no special
meaning other than the obvious one.

For sendmail, the sequence is fairly easy. Edit the /etc/aliases file
and add the line:

ppp:THIS_USER_CANNOT_RECEIVE_MAIL

Then run the sendmail program with the option '-bi' to rebuild the
alias database.

c) Secure the ppp file properly.
chown root ~ppp/.ppprc
chmod 444  ~ppp/.ppprc

You may wish to extend the security by creating a group 'ppp' and putting
the ppp user into that group, along with the binaries for pppd and pppstats.
Then you may secure the binaries so that they are executable from the owner
(which should be root) and the group only. All other users would be denied
all access to the files and executables.

d) Prevent the motd file from being sent to the ppp user.
touch ~ppp/.hushlogin
chown root ~ppp/.hushlogin
chmod 444  ~ppp/.hushlogin


ADDITIONAL INFORMATION

Besides this document, additional information may be found in:

- The file README in the source package
- The PPP-HOWTO on sunsite.unc.edu
- The Net-2-HOWTO on sunsite.unc.edu
- The Network Administration Guide published by O'Rielly and Associates

Please consult these sources of information should you have questions
about the program. If you still can not find your answer then ask either
the usenet news groups or the mail list.



DIP SUPPORT

The dip program used by Linux is not directly supported by the PPP
package as such. Please don't ask the PPP porting group questions
about dip. It does work in two areas.

1. If you use it as a parameter to 'connect' then you can use the scripting
   language and establish the connection. You would use the standard set of
   PPP options.

2. dip-3.3.7m-uri and later versions support a 'mode ppp' function
   which will invoke the pppd program. That is all that it does. It will
   not pass any parameters to pppd other than its required '-detach' to
   allow dip to detect the normal termination of pppd.

   The following information comes from John Phillips in an article which he
   posted to comp.os.linux.setup.

Assuming that you already know how dip supports SLIP, these points 
are relative to a working SLIP set-up.

1.  You need dip-3.3.7m-uri, and, of course, PPP compiled into the
kernel.

2.  Make sure pppd is where dip thinks it is: /usr/lib/ppp/pppd, or 
make a link from there to where pppd really is.  (Or re-compile dip 
to tell it where pppd is on your system - see pathnames.h).

3.  The key differences between the dip script for PPP, compared to one 
for SLIP are:

    a.  Use "mode PPP" instead of "mode SLIP"

    b.  Don't set certain options such as mtu and default - these are set 
    by pppd from the file /etc/ppp/options.  Mine looks like this:

        crtscts
        modem
        defaultroute
        asyncmap 0x00000000
        mru 576
        mtu 576

    The actual parameters and values may depend on your IP supplier 
    and his set-up.

    c. Tell your IP supplier's start-up code to use ppp, not slip:  I
    use "send nolqm,idle=240\n" instead of "send slip,idle=240,mru=576\n" 
    at the "protocol: " prompt.  ("nolqm" asks for ppp without the line 
    quality monitoring protocol, which is not - I think - supported in 
    Linux PPP.)  This prompt may be different (or absent) with another 
    IP supplier.

    d. You don't need "get $local <name>", since the ppp protocol 
    negotiates this at start-up.  You still need "get $remote <name>".  
    (This may also vary with IP supplier - you may need to set some 
    more parameters in /etc/ppp/options to work with yours - see "man 
    pppd" for details of the options supported by pppd.)

4.  The dip script will exit after dialling and starting up pppd.  When 
ppp negotiation is completed and IP comes up, pppd runs /etc/ppp/ip-up.  
This file can contain things you want to run when the network comes up 
(e.g. running the mail queue).

5.  When IP goes down (e.g. after you close down the link with "dip -k"), 
pppd runs /etc/ppp/ip-down, which can contain things you want to do on 
close-down.



CONCLUSION

Good luck!

Al and Michael