ppp
ppp copied to clipboard
ppp-project
defaultroute-metric doesn't add a new route even if metrics are different
I have the following default route :
default via 10.X.X.X dev enp2s0 proto static metric 50
I am trying to set up a second default route through ppp (version 2.4.9) with higher metric (300) using defaultroute and defaultroute-metric options.
Here are the options of pppd :
pppd options in effect:
debug # (from command line)
nodetach # (from command line)
dump # (from command line)
defaultroute-metric 300 # (from command line)
noauth # (from command line)
/dev/ttyUSB2 # (from command line)
230400 # (from command line)
lock # (from /etc/ppp/options)
connect ./chatscript.sh # (from command line)
xonxoff # (from command line)
modem # (from /etc/ppp/options)
asyncmap a0000 # (from /etc/ppp/options)
lcp-echo-failure 4 # (from /etc/ppp/options)
lcp-echo-interval 30 # (from /etc/ppp/options)
hide-password # (from /etc/ppp/options)
defaultroute # (from command line)
usepeerdns # (from command line)
192.168.1.2:192.168.1.1 # (from command line)
noipx # (from /etc/ppp/options)
But I get an error telling me it is trying to replace the default route :
Script ./chatscript.sh finished (pid 421), status = 0x0
Serial connection established.
using channel 34
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB2
rcvd [LCP ConfReq id=0x5c <asyncmap 0xa0000> <magic 0x36f6>]
sent [LCP ConfReq id=0x1 <asyncmap 0xa0000> <magic 0xb61544f6> <pcomp> <accomp>]
sent [LCP ConfAck id=0x5c <asyncmap 0xa0000> <magic 0x36f6>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0xa0000> <magic 0xb61544f6> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xb61544f6]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.1.2> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPV6CP ConfReq id=0x1 <addr fe80::e5cc:aece:d9bf:e2c1>]
rcvd [IPCP ConfReq id=0xce <addr 0.0.0.0>]
sent [IPCP ConfNak id=0xce <addr 192.168.1.1>]
rcvd [LCP EchoRep id=0x0 magic=0x36f6]
rcvd [LCP ProtRej id=0x33 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [LCP ProtRej id=0x33 80 57 01 01 00 0e 01 0a e5 cc ae ce d9 bf e2 c1]
Protocol-Reject for 'IPv6 Control Protocol' (0x8057) received
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 192.168.1.2> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
rcvd [IPCP ConfReq id=0xde <addr 192.168.1.1>]
sent [IPCP ConfAck id=0xde <addr 192.168.1.1>]
rcvd [IPCP ConfNak id=0x2 <ms-dns1 8.8.8.8> <ms-dns2 8.8.4.4>]
sent [IPCP ConfReq id=0x3 <addr 192.168.1.2> <ms-dns1 8.8.8.8> <ms-dns2 8.8.4.4>]
rcvd [IPCP ConfAck id=0x3 <addr 192.168.1.2> <ms-dns1 8.8.8.8> <ms-dns2 8.8.4.4>]
Script /etc/ppp/ip-pre-up started (pid 424)
Script /etc/ppp/ip-pre-up finished (pid 424), status = 0x0
not replacing default route to enp2s0 [10.X.X.X]
local IP address 192.168.1.2
remote IP address 192.168.1.1
primary DNS address 8.8.8.8
secondary DNS address 8.8.4.4
Script /etc/ppp/ip-up started (pid 427)
Script /etc/ppp/ip-up finished (pid 427), status = 0x0
Have I misunderstood the defaultroute-metric option?
I suppose it depends on what you are trying to achieve.
The message
not replacing default route to enp2s0 [10.X.X.X]
Is logged when a default route already exist, and you are trying to configure the default gateway, and the new gateway isn't the same as the old gateway. Have you tried adding the option "replacedefaultroute"? This would force replacing the default route regardless.
Again,
it would be helpful here if you provided some more context by providing more info on your environment and what you are trying to do. Think of it as I need to be able to setup a similar environment and reproduce the issue you are having.
Hello!
I don't want to replace the default route. I want to have a second one with a different metric which is what the option "defaultroute-metric" is for I believe.
From the man page :
defaultroute-metric Define the metric of the defaultroute and only add it if there is no other default route with the same metric. With the default value of -1, the route is only added if there is no default route at all.
The PPP interface is a satellite link (high delay, low bandwidth, high cost). I am trying to setup a "least-cost routing" system where going through Ethernet is the preferred option (metric 50) but if it goes down, I still want the PPP default route to exist as a fallback (with metric 300).
I am using pppd version 2.4.9 installed using apt in a docker container (base image python:3.10).
The docker container is launched using "--network host" and "--privileged" options.
Adding or removing routes is possible using ip-up/ip-down scripts but I was wondering why it didn't work using "defaultroute-metric" option.
I include replacedefaultroute in both my PPP configs, I do see a (harmless) error, but it does work:
May 11 09:55:40 clearfog pppd[8052]: replacing old default route to wan-xdsl [0.0.0.0]
May 11 09:55:40 clearfog pppd[8052]: del old default route ioctl(SIOCDELRT): No such process(3)
The routes do install:
root@clearfog:/etc/ppp/peers# ip route | grep default
default dev wan-gpon scope link metric 10
default dev wan-xdsl scope link metric 100
I can confirm the problem, we've run into this as well. Many of our setups have a primary fibre link using pppoe and then a backup LTE (separate router and we get DHCP from that), and if the fibre goes down whilst the LTE is up, when pppd restores it won't add default route even though the metrics are very explicitly set to different values.
@paulusmack, @enaess: Have you seen all comments? It is possible to look for a solution?
There are currently four options related to default routes:
defaultroute defaultroute-metric defaultroute6 replacedefaultroute
The description of defaulroute-metric clearly states:
"if there is no other default route with the same metric."
Looking at the "defaultroute_exists()" function it does indeed compare the metric, however, the invocation in sifdefaultroute() doesn't ask it to look at a specific metric.
Instead of passing -1 as the second argument unconditionally, should we not pass dfl_route_metric (+1 if dfl_route_metric >= 0) here? Ie,
dfl_route_metric < 0 ? -1 : dfl_route_metric + 1
As the second argument, or possibly just handle the +1 situation in defaultroute_exists function?
Oh, the reason for mentioning the whole lot of options is that v4 and v6 is again handled differently here ... should they be brought into alignment?
@ncopa, @rogers0, @sthibaul, @bootc, @rfc1036, @Firefishy, @madhatter0, @pali, @uschindler: What do you think?
IPv4 and IPv6 should work the same way. And I agree that the current behaviour is wrong, because if two routes have different metrics then they are different routes.
@apompee could you check that https://github.com/ppp-project/ppp/pull/472 fixes your case?
Thanks @rfc1036 and @sthibaul for your quick answer and the quick PR! Badly, I have not contacted you directly before...
@apompee, @jimdigriz: Can you test the @sthibaul PR?
@jimdigriz: Thanks for your answer, we wait a comeback from @apompee...
@ncopa, @rogers0, @sthibaul, @bootc, @rfc1036, @Firefishy, @madhatter0, @pali, @uschindler: What do you think?
Why did you mention me in this specific issue? I was active in early times regarding defaultroute6, because defaultroute6 is not recommended to be used, but it is VERY useful when you do NOT want the router advertisements to be used (as they are often broken by PPP providers: some do not send them at all, or only initially and never send them again).
I made some comments on the PR itself. The more I think about this both the existing as well as documented behaviour (which is in my opinion not well defined) is wrong. Do we discuss that on the PR or here?
@sthibaul @Neustradamus I just tried the PR and the second default route is now created properly with the specified metric.
@uschindler: I have added you because you have done a comment 2023-07-23 here:
- https://github.com/ppp-project/ppp/pull/77#issuecomment-1646957341
@jkroonza: Thanks for your comment, @sthibaul: What do you think?
@apompee: No problem, thanks for your test and your confirmation of success :)