Add PR on accell-ppp repo or patch in the vyos-build via PR https://github.com/vyos/vyos-build/tree/current/packages/linux-kernel/patches/accel-ppp
There are no other options for review.

With latest nightly I am unable to use lldp with x710 Nic

vyos@vyos:~$ show version
Version:          VyOS 1.5-rolling-202407040020
Release train:    current
Release flavor:   generic

disable-fw-lldp is on

https://github.com/vyos/vyos-build/pull/686

We should backport https://github.com/net-snmp/net-snmp/pull/785/commits/f5ae6baf0018abda9dedc368fe6d52c0d7a8ab8f to our net-snmp version

I re-check this, and the problem still reproduces on the following versions:

CLI nodes already present under reset tree

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

This can be reproduced even without real hardware:

@a.apostoliuk if you accept the explanation above and the workaround suffices (as recently discussed), we will close this task.

Adding parent T6543 as contributing factor of issue in comment:
https://vyos.dev/T5991#178786

I've checked this bug , it's still present the vesion 1.4./1.5 and the 1.3.x , this problem is related to the update of the new version (openvpn) where the syntax to create a tunnel tap (layer2) is changed , this command allow to transport frame and it's needed when you want to bridge a vtun :

Spring cleaning PR:
https://github.com/vyos/vyos-1x/pull/3760

@Giggum The main reason for using ipaddrcheck is its speed (it's a compiled binary). Python is way too slow for validators due to the interpreter startup cost, so it's not an option until we completely overhaul the CLI backend. I'll look into the issue.

FRR issue is still open, no progress.

Since ISC DHCP relay agent is abandoned, I wonder if there are any chances of getting it fixed.

I agree with @Apachez: people should be able to disable IPv4 or IPv6 forwarding if they feel like it. For example, a router used exclusively as a looking glass or a load balancer arguably shouldn't forward any packets on L3.

I think it's not yet ready for PR - needs review by someone more experienced with accel-ppp internals.
Issue already reported there - https://github.com/accel-ppp/accel-ppp/issues/57
Isn't upstream effectively the same now (accel-ppp owned by VyOS)?
Some issues I reported in accel-ppp were moved to discussions but met with silence otherwise. It might (or not, I don't know) have to do with some personal disagreements - someone other than me might have better luck.

@marekm Can you add the PR to the accel-ppp repo? I guess it will be better to fix it in upstream.
https://github.com/accel-ppp/accel-ppp

Hello @dmbaturin - it's now about 2 years since I've discovered this bug, any chances to review my patch?
I don't claim it's 100% correct, in simple tests it does prevent LCP termination but the closing IPV6CP part (after "else") needs review by someone with better understanding of accel-ppp internals.
I still have a few users of these buggy routers in my network, can help with testing and possibly backporting the fix to Equuleus.
Thanks!

Added T5611 as parent task, as it is clearly the root cause from the description above. As mentioned in T5611 the workaround of saving the config on the source system is needed due to incompatibility of the legacy parser.

Added parent task T5611; the issue is explained in the above comment and in that task. As has been discussed, the easiest workaround is to save the config on the source image before migrating --- backporting the rewrite of vyatta_net_name/vyatta_interface_rescan to 1.3.x, as mentioned in T5611, will not resolve the issue for earlier images, so a workaround is needed in those cases.

As mentioned above, the main regression was fixed; as to the other issue of "‘show system image’ list may not reflect the actual default boot image" I was unable to reproduce originally, but likely fixed as well, as the regression in question corrupted the image list and annotations. Close as fixed; reopen as needed.