- http://www.thoughtport.com:8080/PPP/
-
-Here are a few of the more common problems that this FAQ addresses:
-
-======================================================================
-1) pppd bombs out with an error similar to:
- Jan 26 14:46:25 localhost pppd[256]: Connected...
- Jan 26 14:46:26 localhost pppd[256]: ioctl(PPPIOCGUNIT): Inappropriate ioctl for device
- Jan 26 14:46:26 localhost pppd[256]: Exit.
-
-There are two things that can cause this error. The most common error
-is that you are using the innappropriate device for communication to
-your modem. You should be using /dev/cufa or /dev/cufb. Second, the
-Loadable Kernel Server (LKS) and the user level daemon (pppd) must be
-of the same version. While unusual, the error above can be the result
-of using the wrong Loadable Kernel Server (LKS) with pppd (or vice
-versa). Some versions of PPP installed the LKS (ppp_reloc) in
-/usr/lib/kern_loader/ppp and some in /usr/local/ppp/reloc. The second
-is going to be the standard place for installation from now on.
-
-Solution: Make sure that you are using the appropriate device for
-communications with your modem. Further, make sure that your
-/etc/rc.local is loading the correct version of the LKS and make sure
-you are really calling the correct pppd for use with the LKS that you
-loaded.
-======================================================================
-
-2) PPP works fine, but when the link is up, netinfo sleeps when you
- try to print or send mail.
-
-This problem is typically a result of an improper routing setup on the
-PPP client (your host). When PPP starts up, it will dynamically
-negotiate an IP address for use on the PPP interface (usually ppp0).
-If you don't specify an IP address to pppd, then the address will
-usually be provided by the peer. It may change each time that you
-bring up a PPP link. If you did specify an IP address, pppd will
-attempt to use that address first. If that fails, it will try to get
-an address from the peer. Either way, the PPP interface usually has a
-new IP address. The routing problem can result when trying to access
-your local host (and netinfo) on the IP address that was dynamically
-negotiated.
-
-Solution: The solution is straightforward. You must add a route from
-the IP address that your PPP interface uses to the special loopback IP
-address 127.0.0.1. The 'route' command will allow you to do this.
-For instance, if you are assigned the address 35.8.74.211 during PPP
-negotiation, you can add the needed route by\7fentering (as the user
-root):
-
- /usr/etc/route add 35.8.74.211 127.0.0.1 0
-
-This route needs to be added each time the link comes up. However,
-one problem with hard coding this command into /etc/ppp/ip-up is that
-you may get a different IP address each time the link comes
-up. Fortunately, Bill Bereza <berezaw@river.it.gvsu.edu> submitted
-this nice script clip that can be pasted into /etc/ppp/ip-up. This
-will create the correct route entry for you automatically. Place this
-in /etc/ppp/ip-up:
-
- /usr/etc/route add $4 127.0.0.1 0
-
-You will also want to add this little clip to /etc/ppp/ip-down: <br>
-
- /usr/etc/route delete $4 127.0.0.1
-
-This removes the route when your link goes down.
-
-======================================================================
-
-3) People who are trying to set up a NeXT as a PPP server that
- they dial into often complain that they can make a connection, but
- the remote machine can only ping the server. No other packets
- work.
-
-Check out the 'proxyarp' option to pppd. Servers (connected to their
-LAN) must proxyarp for the remote address (i.e. the address of the
-machine dialing in).
-
-======================================================================
-
-4) Your pppd/chat dials the modem but you cannot get a negotiation
- to start. The /usr/adm/ppp2.2.log file shows something similar
- to:
-
- Mar 13 12:02:41 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:02:44 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:02:47 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:02:51 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:02:54 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:02:57 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:03:00 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:03:03 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:03:06 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:03:09 crystal pppd[243]: sent [LCP ConfReq id=0x1 <pcomp> <accomp>]
- Mar 13 12:03:12 crystal pppd[243]: LCP: timeout sending Config-Requests
- Mar 13 12:03:12 crystal pppd[243]: Connection terminated.
- Mar 13 12:03:12 crystal pppd[243]: Serial link is not 8-bit clean:
- Mar 13 12:03:12 crystal pppd[243]: All received characters had bit 7 set to 0
-
-Discussion: This is a common problem. It is typically the result of a
-failure to properly start the remote PPP process. The problem arises
-since the local PPP starts sending packets as soon as chat
-exits. Since there is no remote PPP process running to interpret the
-packets, the remote command line interpreter starts sending error
-messages for each received packet (considered garbage to the remote
-CLI). Thus, your local PPP process is receiveing error message text
-instead of the expected PPP packets. Since error message text is
-usually ascii (values < 127) PPP believes that the link is not 8-bit
-clean.
-
-Solution: Make sure you add the '-v' option to chat (in your dial
-script) and then check the output of /usr/adm/ppp2.2.log to see why
-chat failed to start the remote PPP process.
-
-
-
-======================================================================
-
-5) NXHosting applications over PPP fails. I don't know why this
- happens. Rest assured, that I and others do have it working.
- The most obvious things to check are that you have your system set
- up as a public window server. Also, make sure that you reset the
- nmserver in /etc/ppp/ip-up (see the example ip-up file). If it
- still doesn't work, you might want to add your peer to your
- /etc/hosts.equiv file. I don't know if that has anything to do
- with it or not, but I don't know why some people can't NXHost
- and others can.