The current PKI infrastructure already implements it.

Now that we have smoke tests for most things, it's time to declare the meta-task done I guess.

Both are present in 1.4.0 RCs.

I suppose we can call it complete — for the future high-level endpoints we have a separate task.

Marked this as resolved since the fix was merged and backported.

@jestabro I appreciate you looking into this. It does seem to be a timing issue. I checked on a few of my systems....it almost always does it in a VM on my slow server, but I have a faster mini-pc where it doesn't appear to happen as often, though it does still happen on some reboots. Now that I have done more testing, it does happen on 1.4-rc1 as well. It does not however happen in 1.3.5.

Moving to systemd-networkd on the long run seems like a very nice idea that I also had. For no and the 1.4 LTS release we will stick with a custom isc-dhcp-client package build

A general summary of the issue and proposed solution to avoid for future migrations has been added to subtask T5996, however even when implemented for 1.4 it will control, but not avoid, the problem when migrating from 1.3 --- short story: this is an incompatibility between the legacy and modern parser, and a need to refine the approach towards compatibility.

@L0crian there are no changes that would allow this in 1.4-rc1 and not 1.4-rc3 but, perhaps, for a matter of timing in bringing the interface up (see below), but if you confirm that is the case and can provide the container portion of your config, I can attempt a reproducer.

The examples in T5939 reveal a general issue that, although uncommon, needs to be rationalized. The modern parser requires single backslashes to be escaped, if in quoted strings, however (1) the legacy parser (unlike the modern parser) is inconsistent in quoting values (2) the existing solution escapes all single backslashes not a part of control sequences and makes no attempt to restore single backslashes when possible --- this is safe, but leads to redundant escaping of backslashes as revealed in the examples in T5939.

@Apachez, what exactly do you want to fix here?

The data channels are not established.
As I understand it, the problem is that the required related ports are not forwarded dynamically to translated address

As I understand changes as in this example
https://wiki.nftables.org/wiki-nftables/index.php/Conntrack_helpers

Sorry for the noise, but Is there any progress with this issue?

In T5376#176691, @Viacheslav wrote:

@svd135 Can you recheck?

This bug was fixed in https://vyos.dev/T5688

It is fixed.

The patch is btw here, in case anyone want to use it as inspiration: https://github.com/vyos/vyos-1x/compare/current...ichdasich:vyos-1x:bgp_large_community_validator_new

PR for 1.3 https://github.com/vyos/vyos-1x/pull/3010

PR for 1.5 https://github.com/vyos/vyos-1x/pull/2988

PRs for VyOS 1.3

• https://github.com/vyos/vyos-1x/pull/3007
• https://github.com/vyos/vyatta-cfg/pull/73

Smoketest conntrack fix https://github.com/vyos/vyos-1x/pull/3005