Error also present in vyos-1.4-rolling-202212020318

The behaviour is quite different depending on what is done. In my case another API key (not the one my application uses) should be deleted and fails, the service restarts afterwards and the config is still the same. Is there something like a hot reload missing? Also, if the API-server dies without restart (had that case several times, would have to find out, which command does that) even a change using cli did not recover the service.

PR for 1.3
https://github.com/vyos/vyatta-op-vpn/pull/34
https://github.com/vyos/vyos-1x/pull/1672

I think the issue is realated to this: https://blog.ipspace.net/2014/09/ipv6-neighbor-discovery-nd-and.html

I add here what I just found and I can reproduce the issue everytime.

You can test with 3-5 servers, the config is basic for each server:

Could you provide config from several items?
How many nodes do we need to reproduce it?

In T973#137840, @elico wrote:

@Viacheslav I want to test this, what should be done?

@Viacheslav I want to test this, what should be done?

@rcit I can assure you were never planned to explicitly disallow embedded IPv4 notation. Moreover, I thought the current validator supports it, even though we didn't have tests for it. I'll take a look!

@c-po I think the reason you're seeing the old name of 'pdns-r/worker' is due to a packaging regression described in T4814. All the latest builds of vyos 1.4 seem to be providing powerdns 4.4 instead of the expected 4.8. Since this issue and corresponding bugfix only pertains to powerdns >= 4.8, the issue would not be visible if powerdns is downgraded to 4.4.

Just as a point of additional reference, I've bisected the PowerDNS source code to see where the change from 'pdns-r/worker' to something else occurred and successfully found that commit 69b39198 in the repository changes the thread names away from the prefix of 'pdns-r'. Since that change, the string pdns-r/ no longer exists in the source code. The aforementioned commit is included in the following tags:

Hmm, I can't seem to reproduce that name with "pdns-recursor/now 4.8.0~beta1-1pdns.bullseye amd64" or "pdns-recursor/now 4.8.0~beta2-1pdns.bullseye amd64" both in a live bare-metal system or in a VM. Both versions return pdns_recursor for me when printed from p.name(). The worker thread names (as listed from ps or htop) also don't match: "rec/web+stat" and "rec/taskThread", not that either of these are returned by p.name().

We use p.name from process_iter and it returns pdns-r/worker. That‘s why I have reverted the commits as in the latest 1.4 VyOS iso with PDNS 4.8 beta it‘s how they names the worker thread

@c-po I noticed you've reverted the commit, may I ask how you're able to reproduce the process name of 'pdns-r/worker'? Just doing the testing again with the latest build as of writing (vyos-1.4-rolling-202211060813-amd64.iso), I get:

@v.huti Thanks for investigating and testing! How about you create a PR with the patch against 1.3 / equuleus ?

Hi @zsdc! This seems to be related to T4028. The relevant commits are:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
commit 92980561382fc04380414a6e2f6ca6746c2fe5e9 ┃
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━━━
Author: Donald Sharp <sharpd@nvidia.com>
Date:   Mon Apr 19 19:23:45 2021 -0400

re-signed crux repo

Thanks for catching this

Relevant PRs:

Reopened, as this was never backported to 1.3; set for 1.3.3.

Adds firewall node rule N source/destination fqdn domain.com for single domains per rule and refactors resolver daemon.

Backport for VyOS 1.3.3 https://github.com/vyos/vyos-1x/pull/1629

Still on track for 1.4 ?

Any update on this, since it's been more than 2 years since the initial request? This would indeed be very useful for hairpin NAT. It it complicated to implement?

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

PR for VyOS 1.3 https://github.com/vyos/vyatta-cfg-system/pull/187

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

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

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

i dont know if this is good or not, next version of radvd will include options la RFC8781 which are not even though for frrouting, even im opening them a request for such feature but i dont expect it to be available anytime soon.