From owner-freebsd-questions Mon Mar 18 06:22:21 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA24138 for questions-outgoing; Mon, 18 Mar 1996 06:22:21 -0800 (PST) Received: from bsd.tseinc.com (bsd.tseinc.com [199.217.191.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA24133 for ; Mon, 18 Mar 1996 06:22:17 -0800 (PST) Received: from ws2.tseinc.com (ws2.tseinc.com [199.217.203.22]) by bsd.tseinc.com (8.6.12/8.6.12) with SMTP id IAA00291 for ; Mon, 18 Mar 1996 08:22:00 -0600 Date: Mon, 18 Mar 1996 08:22:00 -0600 Message-Id: <199603181422.IAA00291@bsd.tseinc.com> X-Sender: jlwest@bsd.tseinc.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-questions@freebsd.org From: "Jay L. West" Subject: Help!!! Severe PPP problems Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks a MILLION for all who have responded thus far. I missed some of the mail replies though. We upgraded to 2.1 this weekend and the major problem of the 'ppp -auto provider' grabbing the whole cpu seems to have disappeared. There is one other problem that remains and I have done a lot of work to isolate exactly what happens. Hopefully this will give particulars so others here may help. The last problem we're having is with iijppp and routes. FYI- we're running 2.1 on a 486dx4/100 with 16mb RAM. The machine has an ethernet card (ed0) for our local network of workstations (199.217.203). There is an ISDN iijppp connection to our upstream provider (199.217.191.65 -> 199.217.191.9). When an iijppp user dials in, the ips are assigned based on the tty device (199.217.203.40 (us) to 199.217.203.xx (them, range 41-48)). Gateway behavior (forwarding) is turned on. Here's my sysconfig, ppplogin script, ppp.conf, and ppp.linkup. The link to my provider is brought up via 'ppp -auto provider' and 'ping -c1 199.217.191.9' in /etc/netstart. Here's my /etc/sysconfig lines: network_interfaces="lo0 ed0 tun0" ifconfig_lo0="inet localhost" ifconfig_ed0="inet 199.217.203.1 netmask 0xffffff00" ifconfig_tun0="inet 199.217.191.65 199.217.191.9 netmask 0xffffff00" ---------------------------------------------------------------------- Here's my iijppp login script (dial up users have this as their login shell): /usr/sbin/ppp -direct `tty | cut -d/ -f3` ---------------------------------------------------------------------- Here's my /etc/ppp/ppp.conf file (phone number, id and password removed): default: disable lqr deny lqr set timeout 900 provider: set device /dev/cuaa1 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" set phone xxxxxxx set login "TIMEOUT 10 gin:-BREAK-gin: yyyyyy word: zzzzzzz" set timeout 0 set ifaddr 199.217.191.65 199.217.191.9 ttyd2: set ifaddr 199.217.203.40 199.217.203.41 255.255.255.0 ttyd3: set ifaddr 199.217.203.40 199.217.203.42 255.255.255.0 ttyd4: set ifaddr 199.217.203.40 199.217.203.43 255.255.255.0 ttyd5: set ifaddr 199.217.203.40 199.217.203.44 255.255.255.0 ttyd6: set ifaddr 199.217.203.40 199.217.203.45 255.255.255.0 ttyd7: set ifaddr 199.217.203.40 199.217.203.46 255.255.255.0 ttyd8: set ifaddr 199.217.203.40 199.217.203.47 255.255.255.0 ttyd9: set ifaddr 199.217.203.40 199.217.203.48 255.255.255.0 ---------------------------------------------------------------------- Here's my /etc/ppp/ppp.linkup file: provider: add 0 0 HISADDR ttyd2: ttyd3: ttyd4: ttyd5: ttyd6: ttyd7: ttyd8: ttyd9: ---------------------------------------------------------------------- Ok, with that out of the way, here's the problem... Before a dial in user connects (ie after a fresh boot) here's what my routing table looks like: bsd# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 199.217.191.9 UGc 20 210 tun0 127.0.0.1 127.0.0.1 UH 2 142 lo0 199.217.191.9 199.217.191.65 UH 21 1 tun0 199.217.191.65 127.0.0.1 UGHS 0 0 lo0 199.217.203 link#1 UC 0 0 199.217.203.22 0:c0:a8:28:63:8 UHLW 2 920 ed0 330 224 199.217.191.65 US 0 0 tun0 Note that 203.22 is just a workstation off the ed0. Now, when a user dials in here's the new routing table set up: bsd# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 199.217.191.9 UGc 20 210 tun0 127.0.0.1 127.0.0.1 UH 2 142 lo0 199.217.191.9 199.217.191.65 UH 21 1 tun0 199.217.191.65 127.0.0.1 UGHS 0 0 lo0 199.217.203 link#1 UC 0 0 199.217.203.22 0:c0:a8:28:63:8 UHLW 2 920 ed0 330 199.217.203.41 199.217.203.40 UH 1 24 tun1 224 199.217.191.65 US 0 0 tun0 This looks great. If the user disconnects normally, the .41 to .40 route disappears and all is well. However, if the user disconnects abnormally (ie, his system crashes or he just turns off his modem, or he disconnects while receiving data) the phone line hangs up but look at the resulting routing table: bsd# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 199.217.191.9 UGc 20 210 tun0 127.0.0.1 127.0.0.1 UH 2 142 lo0 199.217.191.9 199.217.191.65 UH 21 1 tun0 199.217.191.65 127.0.0.1 UGHS 0 0 lo0 199.217.203 link#1 UC 0 0 199.217.203.22 0:c0:a8:28:63:8 UHLW 2 920 ed0 330 199.217.203.41 link#1 UHLW 1 24 224 199.217.191.65 US 0 0 tun0 Note the 203.40 has become link#1, the flags have changed from UH to UHLW, and the tunx device is gone. If a user dials back in on this port, the route stays as above and he can log in but not get out tun0 to the Inet. If I do a 'route delete 199.217.203.41' the route will disappear but will then suddenly re-appear about 30 seconds later (with no user dialing in at all). The only way I have found to correct this is to do a 'route 199.217.203.41 delete' exactly just before they dial in. Then the route gets added correctly and if they exit correctly it will disappear and stay gone. If users exit normally the above configuration works great. Incidentally, if I do a 'ping 199.217.203.99' (there's no such system on my class C) a link#1 route like above appears, but it disappears in a minute or so and stays gone. I'm not sure if this is related. Users who connect and disconnect normally work just great. I copied the above routing information 'after the fact' so the refs and use fields may not be exact but the rest is. In case it is germane, this system is running name services (primary for the tseinc.com domain, primary for the 199.217.203 in-addr.arpa net) and no routing protocols are being run. I hope this gives enough information for someone to help us out. Any input is MOST appreciated. THANKS! Jay L. West The Software Exchange, Inc. 1-800-669-8203