Re: rtadvd appears to ignore options set in /etc/rtadvd.conf
- In reply to: Karl Denninger : "Re: rtadvd appears to ignore options set in /etc/rtadvd.conf"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 25 Jul 2025 01:41:36 UTC
The following handful-line patch (left the original assignments commented out) causes rtadvd to conform to the man page *except* you have to actually specify the interface to change pltime and vltime; doing so in "default" is not picked up. I initiated a bug report; is there a reason it shouldn't be this way considering the man page says it should work and as below as I describe there ARE circumstances where you really do want it to behave like this. diff --git a/usr.sbin/rtadvd/config.c b/usr.sbin/rtadvd/config.c index a264858edaf7..ade01e4d39f7 100644 --- a/usr.sbin/rtadvd/config.c +++ b/usr.sbin/rtadvd/config.c @@ -1092,8 +1092,13 @@ get_prefix(struct rainfo *rai) __func__, ntopbuf, pfx->pfx_prefixlen, ifi->ifi_ifname); /* set other fields with protocol defaults */ - pfx->pfx_validlifetime = DEF_ADVVALIDLIFETIME; - pfx->pfx_preflifetime = DEF_ADVPREFERREDLIFETIME; + int64_t val64; + MAYHAVE(val64, "vltime", DEF_ADVVALIDLIFETIME); + pfx->pfx_validlifetime = val64; +// pfx->pfx_validlifetime = DEF_ADVVALIDLIFETIME; + MAYHAVE(val64, "pltime", DEF_ADVPREFERREDLIFETIME); + pfx->pfx_preflifetime = val64; +// pfx->pfx_preflifetime = DEF_ADVPREFERREDLIFETIME; pfx->pfx_onlinkflg = 1; pfx->pfx_autoconfflg = 1; pfx->pfx_origin = PREFIX_FROM_KERNEL; On 7/24/2025 10:59, Karl Denninger wrote: > BTW the reason this behavior is definitely bad news is the following: > > Note that if the delegated address changes the host in question does > get it marked "deprecated" essentially immediately but it remains in > the address table for a very long time which is both pointless and, if > the delegated address changes on a relatively frequent basis (you'd > hope it doesn't but it might) you will wind up with a lot of > deprecated addresses. That's annoying but otherwise not a huge problem. > > HOWEVER, what is a significant problem is if IPv6 disappears (that is, > presume the gateway crashes or is rebooted and on restart fails to get > a new IPv6 delegation at all) -- since you can't set the shorter valid > time and have it work the system(s) that previously got those SLACC > addresses on your inside network will attempt to connect outbound on > them and fail since no further rtadvd updates will show up to tell the > box that the delegation and route has changed. This wildly damages > performance until said time expires, you reboot them or manually > remove the IPv6 SLACC address from the interface on each of those > devices -- and that potentially could be a very large number of devices. > > On 7/24/2025 07:47, Karl Denninger wrote: >> >> Nope -- no change: >> >> 07:44:23.810602 IP6 (hlim 255, next-header ICMPv6 (58) payload >> length: 56) fe80::2e0:b4ff:fe68:f895 > ff02::1: [icmp6 sum ok] ICMP6, >> router advertisement, length 56 >> hop limit 64, Flags [none], pref medium, router lifetime >> 1800s, reachable time 0ms, retrans timer 0ms >> source link-address option (1), length 8 (1): 00:e0:b4:68:f8:95 >> prefix info option (3), length 32 (4): >> 2606:83c0:8000:1b00::/64, Flags [onlink, auto], valid time 2592000s, >> pref. time 604800s >> >> Note that I cannot set an actual valid "address" in the config file >> since I have no clue what it is in advance (it comes off the >> delegation from the ISP of course) >> >> This looks like a bug (starting rtadvd with verbose debugging on in >> the foreground doesn't log any complaints -- it looks like it just >> ignores the parameters.) >> >> On 7/23/2025 23:26, John Hay wrote: >>> Hi Karl, >>> >>> What if you use a = instead of the #? For example :vltime=86400: >>> >>> I set rdnss and dnssl using = and that works. >>> >>> John >>> >>> >>> On Thu, 24 Jul 2025 at 01:38, Karl Denninger <karl@denninger.net> wrote: >>> >>> On 7/23/2025 16:47, Bjoern A. Zeeb wrote: >>>> On Wed, 23 Jul 2025, Karl Denninger wrote: >>>> >>>> Hi, >>>> >>>> (sorry I deleted the message as the tex/only part was barely >>>> parsable). >>>> >>>> Can you, for testing, try adding an >>>> addr="xxx:xxx:xxx:xxxx::":\ >>>> to one of your entries and see if the behaviour changes? >>>> >>>> /bz >>>> >>> root@IpGw:/etc # more /etc/rtadvd.conf >>> # Set the preferred lifetime to 10 minutes on advertised prefixes. >>> # All other parameters are default. >>> # >>> default:\ >>> :vltime#86400:\ >>> :pltime#3600:\ >>> :prefixlen#64:addr="xxx:xxx:xxx:xxxx::": >>> ix1:\ >>> :vltime#86400:\ >>> :pltime#3600:\ >>> :prefixlen#64:addr="xxx:xxx:xxx:xxxx::": >>> ix1.4:\ >>> :vltime#86400:\ >>> :pltime#3600:\ >>> :prefixlen#64: >>> >>> No change -- the announcement is going out on ix1 from the gateway. >>> >>> On machine receiving the advertisements: >>> >>> 19:35:49.085297 IP6 (hlim 255, next-header ICMPv6 (58) payload >>> length: 56) fe80::2e0:b4ff:fe68:f895 > ff02::1: [icmp6 sum ok] >>> ICMP6, router advertisement, length 56 >>> hop limit 64, Flags [none], pref medium, router lifetime >>> 1800s, reachable time 0ms, retrans timer 0ms >>> source link-address option (1), length 8 (1): >>> 00:e0:b4:68:f8:95 >>> prefix info option (3), length 32 (4): >>> 2606:83c0:8000:1b00::/64, Flags [onlink, auto], *_valid time >>> 2592000s, pref. time 604800s_* >>> >>> >>> -- >>> Karl Denninger >>> karl@denninger.net >>> /The Market Ticker/ >>> /[S/MIME encrypted email preferred]/ >>> >> -- >> Karl Denninger >> karl@denninger.net >> /The Market Ticker/ >> /[S/MIME encrypted email preferred]/ > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/