In T3338#87652, @zsdc wrote:

Can you share details about your hypervisor and datasource? Also as the full Cloud-init log (/var/log/cloud-init.log)?

I believe this is the behavior in 1.2.6 aswell?
And I think its not even possible to reset one peer?
So, reset vpn ipsec-peer XXX is broken
as well as reset vpn ipsec-peer XXX tunnel YYY

If this package supports all existing setups and the GRE usecase I see no reason to not replace it. @basalblas PR is happily accepted.

Can you share details about your hypervisor and datasource? Also as the full Cloud-init log (/var/log/cloud-init.log)?
Either datasource generates a wrong config, either the format is not well described in the Cloud-init documentation - there noted that: "gateway: IPv4 address of the default gateway for this subnet". I more believe in the wrong documentation, but would be better to check.
Independently of this all, the situation is not good, because we need to verify values that put into config. So, this will be fixed in one or another way (proper adding or drop), when we figure out details.

So I'm unsure how to rewrite that in a clean way, and I would appreciate your and @c-po's opinions on the subject

dhcp-helper is working perfectly fine with GRE tunnels, see my feature request https://phabricator.vyos.net/T3340

Keep in mind you cannot run dhcp-helper and ISC DHCP server at the same time on a single router. The Vyos CLI should not allow this.

Well, they do work together.

In T2898#87573, @jack9603301 wrote:

@wsapplegate Have you finished a patch yet?

@c-po What do you think?

In T2898#80264, @c-po wrote:

That we can deal with later on when it‘s needed

Yep, got bitten by that too. It's due to some interface types being absent from src/validators/interface-name. Luckily, the solution is pretty easy, here's a patch which adds l2tpeth and friends to that validator:

@pasik I should have a fix committed soon; thanks for the report !

Good job debugging the issue @varesa and @jestabro ! It looks like the actual cause for the deadlock was found already..

This actually has nothing to do with the http api, but rather is a deadlock coming from ConfigSession show_config(), namely, the use of Popen.wait() in __run_command().

This issue has been fixed in this commit: https://github.com/vyos/vyos-1x/commit/0fb5cc02c6c16ef410c1b1f746c1fbfbc40a0da0

@dmbaturin @zsdc Perhaps we could discuss the possibility of changing the dhcp(v6) server to a better server (and what feature changes might exist), which I hope will address the older ISC's better support for interfaces such as PPPOE and the latest dhcp(v6) standard

DHCPd shold be vonsistent for both v4 and v6 - running different daemons is simply bad.

GDB however tells a different story:

vyos@vyos# ps aux | grep cli
root      1624  0.1  1.9  35212 19508 ?        S    12:11   0:00 /bin/cli-shell-api showConfig
root      1684  0.0  0.5   9492  5720 ?        Ss   Feb16   0:00 /sbin/dhclient -4 -nw -cf /var/lib/dhcp/dhclient_eth0.conf -pf /var/lib/dhcp/dhclient_eth0.pid -lf /var/lib/dhcp/dhclient_eth0.leases eth0
vyos      2534  0.0  0.0   6084   892 pts/0    S+   12:22   0:00 grep cli

Seems like the issue manifests in cnode-algorithm.cpp:_diff_print_indent: