On Fri, Dec 04, 1998 at 01:27:57PM -0700, Chris Jones wrote:
> >>>>> "Ignatios" == Ignatios Souvatzis <is@jocelyn.rhein.de> writes:
> 
> >>  Nope, doesn't work.  I tried changing the netmask to
> >> 255.255.255.255 (which, in retrospect, seems like a very good
> >> idea), but I get the same symptoms:  If that route exists when
> >> cricket dials in, then pppd doesn't change it to point out the
> >> correct interface.
> 
> Ignatios> why does such a route ever exists? do you put the machine
> Ignatios> onto the Ethernet sometimes (in this case the route contains
> Ignatios> the link level address, replacing what was the arp cache in
> Ignatios> 4.3BSD) ?
> 
> The route gets cloned from the default route on fxp0, if I even ping
> cricket while ppp0 is down.  Because cricket's IP is 153.90.240.162,
> and the default route puts 153.90.240/24 on fxp0, the kernel believes
> cricket is on the local net.  So when I do *anything* that tries to
> get to cricket, and ppp0 is down, a route gets cloned that points to
> fxp0.
> 
> So, if anybody tries to access cricket from finn, when cricket isn't
> connected, then cricket will be unable to connect until finn is
> rebooted.  I don't think I can guarantee that nobody will ever try
> that.
> 
> Ignatios> The "proxyarp" parameter should handle this right. You'll
> Ignatios> need it anyway to make cricket visible on the Ethernet.
> 
> Yeah, it should.  I've already got that in my config, though.  When
> this route problem doesn't occur, proxyarp works just great.
> 
> In fact, proxyarp may make things worse.  Finn advertises (via ARP)
> that it's the place to send traffic designated for cricket.  So, if
> cricket connects to finn, and then sends out an HTTP request, and then
> disconnects, then the router on finn's ethernet will now have an ARP
> entry that points to finn.  So when the HTTP reply comes back, the
> router will forward it to finn, and finn will (probably; I haven't
> tested this) end up cloning that route entry on fxp0 again.

I must confess that I've never taken the route _down_ again when operating PPP.
But I've also never had problems to dial in, even on dial-in machines running
NetBSD. Hmmm... maybe you should delete the route in the welcom script (not
the IP-up script!), and let pppd create the right route and proxyarp?

	-is