Hello from Grafana,

Nov 27 21:47:20 kernel: [STATE-POLICY-INV-A]IN= OUT=eth3 MAC=01:80:c2:00:00:00:60:be:b4:10:7a:6d:00:26
Nov 27 21:47:20 kernel: [STATE-POLICY-INV-A]IN= OUT=eth2 MAC=01:80:c2:00:00:00:60:be:b4:10:7a:6c:00:26

21:35:57.958675 60:be:b4:10:7a:6a > 01:80:c2:00:00:00, 802.3, length 38: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none], bridge-id 8000.52:37:9c:d2:22:eb.8001, length 35

this isthe invalid stp traffic log

Can you share logs for those entries?

Hi @n.fort
the error messages disappeared after manual add your command. there still has few stp traffic with same error

Can you check manually adding next rule?

I think it being called and centered around blacklisting is too specific. I'd be more inclined to see it as a firewall group, perhaps like the functionality of domain groups:

Example vyos config:

A lot of work was lost in mid of the year when my not pushed changes got lost due to a hardware failure.
So I had to do the work again.

Personally I would still prefer the later that is with DebianBanner no.

Had a look at this since it seems an easy task, but adding DebianBanner no only removes the Debian packages version string. As far as I can tell there is no way to remove the SSHd versiond used.

@daniil Any idea for CLI and what it should generate to strongswan.conf?
Which plugin should it use?
https://docs.strongswan.org/docs/5.9/plugins/plugins.html

eap-dynamic Plugin
eap-gtc Plugin
eap-radius Plugin
eap-simaka-sql Plugin
eap-tls Plugin

Nov 17, 2024

The PR# is re-submitted for review and testing

PR#358 merged

In T4930#208556, @Viacheslav wrote:

@runar btw, we have python script for the priority /usr/libexec/vyos/priority.py

@runar btw, we have python script for the priority /usr/libexec/vyos/priority.py

I don't agree with the 'refresh peer' idea in this script, it would ruin connections with peers with ddns. Also the $IP by digging, it's stupid and it can't handle any CNAMEs.

This script is handed over as an example for how it potentially can be done and not a "this is how you should do it", and yea there are potentials for improvement. but to call digging stupid is not correct in my mind, as it does exactly what its set to do.
as for the issue you noted that can be fixed by using tail -1 instead of head -1, that way you get the last element in the list, eg. the address that the cname points to.

In T4930#208505, @runar wrote:

Hi!

I do not like the concept that this should be done inline while in the middle of a commit.
As this will halt the commit phase for potentially a long time (relative) if dns is not up'n'running.
This in itself is not that critical, but if this is done the same on multiple sub-systems you potentially can have an exponentionall increase of boot time because of this.
And in a time where we are optimising milliseconds of code to get shorter boot and commit times in other subsystems i feel this is not the correct way to do it.

This task can remain closed - I have created a new task instead:

The new package exists at: https://github.com/vyos/vyos-build/tree/current/scripts/package-build/xen-guest-agent

I do not like the concept that this should be done inline while in the middle of a commit.
As this will halt the commit phase for potentially a long time (relative) if dns is not up'n'running.
This in itself is not that critical, but if this is done the same on multiple sub-systems you potentially can have an exponentionall increase of boot time because of this.
And in a time where we are optimising milliseconds of code to get shorter boot and commit times in other subsystems i feel this is not the correct way to do it.

I’d expect the behavior is correct now. There shouldn't be empty nodes. As some of them uses “default values” and system can see it as partly configured,
In any case the check is here https://github.com/vyos/vyos-1x/blob/ec18cc393591052fd1f021c4a62220ab2e537a2e/src/conf_mode/service_ntp.py#L68

Path issues and unit tests resolved

Sounds reasonable! I'm not going to worry about it any more, unless I see any further symptoms. Thanks a lot for the fix and taking the time to respond here!

https://github.com/vyos/vyos-1x/pull/4207

@gadams it may well have been the case that the fragile synchronization before the fix was in fact a cause of the problem, at least in some (all ?) cases. I expected however, that any other config error on boot could also trigger the complaint in vyos-configd, which would consequently drop any useful output. With the original change in T6326 and the fix in T6899, any output (error or otherwise) should now be robust and generally available (notably, through the http-api, which was the motivation to finally fix the output workaround for T6326).

To be clear, the clean-config boot hangs I was seeing were prior to this fix. Since the fix, I have yet to see the hang.

@gadams I agree with 2, as becomes apparent in the current situation: it is misleading and should be changed so as to avoid confusion. If you want to take it up, that would be great; thanks. Regarding 1, if you are seeing boot hangs on a system with the above fix, we will need to investigate: I have not encountered it, so I can try to reproduce with the following information: rolling version; sanitized config; platform (vm or hardware). I suggest opening as a separate task, as the forum reports so far (unless I'm mistaken) have pointed to this one. Thanks again for the info.

For the record, I am seeing the same thing with the same build (but different config commands, since this is a fresh installation, and there's not much in config.boot).

@opswill I suggest closing this task and opening a separate task focused on the specific continuing issue.

This is resolved for rolling, and not applicable to Circinus until backport of T6326.

PR https://github.com/vyos/vyos-1x/pull/4206

@opswill Yes, those debug messages report that vyos-configd is operating correctly: error_code 1 is 'success' in the enum list. Consequently, the obscuring error in vyos-configd has been resolved, and the root cause of your issue can now be investigated ...