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.