In T3493#189273, @Viacheslav wrote:

Does 1.5 has the same bug?

Does 1.5 has the same bug?

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

Done.
https://github.com/vyos/vyos-workflow-test-temp

In T5835#188611, @Viacheslav wrote:

I'd prefer to integrate the Port Control Protocol (PCP) instead.

In T5835#188605, @Viacheslav wrote:

You can still have it in a container easily; as I mentioned, it has never worked since 2021
You do not lose anything.

PR merged into vyos-utils:
https://github.com/vyos/vyos-utils/pull/20
and backported. The fix has been tested with migration from 1.3.x with settings as suggested by @trae32566

Yes, @c-po that would be a reasonable explanation; the timeout was added for Equuleus by 1.3.4. Without a reporting user to ask; other reports on later version; or further information, I would vote to close ...

https://github.com/vyos/vyos-1x/pull/3494

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

The argument would be to relax the url validator regex for compatibility with 1.3: since the plan is to replace this mechanism in 1.5 with something similar to @trae32566 suggestion above (brought up for discussion by @Viacheslav recently), and since it is deprecated/not advised anyway (RFC 3986). The simple change will be made to the validator.

https://github.com/vyos/vyos-1x/pull/3492

https://github.com/debiansid/nftables-fullcone

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

@jestabro It was a report from the user; unfortunately, I do not have more details.

I remember there was an ancient bug where the commit-archive rewrite did not come with a timeout. As routing might not have been converged during boot, that could explain the lock.

Naive attempts to reproduce on 1.3.3 are not successful, yet (Vmware; KVM), but will continue to investigate; any other information is welcome @Viacheslav, should you recall ...

https://github.com/vyos/vyos-1x/pull/3489

@jestabro This was the first of some issues I reported with migration to 1.4.0. The report is (with apologies) a bit vague as much did not work and it took more effort to identify the causes. It turned out to be a combination of things, of which T6131 was only part.

@matthewr Were all issues of this task resolved by the above discussions and the fix for T6131 ?

@jestabro could it be that the validator needs an update to allow special characters in the user/password field?
https://github.com/vyos/vyos-utils/blob/0d57cc9a266fe8d6fc87df5a769f42b4a45c7221/src/url.ml

It seems to work basically

Can you manually edit the node and re-check if it will work for acme

sudo nano -c /opt/vyatta/share/vyatta-cfg/templates/pki/certificate/node.tag/acme/listen-address/node.def

replace:

type: txt
help: Local IPv4 addresses to listen on
val_help: ipv4; IPv4 address to listen for incoming connections
allowed: sh -c "${vyos_completion_dir}/list_local_ips.sh --ipv4"
syntax:expression: exec "${vyos_libexec_dir}/validate-value  --exec \"${vyos_validators_dir}/ipv4-address \"  --value \'$VAR(@)\'"; "Invalid value"

to

type: txt
help: Local IPv4 addresses to listen on
val_help: ipv4; IPv4 address to listen for incoming connections

@Alfa80 this is actually the verbatim output of sudo wg show <interface>. I agree that it would sometimes be more intuitive to see the peers name