Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Apr 95 23:28:28 +0000
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: <>

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      # normally done for you by ppp
route add default          # *WRONG* should be
ping                       # any address with no specific route

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.


Want to link to this message? Use this URL: <"PC-950423232723-3424*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/">