Date: Sun, 23 Apr 95 23:28:28 +0000 From: Andrew.Gordon@net-tel.co.uk To: amurai@spec.co.jp Cc: hackers@FreeBSD.org Subject: Re(2): IP problem with 950412-SNAP (and earlier -SNAPs) Message-ID: <"PC-950423232723-3424*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> In-Reply-To: <199504201443.XAA01201@tama.spec.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, I have now discovered the problem that was giving me my reboots (at least the ones concerned with IIJ PPP). Having found out what made it go bang, it then became obvious that my configuration was in fact wrong - though this does point up some issues in kernel packet routing and in the IIJPPP that probably want fixing. How to make it go bang ====================== This problem applies to any point-to-point interface - I have reproduced it with tun0 and ppp0. ifconfig tun0 1.2.3.4 5.6.7.8 # normally done for you by ppp route add default 1.2.3.4 # *WRONG* should be 4.5.6.7 ping 9.8.7.6 # any address with no specific route BOOM! What appears to be going on is that the local interface address of a point-to-point link is not considered valid when routing a packet (ie. unlike the ethernet interfaces, the point-to-point interfaces don't provide a loopback facility for their own interface address). However, the test for a legal destination for a default route allows either end of a point-to-point link to be specified and so the dud default route is allowed to be entered into the routing table. When a packet then comes along and tries to use the default route, the routing logic appears to go into <look up dest addr>, <not found so use default route as dest addr>, <look up dest addr> -> infinite recursion and crash. Problem 1 ========= It shouldn't be possible to add such an invalid default route. ifa_ifwithroute() in src/sys/net/route.c looks like the right place, but it is rather complicated already.... Problem 2 ========= Disaster shouldn't occur if the routing table does get screwed up (which it might otherwise do with redirects or interfaces disappearing). Probably easy enough to add some recursion control if only I could find where it was actually happening in the first place... Problem 3 ========= IIJ PPP really needs a better means of adding default routes. The reason my configuration was wrong in the first place was that my ISP assigns me a fixed IP address, but the address at their end varies according to which of their machines I dial into - so I set up the default route to my interface address (fixed) and let the address of the other end get negotiated by PPP. Manual dialling is no problem, since the script can contain "add 0 0 HISADDR", but the problem with dial-on-demand is that the default route must exist before the link is up (in order to get the packets to trigger the auto-dial), yet may need to change afterwards when the address at the far end has been negotiated. Either ppp needs to know all the routes that point at its interface (which might be network route(s) rather than a global default route), and delete/re-insert them once the address of the far end is known, or else the kernel restriction on routing to the local interface address needs to be relaxed (but what if you have multiple point-to-point links sharing the same address). I'm not sure if this problem explains all the wierd behaviour I was seeing - some of the unpredictability was caused by things like DNS caching leading to unexpected DNS traffic trying to use the defective route, but not the tcpdump/ipfw problems. Maybe they were unrelated bugs that have since been fixed (I can't now reproduce them on my test systems, and haven't yet dared upgrade my 'live' system to a more recent kernel, as it currently works if I don't touch it). Any thoughts on the above greatly appreciated. I can probably make some suitable changes to ppp to solve problem 3, but I'm not sure I understand the existing kernel routing code well enough to fix 1 and 2. Andrew. andrew.gordon@net-tel.co.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?"PC-950423232723-3424*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/">