Thank you for your work. I tried upgrading to the latest version 1.5-rolling-202411220007. After the upgrade, I still lost access to the LAN. However, after checking the logs, it seems that the previous exception has been fixed. There are just a few logs: Sending reply: error_code 1 with output. I'm not sure if this is a bug; could you please take a look?

As mentioned above, I'm not sure the Intel drivers actually support hardware flow table offload. I came across a thread on the netfilter development mailing list where the maintainer mentions that the driver needs to implement TC_SETUP_FT and that hw-tc-offload is not sufficient. The thread was discussing the igb driver for the Intel i350, but a cursory search of driver sources I only saw reference to TC_SETUP_FT in Mellanox and Mediatek drivers. It is entirely possible I'm missing something though.

Raised https://github.com/vyos/vyos.vyos/pull/365

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

So yes, that's the idea, and the tools are there for a simple implementation (done in May, rebased now for comparison):
https://github.com/vyos/vyos-1x/compare/current...jestabro:example-property-secret

@sarthurdev i think it can be good idea to those case , what do you think ? @dmbaturin @jestabro

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

Could nodes be flagged as sensitive in XML properties and that flag exposed to op-mode show scripts?

In T6691#207172, @MPStudyly wrote:

I've just encountered the same issue upgrading from a 1.5 build from May 2024 to the most recent a few days ago. Had very little time to investigate. Next week I'll take some more time and will report back if I find anything interesting.

This is mentioned in https://github.com/vyos/vyos-documentation/blob/current/docs/changelog/1.3.rst as a fix in upcoming 1.3.9 - but the backport https://github.com/vyos/vyos-1x/pull/3015 had conflicts and was closed.
So, just a question - what is really the status of this in equuleus?

@sarthurdev and need to be in 1.4?

@syncer The fix is present in rolling and circinus branches

@sarthurdev, does this require backporting?

Can be closed as resolved by above PR.

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

The first three PRs above have been merged, and the next in sequence (https://github.com/vyos/libvyosconfig/pull/21) opened for review.

T6899 merged; when rolling available, kindly retest. Thanks !

This will be squashed with https://vyos.dev/T6326 for backport to Circinus, after confirmation.

This will need the fix in https://vyos.dev/T6899 for backport to Circinus.

Issue present in 1.4.0 tested with Supermicro SOL on ttyS1.

Per slack, this is being investigated for re-introduction into 1.4.1. Putting this on pause for now.

It appears that path-limit GBP network options is deprecated

@Viacheslav @dmbaturin need to be fixed in 1.4.1

Confirmed this is happening with current mainline and 1.4, but not 1.2,1.3 or 1.5.

Needs testing

PR https://github.com/vyos/vyos-1x/pull/4198
Add base64 encrypted password

$ echo -n 1234567890 | base64
MTIzNDU2Nzg5MA==
$ 

Thanks @gadams , and yes that was also mentioned in the forum discussion here:
https://forum.vyos.io/t/vyos-sometimes-does-not-start-properly/15486
I believe the correction made in the PR for the parent task T6899 should help reveal/resolve the issue.

It's not just on upgrade; I'm seeing the same problem in a fresh installation of VyOS 1.5-rolling-202411190007:

Dear Viacheslav,
Glad to hear you.
I think Base64 is ok and is the right approach.

5 endpoints using domain, limit retry to 5 times, total start costs around 5 * 10 = 50 seconds.

@marco_agostani we do not have validators on the insert config step https://github.com/vyos/vyos-1x/blob/8f76c96cb4d7132b7654aa5f37e8ab49fa2e137a/interface-definitions/vpn_ipsec.xml.in#L35-L43
It is more of an interpreter issue/feature

The PR for the parent task:
https://vyos.dev/T6899
will avoid obscuring underlying errors. Revisit after merge of above.

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

Maybe it will be fixed after merging https://vyos.dev/T6045

In T4930#208083, @runar wrote:

Hi @sskaje!

In reference to T1700 and other tickets, there are things in wireguard that is not implemented the "best way".
For the first as noted earlier, the Wireguard kernel module have NO information of the existance of a "DNS peer", DNS to IP mappings are done by the wg config utillity at the moment the command is executed on the device.. this means that entering a DNS name as a peer address will execute a DNS request ONCE and its never retried .

In reference to T1700 and other tickets, there are things in wireguard that is not implemented the "best way".
For the first as noted earlier, the Wireguard kernel module have NO information of the existance of a "DNS peer", DNS to IP mappings are done by the wg config utillity at the moment the command is executed on the device.. this means that entering a DNS name as a peer address will execute a DNS request ONCE and its never retried .

I thought dns look up causes the block. So I made some changes like:

I did some investigation - apparently the plugin cannot match the full command pattern (including optional attributes) and silently refuses to generate a resultant set of commands - I will be looking into this - most likely the issue is related to rm_templates regex patterns for getval

@Viacheslav I made is based on T6490, PR here: https://github.com/vyos/vyos-1x/pull/4194
This PR makes peers no longer required, so WireGuard interfaces will be created on boot, with or without Internet connection, with or without DNS resolution.

Per slack conversation.

@sskaje, what would it be like without an internet connection while the system was loaded? And will the Internet be available 1-2 minutes after boot?
I think you will get the router without wireguard at all, as it was in the previous commits. It cannot resolve the address, so it cannot create a session. And it will be in this state until you reconfigure it again.