Subject: Re: pppd's routes aren't getting created reliably
To: Chris Jones <firstname.lastname@example.org>
From: Ignatios Souvatzis <email@example.com>
Date: 12/04/1998 21:52:43
On Fri, Dec 04, 1998 at 01:27:57PM -0700, Chris Jones wrote:
> >>>>> "Ignatios" == Ignatios Souvatzis <firstname.lastname@example.org> 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 184.108.40.206,
> 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
> 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
> 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?