- 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:
- daemon,local2.* /dev/console
- daemon,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 5". 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
-transmssion 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-activists PPP
-channel 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. You need to use the 'noipdefault'
-option to tell pppd to request the IP address from the remote host.
-
-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:/tmp:/etc/ppp/ppplogin
-Here the file /etc/ppp/ppplogin would be an executable script
-containing something like:
- #!/bin/sh
- exec /usr/etc/pppd passive :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 'passive' option (which is
-not required) just means that pppd will try to open negotiations when
-it starts, but if it receives no reply it will just wait silently.
-This is appropriate if the remote end might take some time before it's
-ready to negotiate. (Note that the meaning of the 'passive' option
-changed between ppp-1.3 and ppp-2.0.)
-
-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, with the /etc/ppp/ppplogin script containing
- #!/bin/sh
- exec /usr/etc/pppd passive proxyarp :192.1.2.23
-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.
-
-ADDING MORE PPP CHANNELS
-
-By default, Linux PPP comes with 4 kernel channels, which means that
-at most 4 simultaneous PPP sessions are possible. If you desire more
-such sessions (for example if you are serving many dialup lines), you
-can easily reconfigure the kernel to add new channels. There are two
-steps.
-
-First you need to edit the kernel file drivers/net/Space.c . As
-distributed, it contains a section that looks like this:
-
-#if defined(CONFIG_PPP)
-extern int ppp_init(struct device *);
-static struct device ppp3_dev = {
- "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, NEXT_DEV, ppp_init, };
-static struct device ppp2_dev = {
- "ppp2", 0x0, 0x0, 0x0, 0x0, 2, 0, 0, 0, 0, &ppp3_dev, ppp_init, };
-static struct device ppp1_dev = {
- "ppp1", 0x0, 0x0, 0x0, 0x0, 1, 0, 0, 0, 0, &ppp2_dev, ppp_init, };
-static struct device ppp0_dev = {
- "ppp0", 0x0, 0x0, 0x0, 0x0, 0, 0, 0, 0, 0, &ppp1_dev, ppp_init, };
-#undef NEXT_DEV
-#define NEXT_DEV (&ppp0_dev)
-#endif /* PPP */
-
-The pattern should be obvious. For more channels, you need to add
-more "static struct device pppN_dev" lines, changing the first, sixth
-and eleventh structure entries as appropriate. The highest numbered
-PPP device should have NEXT_DEV in its eleventh structure field, and
-you should change the ppp3_dev structure to have &ppp4_dev there
-instead.
-
-For example, to add 2 extra channels, you would have
-
-#if defined(CONFIG_PPP)
-extern int ppp_init(struct device *);
-static struct device ppp5_dev = {
- "ppp5", 0x0, 0x0, 0x0, 0x0, 5, 0, 0, 0, 0, NEXT_DEV, ppp_init, };
-static struct device ppp4_dev = {
- "ppp4", 0x0, 0x0, 0x0, 0x0, 4, 0, 0, 0, 0, &ppp5_dev, ppp_init, };
-static struct device ppp3_dev = {
- "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, &ppp4_dev, ppp_init, };
-... etc.
-
-Second, you need to change the line in ppp.h (in include/linux) to
-change the line that reads
-
-#define PPP_NRUNIT 4
-
-to show the new number of channels; in our case it would become
-
-#define PPP_NRUNIT 6
-
-Finally, recompile and reboot. The bootup message and the contents of
-/proc/net/dev should show the correct number of channels.
-
-CHANGES FROM LINUX PPP 0.1.x
-
-Linux PPP 0.1.x was based on the free PPP package PPP-1.3. Linux PPP
-0.2.1 is based on PPP-2.0.4. There have been some changes to the pppd
-options along with significant enhancements. You should read
-"RELNOTES" in the pppd directory for a description of the changes.
-
-Also, some options which were added to PPP-1.3 for the Linux version
-have now changed names:
- 'defroute' is now 'defaultroute'
- 'kerndebug' is now 'kdebug'
- 'dropdtr' is now 'modem'
-In addition, it is now necessary to use the 'noipdefault' option if
-you want to get the local IP address from the remote PPP server.
-
-CONCLUSION
-
-Good luck!
-
-Michael