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.

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.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

IPoE server was rewritten to get_config_dict
The original bug was solved

@FileGo Could you re-check it with 1.4-rc3 or the latest rolling?
Not sure that we can fix anything in this specific case.

No responses from the author
I closed the task because we do not have other issues like this.
Feel free to reopen if it is required.

@dberlin Can you recheck?

@JonD Have you figured out what the problem is?

@pjeevarathinam Could you re-check wiht 1.4-rc3 or the latest rolling?
You can play with descriptions

vyos@r4# set system frr descriptors 
Possible completions:
   <1024-8192>          Number of file descriptors

I believe it was an issue with my DNS server. Nevertheless, the issue cannot be reproduced so the bug report can be closed.

@c-po in task T4797 (https://github.com/vyos/vyos-1x/pull/1648) you mentioned that the author should use the system task-scheduler feature.
I would understand this the same way as the author did:
The implementation of scheduling should be a module which could be reused by other features/extensions but the "cron" data should be stored separate from
what the user can schedule via the config.
But maybe you see it differently?

Honestly? Rather not. Even though i have been testing this extensively, there needs to be some discussion re: old-config-impact (+some testing); Similarly, _ideally_ this would not just go for standard python regex, but instead try to figure out what frr _acutally_ uses. So, while a poc, i think this needs a bit more work.

@tfiebig Could you add a PR?

@Apachez I would need this feature in another feature (https://vyos.dev/T6040) to avoid a double implementation.

PR https://github.com/vyos/vyos-1x/pull/3000

@greywolfe Any update?

@svd135 Can you recheck?

@twan Could you try with the 1.4-rc3 image?

@dcplaya provide the whole configuration to reproduce or close the task if the reason is firewall incorrect configuration.

PR https://github.com/vyos/vyos-1x/pull/2999

Not an issue on 1.5 with Kea.

PR: https://github.com/vyos/vyos-1x/pull/2997

This turns out to be non-trivial, due to the interaction between legacy and modern behavior; nonetheless, a simple preliminary fix is in testing, and the task will be updated with the details when the PR is complete.