This document describes some of the common problems which users may encounter with their first use of PPP. It is a condensation of the development mail list problems and their corresponding solutions. Of course, your problem may not be listed. If you have a problem, then I usually frequent the usenet news groups, but I would prefer that you ask it on the mail list. Instructions for joining the mail list are in the README.linux file. -------- Q: I can't seem to leave that bloody mail list! A: This question is one of the most frequent problems. I realize that you would tend to get frustrated, but posting this type of message to the list will only make more enemies than friends. The instructions on how to quit are included if you ask the mail list -request address for 'help'. The major problem that most people find is that they send the leave request from one account and expect that the system will match their user name and quit them from a different account. This does not work. You must use exactly the same account, host name, and domain name. If you sent your subscription request from one host, such as plato, and you have now switched to a different host, cicero, then you must send the leave request from plato. The mail list software matches the From: name. It could care less about Reply-To:. It could care less about Sender:. It only matches the From: address. If this does not work, then the only human being in the world who can do anything about manually removing your address is arl@joker.cs.hut.fi. There is no one on the mail list who will be able to remove you. Repeated requests to the list will only get people mad at you. Send your requests to Arl. ------------ Q: I can reach the remote server, but I can not get anywhere else. A: Did you forget the 'defaultroute' parameter? This parameter adds a default route into your routing system so that frames to all other IP addresses will be sent to the PPP device. ------------- Q: I have a default route and I still can't get anywhere else! Now what? A: The problem then is not with the local Linux system. It most likely is routing problem on the remote end. (The remote end is also called the 'peer' system.) The remote computers need a route back to you just as you need a route to them. This may be accomplished by one of four methods. Each has advantages and limitations. You need to do one and only one of these. 1. Use a host route. At each host on the remote system, add a host route to your Linux IP address with the gateway being the terminal server that you use for your local access. This will work if you have a small number of host systems and a simple network without bridges, routers, gateways, etc. 2. Use a network route. Subdivide the remote IP addresses so that your local Linux IP address and the remote terminal server address and the remote terminal server's ethernet address is on the same IP domain. This will work if you have the IP addresses to spare. It will work very well if you have a Class-B IP domain and can afford to put the all of the remote addresses on the same IP domain. Then add a network route on each of the gateways and routers so that any address of the remote network is sent to the terminal server. Most configurations have many hosts but few routers. (We have over 300 host systems with only 3 routers.) 3. Use gated on all of the gateways and on the terminal server. This will cause the terminal server to broadcast to the gateways that it can accept the frames for your IP address. Since the hosts will have a default route to one of the gateways, the gateways will generate the ICMP re-direct frame and the specific host will automatically add its host route. 4. Use proxy ARP on the terminal server. This will only work if your Linux IP address matches the one of the IP domains of the network cards. There is no clear solution. You must choose one of these. -------------------- Q: I keep getting the message to the effect that the magic number is always NAKed. The system will not connect. A: There is a one in over four billion chance that the two systems have chosen the same magic number. If you get a continual failure about the magic number, the chances that this is a fluke will geometrically reduce. The most common reason for this failure is one of two conditions: 1. The modem has disconnected immediately upon making the connection and logging you on to the remote. Most modems are configured to echo the data sent to them and you are seeing the local echo from the modem. 2. The remote ppp software is not running when you think it is. Is the remote system configured to run PPP? Is the ppp process in the expected location? Is the privileges suitable so that you may run it? This would indicate that the shell is doing the local echo of the data. In either case, the Linux system is sending data to the remote which is being fed immediately back into the serial receiver. This is not an acceptable condition. You have what is called a "loop". -------------------- Q: I am trying to connect to a Netblazer and it terminates with a message "Could not determine local IP address". A: The Netblazer does not have your IP address. You do not have your IP address. You must have been given a piece of paper with your IP address written upon it. Use the local IP address and the remote IP address as a parameter to the pppd process. Use the pppd option format of: local_ip:remote_ip (That is the local IP address, a colon, and the remote IP address.) -------------------- Q: I am trying to connect to a Netblazer and it terminates with a message "Could not determine remote IP address". A: See above. -------------------- Q: I can not ping my local IP address A: You are not able to do this because you don't have a route to the address. This is the normal operating environment. Don't try to ping the local IP address. If you wish to ping your own system then use the loopback address of 127.0.0.1. -------------------- Q: Can I use the same local IP address for all of the lines of my PPP server? A: Yes. The local address is not significant to the local system. You must have a unique _remote_ IP address. The routing is performed based upon the remote IP address and not the local IP address. -------------------- Q: I am using a Xyplex terminal server and pppd complains about receiving a protocol reject for protocol fffb. What is this? A: The Xyplex terminal server is confused about Van Jacobson header compression. Use the pppd option "-vj" to disable the header compression. -------------------- Q: The connection fails with errors "ioctl(TIOCGETD): I/O error" or "ioctl(PPPIOCSINPSIG): I/O error". What now? A: Look at the boot messages when you boot the kernel. If it says "PPP version 0.1.2" then you have an old version of the ppp.c driver. If it says "PPP version 0.2.7" then you have the current driver, however, it was not built with the same set of defines for the ioctl numbers. Ensure that you have only one file called "ppp.h". It should be located in the kernel's include/linux directory. Once you have done this, rebuild the kernel and the pppd process. -------------------- Q: Sometimes the messages "ioctl(PPPIOCGDEBUG): I/O error", "ioctl(TIOCSETD): I/O error" and "ioctl(TIOCNXCL): I/O error" occur. Why? A: The remote system has disconnected the telephone. The tty drivers will re-establish the proper tty dicipline and these errors are the result of the pppd process trying to do the same thing. These are to be expected. -------------------- Q: I am trying to use the merit network. Why does this not connect? A: Some users of the merit network have indicated that it needs PAP. Did you try PAP authentication? -------------------- Q: My netstat says something other than the following. It may report the ppp device as "unknown" and show a strange hardware address. Is this important? ppp0 Link encap Point-Point Protocol inet addr 192.76.32.2 P-t-P 129.67.1.165 Mask 255.255.255.0 A: No. The information is for display purposes only. If you are using a recient 1.1 kernel then update the nettools package with the current one on sunacm.swan.ac.uk in the directory /pub/Linux/networking/nettools. -------------------- End.