@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 ...

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.

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

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

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.

@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.

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

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:

@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.

@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.

Code commit here: https://github.com/sskaje/vyos-1x/tree/T4930

On hold befor the time we rework the op mode system not to use the old Vyatta's code at all

Tried to apply multi_to_list function to ConfigTree().to_json() but it works only for the full config or if pass the path.
The problem is described in the comment on closing the pull request: link. For now there is no way to pass the argument before the filter (json) to the function after the filter

Since Ipsec secrets al already maintaned in Json config that handle correctly quoting
Is still possible relax the check on the " (double quotes) and let him be saved and commited.
The check is also in commiting phase
I.e.

PR https://github.com/vyos/vyos-build/pull/839

The only piece remaining here is a backport for Equuleus.

This will have a simple solution as a corollary of the work T6718: put on hold for now, pending restatement in terms of that work.