Does defaultroute option work for pppoe?

Can someone please check if defaultroute option actually works for pppoe (might be ppp in general)?
based on wiki defaultroute should work and be set as 1 by default

if I ran

ps www | grep ppp

i clearly see it starting with nodefaultroute

also if i add defaultroute in pppd_options, pppoe refuses to even try to connect, it complains about defaultroute option (normal, after all defaultroute and nodefaultroute exclude each other)

apparently this commit;a=commit;h=d2212229078838fb244f65b6685d702a9f646d0d

made nodefaultroute more or less hardcoded

(I'm dealing with some weird issue between isp pppoe server/equipment and openwrt... Trust me you can't help me because I don't really have what logs to show you, it makes no sense.)

Yes it is working as expected. The nodefaultroute option is hardcoded and passed to pppd because we do not want pppd to install any kernel routes. Instead, the IPCP information is passed to ip-up [1] and ip6-up [2] scripts appended to the pppd command line [3] which submit the information to netifd which then takes care of programming the layer 3 address settings on the ppp interface device.


The decision whether to install or not install default routes is made in a protocol-agnostic manner in netifd C code here:;a=blob;f=interface-ip.c;h=c159e09133165aec461d34c8a42311d7f5e69bd3;hb=9932ed0220e7634d085a32cfd72fd3e25e1a1745#l715

When a route with prefix /0 is to be installed and when the interface option defaultroute is set to 0, the route will be filtered.


Thanks for the answer. :slight_smile:

I will see what I can do. Debuging this only from my side, because isp is unwilling to help me, is not an easy task, not to mention that I'm dealing with multiple problems regarding pppoe and things got worst every time isp made changes (to it's internal route and when it added the cgn nat (that for some reasons sometimes doesn't trigger, sometimes i get real ipv4 ip)).

I got more help from a neighbour that let me see the logs on his router an use his connection for testing purposes than I got from my isp. The only difference is that i'm connected directly in the ont while he is connected in a managed switch and the switch is connected in the same ont as me.

L.E. #1: I think it's all about the pppoe options. Same router using stock doesn't show the behaviour I see with OpenWRT.

By looking in the stock firmware sources I see this line:

# Standard PPP options we always use
PPP_STD_OPTIONS="$PLUGIN_OPTS noipdefault noauth default-asyncmap $DEFAULTROUTE hide-password nodetach $PEERDNS mtu 1492 mru 1492 noaccomp nodeflate nopcomp novj novjccomp user $USER lcp-echo-interval $LCP_INTERVAL lcp-echo-failure $LCP_FAILURE $PPPD_EXTRA"

I will basicaly add all of them (the ones that can actually be used with OpenWRT) and see if it fixes the problem. I should because after all it's same client used in both cases, not same version but version shouldn't really have an impact.

My bet is it's either default-asyncmap or one of the no<compression> needed to fix the issues.

Anyway it has to be something changed on ISP side that doesn't play well with OpenWRT, because up to some moment it happy worked and bang from that moment issues showed up (it's close to 3 years of issues) even an OpenWRT version known to work without issues started to have them (I know for sure 14.07 didn't showed any problems but this also shows the same weird issues, yes I know it's an old version I just used it to figure out if some changes with OpenWRT are causing my issues, clearly not, and I removed the hardware because I doubt 3 routers and 2 lan cards are all broken...).

Gonna test... No clue when I will edit it again, in normal conditions I should manage to get 30+ days uptime.

I think it's rather better to share your actual problem in a new thread so people may be able to help you.