Do the default RA's need tweaking.

NogBadTheBad

@johnpoz said in Do the default RA's need tweaking.:

This redmine is related

https://redmine.pfsense.org/issues/11105

Ta John.

Hmmm, maybe it should be suppressed in the logs, its a bit misleading.

works as expected,
but now shows warning in routing.log:

routing.log:Mar 22 09:30:01 pf4 radvd[26608]: warning: (/var/etc/radvd.conf:24)
AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be deleted faster

jsmiddleton4

I'm seeing this in my log. Its a non-issue yes? Something fixed in 2.6?

areckethennu

@jsmiddleton4 It's odd that I'm seeing these in my logs as well. According to that redmine, it was closed and targeted for version 2.5.1. And, this:

https://redmine.pfsense.org/versions/61

says it actually was in 2.5.1 (if I'm reading that right). But, I'm on 2.5.2-RELEASE (amd64) and still seeing them.

surfcore

@areckethennu This is my first post on this site... not sure if it's kosher to respond to a thread this old rather than create a new topic but this isn't a new topic.

I've been using pfSense for about a year and decided recently to redo my install from scratch and watch the router logs from the onset to at least get a baseline.

I'm on 22.05 with a fresh installation and still getting the following message in my routing log:
warning: AdvDNSSLLifetime <= 2*MaxRtrAdvInterval would allow stale DNS suffixes to be deleted faster

It appears from looking at the redmine johnpoz referenced that this matter was closed with this log entry still being created. Is that the final status? Is there anything we should do with this or just ignore?

Updating stale DNS entries in a timely manner would seem to be important?

Should I attempt the config file update suggested in redmine - 11105)?
RDNSS 2001:470::1::3 2001:470::2::8 {
AdvRDNSSLifetime 3060
};

pst

@surfcore I see that the issue is still present in my logs for 23.05., The warning was noted already when the change was introduced (see https://redmine.pfsense.org/issues/11105#note-9) but does not appear to be worked on since.

I have prepared a change to have AdvRDNSSLifetime configurable in the GUI and it seems to be working as expected.

@johnpoz is it possible to reopen bug 11105 or should I raise another one?

johnpoz

@pst The way I read that redmine was the answer was WAD to be honest.

If you want to expose a gui entry for ravd to be able to set specific AdvRDNSSLifetime value, I would think that would be a feature request imho.

pst

Thanks @johnpoz After a bit more testing I have come to the conclusion that the RADVD warning is a red herring. It is most likely caused by RADVD not implementing RFC 8106. The boundry condition corresponds to RFC 6106 which is now obsolete.

Unless someone is desperate for GUI configuration of AdvRDNSSLifetime I won't be raising a feature request.

RobbieTT

@johnpoz Just masking out the warning from the logs would probably be enough to make this 'issue' go away.

It just adds noise and it isn't really an issue, let alone deserving of a 'warning'.

️

johnpoz

@RobbieTT said in Do the default RA's need tweaking.:

It just adds noise and it isn't really an issue, let alone deserving of a 'warning'.

I hear you and with you - log spam just makes logs harder to read for sure.. And lead to users going down a red herring rabbit hole all the time..

I would believe that log is part of the ravd package and prob not easy to manipulate not logging warnings.. If you can adjust that specific setting - no matter how useful or non useful it is to get the application not to make a fuss about it and create log spam, I would be all for it.

It doesn't bug me - not really looking in that log pretty much ever.. But it could be a handy feature to have to be able to adjust that and remove what seems like is spam in the log might be useful.

RobbieTT

@johnpoz said in Do the default RA's need tweaking.:

I would believe that log is part of the ravd package and prob not easy to manipulate not logging warnings.. If you can adjust that specific setting - no matter how useful or non useful it is to get the application not to make a fuss about it and create log spam, I would be all for it.

The ideal fix would be to correct the pfSense warning trigger to comply with the current RFC (ie 3 times the MaxRtrAdvInterval) rather than have radvd expect and issue a warning for 2 times the MaxRtrAdvInterval value.

pfSense is stuck in a bit of a rut. It calculates the values in accordance with the current RFC (default 600 seconds x 3 = 1800 seconds) but triggers the 'warning' for the old RFC calculation.

pfSense's version of radvd.conf itself includes a comment - Automatically Generated, do not edit so I am unsure what actually configures it and presumably a manual edit would not survive:

[23.05-RELEASE][admin@Router-8.redacted.me]/root: cat /var/etc/radvd.conf
# Automatically Generated, do not edit
# Generated for DHCPv6 Server lan
interface igc0 {
	AdvSendAdvert on;
	MinRtrAdvInterval 200;
	MaxRtrAdvInterval 600;
	AdvDefaultLifetime 1800;
	AdvLinkMTU 1500;
	AdvDefaultPreference medium;
	AdvManagedFlag off;
	AdvOtherConfigFlag on;
	prefix 2a02:red:acted:3::/64 {
		DeprecatePrefix on;
		AdvOnLink on;
		AdvAutonomous on;
		AdvValidLifetime 86400;
		AdvPreferredLifetime 14400;
	};
	route ::/0 {
		AdvRoutePreference medium;
		RemoveRoute on;
	};
	RDNSS 2a02:red:acted:3:red:acted:fe1b:70aa {
		AdvRDNSSLifetime 1800;
	};
	DNSSL redacted.me  {
		AdvDNSSLLifetime 1800;
	};
};

I'm still new to pfSense and feeling my way around but it looks like this contradiction was introduced into pfSense here:

Bug #11105

It was closed on Redmine but without resolving the warning issue or moving it to a new bug report.

With your thoughts on the difficulty on changing the fault mask, fixing the actual issue may be the easiest path?

️

pst

@RobbieTT If I understand the problem correctly, the configuration that pfSense generates is correct according to RFC 8106 but RADVD which is part of FreeBSD only complies with RFC 6106. The change should therefore be made in FreeBSD as it not a "pfSense issue" as such.

RobbieTT

@pst said in Do the default RA's need tweaking.:

@RobbieTT If I understand the problem correctly, the configuration that pfSense generates is correct according to RFC 8106 but RADVD which is part of FreeBSD only complies with RFC 6106. The change should therefore be made in FreeBSD as it not a "pfSense issue" as such.

I'm not versed in the ins and outs of pfSense vs FreeBSD vs Netgate's upstream revisions of FreeBSD. It is way-over my head.

[edit:] FreeBSD 14 and current pfSense use radvd v2.19 (ie the latest) so it should be fully compliant with the later RFC.

The warning though was triggered by a pfSense change, albeit with a laudable aim, as referenced earlier.

️

pst

@RobbieTT said in Do the default RA's need tweaking.:

[edit:] FreeBSD 14 and current pfSense use radvd v2.19 (ie the latest) so it should be fully compliant with the later RFC.

One could only wish that was the case, but checking the source code and change log (https://radvd.litech.org/) there is no mention of RFC 8106. Implementation of other RFCs are mentioned though.

The configuration parser is written in YACC but quite easy to understand (radvd-2.19/gram.y):

| T_AdvRDNSSLifetime number_or_infinity ';'
                {
                        if ($2 > 2*(iface->MaxRtrAdvInterval))
                                flog(LOG_WARNING, "warning: AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be d
eleted faster");
                        if ($2 < iface->MaxRtrAdvInterval && $2 != 0) {
                                flog(LOG_ERR, "AdvRDNSSLifetime must be at least MaxRtrAdvInterval");
                                rdnss->AdvRDNSSLifetime = iface->MaxRtrAdvInterval;
                        } else {
                                rdnss->AdvRDNSSLifetime = $2;
                        }
                        if ($2 > 2*(iface->MaxRtrAdvInterval))
                                flog(LOG_WARNING, "warning: (%s:%d) AdvRDNSSLifetime <= 2*MaxRtrAdvInterval would allow stale DNS servers to be deleted faster", filename, num_lines);

                        rdnss->AdvRDNSSLifetime = $2;
                }

As you can see, the warnings that we get are only FYI as no change of the specified values take place. The non-compliance in the current software version (2.19) with RFC 8106 would be if AdvRDNSSLifetime is < MaxRtrAdvInterval which is rejected but should be allowed according to RFC 8106.

I agree that the warning was triggered by the pfSense change but the alignment with RFC 8106 should be made in RADVD (IMHO).

RobbieTT

@pst The default and example configuration file in v2.19 use the later x3 standard. The example text included with pfSense also uses the factor 10 sec x 3 = 30 seconds.

Joined-up, it is not.

️

pst

@RobbieTT There has been a change submitted to RADVD which align it to RFC8106:

https://github.com/radvd-project/radvd/commit/17c43bff200bbc1d4786eb917860a79db4f95c2e

Hopefully that will trickle through the system and end up in a pfSense release, at some point.

RobbieTT

@pst said in Do the default RA's need tweaking.:

@RobbieTT There has been a change submitted to RADVD which align it to RFC8106:

Thanks for that, very helpful.

It shows as a committ and the issue marked as closed over 2 years ago. Do we know where the air gap is between the issue being resolved and where we are now with pfSense?

[To me it looks like radvd itself has not been touched in over 2 years, suggesting that this package is not being maintained.]

️

pst

@RobbieTT No decision about a RADVD 2.20 release has been made yet (as of this post's date anyway), but voices has been raised:

https://github.com/radvd-project/radvd/issues/185

I don't know how long it will take after the 2.20 release before it ends up in pfSense as it needs to be integrated into FreeBSD first (I guess).

RobbieTT

@pst Not looking good - the last question on 2.20 is asking if downstream users are now expected to build from git, rather than a [2.20] tagged release.

That was in January 2023.

Indeed, there have been no releases since the original package maintainer retired in Jan 2021.

️

bearhntr

@RobbieTT

Is there a way to fix this? Is there a set of instructions on fixing it? I am not super-Linux proficient, simple-is as simple-does.

I just going through some of these logs on my pfSense+ 23.05.1-RELEASE (amd64) - Just installed the latest this AM.

I am one of those who hates seeing errors and warnings. <grin>

RobbieTT

@bearhntr
I've no idea, sorry!

️