PPP daemon do not resetting the default gateway

Woodsman · 12-05-2005, 07:22 PM

I'm using Slackware 10.2, KDE 3.4.3, PPP 2.4.4b1

I've run into an interesting problem. In /etc/rc.d/rc.inet.conf, if I set the GATEWAY variable, then when I dialup the PPP daemon fails to reset the default gateway in the routing table. The pppd option of defaultroute is set in the /etc/ppp/options config file.

If I disable the GATEWAY variable and restart the rc.inet scripts, or manually disable the default gateway in the routing table (route del default), then pppd correctly sets the default table.

I am unable to find any clues about this behavior. In my NT4 box I have no such problems seamlessly toggling between dialup and using a gateway. Therefore the problem seems localized to either the ppp daemon, Slackware, or how Slack builds the routing table.

I first noticed this problem using KPPP. I verified the defaultroute option was set in the /etc/ppp/options config file, but then I added that option in KPPP as well. No dice. I then dialed out with ppp-go. Same results, thus, the problem seems peculiar to the ppp daemon or how the routing table is configured. Regardless of what I try, the ppp daemon always fails to reset the routing table.

Your thoughts and ideas are appreciated!

gbonvehi · 12-05-2005, 07:49 PM

Well, maybe it was designed to behave that way. I haven't seen documentation about the behaviour the daemon will take when there's already a default route.
You could create try creating a file called /etc/ppp/ip-pre-up and try resseting the default gateway from there. It should be called before the interface goes up.

Woodsman · 12-05-2005, 08:18 PM

Quote:

You could create try creating a file called /etc/ppp/ip-pre-up and try resetting the default gateway from there. It should be called before the interface goes up.

I have already done something similar with scripts.

I now boot such that either of my two boxes can serve as a gateway, and as I write this I am using NT4 and Box 2 is my gateway. But when I dialup in Slack I wrote a script to forcibly remove the existing default gateway. Upon hanging up I then use another script to restore the other box as the default gateway. Since NT4 does this flawlessly without scripts I merely assumed I should experience the same in Slack. Scripts fix the problem and as you say, this might be by design. But still a frustrating PITA!

The odd thing is that, just like the Windows dialup tool, the KPPP dialer has an option to set the dialup server as the default gateway. But the problem seems to be the ppp daemon itself and not KPPP.

The logs show an entry that pppd is not replacing existing default route, but I don't know where else to look why pppd refuses to do this. This log entry seems to indicate that the defaultroute option is being acknowledged by pppd.

gbonvehi · 12-05-2005, 08:46 PM

If my C knowledge isn't wrong and the little look I took at pppd sources is correct, it seems it was designed to behave that way:

Code:

/********************************************************************
 *
 * defaultroute_exists - determine if there is a default route
 */

static int defaultroute_exists (struct rtentry *rt)

<SNIP>

/********************************************************************
 *
 * sifdefaultroute - assign a default route through the address given.
 */

int sifdefaultroute (int unit, u_int32_t ouraddr, u_int32_t gateway)
{
    struct rtentry rt;

    if (defaultroute_exists(&rt) && strcmp(rt.rt_dev, ifname) != 0) {
        if (rt.rt_flags & RTF_GATEWAY)
            error("not replacing existing default route via %I",
                  SIN_ADDR(rt.rt_gateway));
        else
            error("not replacing existing default route through %s",
                  rt.rt_dev);
        return 0;
    }

As you can see it won't change the default route if there's already one there.

Woodsman · 12-05-2005, 09:12 PM

Quote:

As you can see it won't change the default route if there's already one there.

Tyrants!

Woodsman · 12-15-2005, 10:38 AM

Possibly I'm missing the big picture, but how can I create the ppp0 device without actually dialing out?

As noted in this discussion, the ppp daemon is designed intentionally not to override an existing default network routing path. However, hopefully one way around this is to add the ppp0 device to the routing list with a metric weight of zero. The new Slack rc scripts adds the eth0 device with a metric weight of one. Thus, with a metric weight of zero the ppp0 device becomes the default routing path but if unavailable the device with the next metric weight would be selected for routing. Therefore, during normal LAN operations the default route is eth0, but when the ppp0 device is activated that path is the default route and eth0 is ignored.

Unfortunately, one cannot manually add a device that does not exist and typically the ppp0 device does not exist until dialing out. How can I initialize/create the ppp0 device without actually dialing out---sort of placing the ppp0 device into standby mode until actually dialing out? Is this possible?

Any ideas?