Date: Tue, 20 May 1997 20:29:39 -0400 From: "Paul Missman" <missmanp@milo.cfw.com> To: <ops@dal.net>, <freebsd-doc@freebsd.org>, <freebsd-questions@freebsd.org> Cc: "Ron Perry" <hawk@cfw.com>, "Lori M. Snyder" <lorelei@cfw.com>, <webmaster@cfw.com>, <help@cfw.com> Subject: PPP support in FreeBSD Message-ID: <9705210026.AA32413@milo.cfw.com>
next in thread | raw e-mail | index | archive | help
(Note: If you don't care about freeBSD or PPP, you may skip this and go on to the next email in your inbox). :o) (Also note: This information applies to freeBSD version 2.2.1 and user mode PPP version 0.94.) This email has several purposes: 1. To provide an easy to use route to setting up PPP under freeBSD. 2. To thank everyone who has provided me with suggestions over the past couple of days. The reason for this is that I just spent most of my spare time for the last 4 days, trying to get PPP to function correctly on my freeBSD operating system. The debugging was complicated by the fact that: this is the first time I have installed PPP, I have an ethernet connected to the box also, making me unsure of some of the routes problems which crept in, and PPP can exhibit some not-so-nice behavior if you feed it incorrect information. I'll get into some of the possible problems at the end of this memo. Here is what I suggest that you do when setting up PPP under freeBSD for the first time: 1. If you can do without address resolution temporarily, go into /etc/host.conf and comment out the "bind" statement and other address resolution statements except for "hosts". Also, go into resolv.conf and comment out all the nameservers. You can add these back after you determine that PPP functions with your system. This will make debugging the system easier. 2. Add name and address information to /etc/hosts for a couple of machines you expect to see on the other side of the connection when it comes up. Short form names are a good idea here, as you may be typing these a lot during debugging if things don't go well. 3. Don't try to use a script for PPP to login the first time. Do it manually. 4. This all assumes that the "tun0" device is declared in the sysgen statements for the kernel. It is in the GENERIC kernel supplied with the system, so it should not be a problem. Also watch when your system boots, to make sure the modem is detected during the boot up device search. 5. The "tun0" device must be declared in the networks section of /etc/sysconfig, as outlined in the PPP section of the freeBSD handbook. ( One very good source of advise is this handbook and the PPP man pages.) 6. Input the following: ppp (issued at shell level, brings up user mode ppp) set device /dev/cuaax (where x is the number of the serial port, starting from 0 for sio0. Not needed if using the sio0 device.) disable pred1 deny pred1 (this turns off predictor 1 data compression, which not all gateways can accept. My ISP can't.) term (this puts you in manual mode with the modem) at (resets the modem, wait for "OK" to come back from the modem. If no OK, disconnect and phone line, wait a few seconds, reconnect phone line, and try again. If still no OK, reboot system.) atdtxxxxxxx (dials the ISP, xxxxxxx is the phone number. At this point, modem should dial and connect, and you should get login prompt.) login: xxxxxxxx (at prompt, input your userid.) password: yyyyyyyy (input your password) (now wait for PPP to connect, at which time the "ppp" will change to "PPP" in the ppp prompt. Then wait about 10-15 more seconds) show log (this should show network connection, ending with "myaddr" and "hisaddr" info. if no address yet, wait a few more seconds and input "show log" again. if address shows up as 0.0.0.0, the PPP negotiotion failed. on fail, type "close" and "bye" and try again from the top.) show routes (you should see the routes of "myaddr" and "hisaddr" in the routes table that were displayed in the step above) add 0 0 HISADDR (this should add the HISADDR IP number as the default route in the routing table, assuming, of course you want it as the default, which will be the case for most end users) show routes (check to see that the HISADDR IP number is now the default route in the routing table. if not, wait and do again) When the "hisaddr" IP number shows up as the default route, you should be all ready. At this point, bring up another virtual terminal, and try to ping "localhost", the IP corresponding to HISADDR, and other hosts on the other side of the net. If pings are not going through, do "netstat -i and netstat -r" to check the actual system routing table for the routes seen in "show routes" from PPP. Note: You must leave PPP up on the original terminal for the duration. I am working on a script which will look pretty much like what appears in the freeBSD handbook, which dials and becomes it's own task. I'll send this to cfw.com to publish on their website. Problems: These are some of the problems I experienced when trying to get PPP up and running: 1. The "tun0" device needed to be added to /etc/sysconfig, per instructions in the handbook. 2. PPP, if presented with a bad address, may hang the routing system for the entire OS. Symptoms of this are: No reporting by netstat -r or netstat -i for any interfaces in the system (netstat hangs) (aparently PPP locks the routing tables and does not release them). No successful pings to any host, including localhost. In this case, give PPP the "close" and "bye" commands. If you are lucky, this will release the routing table. If you are not lucky, you will have to reboot. 3. Nameserver connections may obscure debugging, which is why I suggested turning them off if possible for the first go-round. If all the above is successful, you may turn them back on, as described in the PPP section of the handbook. 4. Timeouts in the example script in the handbook were too short for protocol negotiation and testing at my ISP. 5. The /etc/ppp.linkup script aparently isn't called by PPP in manual mode. This should be made clear in the handbook and the man pages. 6. If PPP hangs, kill pid, kill -9 pid, and disconnecting the phone line for a few seconds may be used liberally. So, thanks to all who provided suggestions over the last several days. Some of them were good, some of them made the problems worse, but all contributed to my being able to lay out the steps above, which, I think, should guarantee a good connection, if one can be made at all. I'll send a script that works to www.cfw.com. In the meantime, I suggest that the freeBSD handbook folks might want to use some of the above material in the handbook, which I freely give them perrmission to do. Paul Missman (bits^ on DALnet)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9705210026.AA32413>