@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

The biosdevname question is a matter for T5603; this task will be closed.

A version of this change will be part of T5528, only for Circinus initially.

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 :

@Viacheslav found the issue which I've documented below.

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.

The critical issue was addressed in T5520, and the matter avoided with the move to revised image tools. No more to do on this at this point, and will close.

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.

Since the task as worded is no actionable, I'm closing it as invalid. I'm not against using any tools that might help us, but we need to be sure what the task is (e.g., to implement regular scanning, or to fix specific suggestions from a scan...).

No urgency here, so moving out of LTS.

No simple solution, so it should be done and tested in a development release first in any case, not in LTS.

Moving to 1.5 for now. If we are confident about the solution, we can backport it to 1.4 later. New architectures certainly should be introduced in development releases first.

Since it's not really a trivial change, I'm moving this to 1.5 now. If we find a good solution and prove that it's perfectly safe, then we can backport it to 1.4 later.

Seems to work well enough in 1.4.0. If any issues turn up, we'll make separate tasks.

Removing from Sagitta, since we aren't changing any syntax within an LTS release.

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.

How about having a command on the primary router to trigger a save on the secondary router?

@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 child/related task T6300; 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 will not resolve the issue for earlier images, so a workaround is needed in those cases.

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.