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.

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.