- waddington:~$
-
-Try typing:
-
- netstat -nr
-
-This should show three routes, something like this:
-
-Kernel routing table
-Destination Gateway Genmask Flags Metric Ref Use Iface
-129.67.1.165 0.0.0.0 255.255.255.255 UH 0 0 6 ppp0
-127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
-0.0.0.0 129.67.1.165 0.0.0.0 UG 0 0 6298 ppp0
-
-If your output looks similar but doesn't have the destination 0.0.0.0
-line (which refers to the default route used for connections), you may
-have run pppd without the 'defaultroute' option.
-
-At this point you can try telnetting/ftping/fingering whereever you
-want, bearing in mind that you'll have to use numeric IP addresses
-unless you've set up your /etc/resolv.conf correctly.
-
-
-IF IT DOESN'T WORK
-
-If you don't seem to get a connection, the thing to do is to collect
-'debug' output from pppd. To do this, make sure you run pppd with the
-'debug' option, and put the following two lines in your
-/etc/syslog.conf file:
-
- local2.* /dev/console
- local2.* /usr/adm/ppplog
-
-This will cause pppd's messages to be written to the current virtual
-console and to the file /usr/adm/ppplog. Note that the left-hand
-field and the right-hand field must be separated by at least one TAB
-character. After modifying /etc/syslog.conf, you must execute the
-command 'kill -HUP <pid>' where <pid> is the process ID of the
-currently running syslogd process to cause it to re-read the
-configuration file.
-
-Some messages to look for:
- - "pppd[NNN]: Connected..." means that the "connect" script has
- completed successfully.
- - "pppd[NNN]: sent [LCP ConfReq"... means that pppd has attempted to
- begin negotiation with the remote end.
- - "pppd[NNN]: recv [LCP ConfReq"... means that pppd has received a
- negotiation frame from the remote end.
- - "pppd[NNN]: ipcp up" means that pppd has reached the point where
- it believes the link is ready for IP traffic to travel across it.
-
-If you never see a "recv" message then there may be serious problems
-with your link. (For example, the link may not be passing all 8
-bits.) If that's the case, it would be useful to collect a debug log
-which contains all the bytes being passed between your computer and
-the remote PPP server. To do this, alter your syslog.conf lines to
-look like this
-
- local2.*,kern.* /dev/console
- local2.*,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 local2.*,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.23
-
-Here we will insist that the remote machine use IP address 192.1.2.23,
-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.23 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.23
-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.23) 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
-only write access to the root user.
-
-3. The files /etc/ppp/options must be owned by root and accessible only
-from that user. Never permit any other user access to this file.
-
-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.
-
-
-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!