User Details
- User Since
- Jul 31 2022, 1:52 AM (121 w, 4 h)
Dec 22 2023
Jan 22 2023
There's already an open PR for the backport to 1.3 here: https://github.com/vyos/vyos-build/pull/265 which @c-po seems to have approved, should I close that PR in favor of the new one?
Dec 18 2022
Dec 17 2022
Dec 15 2022
Relevant PR:
@zsdc Yeah I see the bug now, I made the assumption that the config level by default was set to the bond (i.e. interfaces bonding bondX), good catch. Tested in a VM and I can confirm no regression in existing bonding behavior.
I couldn't find an effective way to get all the new members added to the bond via config at commit-time without comparing the members to the running/effective config (the function leaf_node_changed() only gets the removed interfaces). Not doing so either causes runtime commit failures (where the bond fails to add/remove members) or boot failures (where the bond fails to add all it's members on boot).
Dec 13 2022
@c-po While I was wrong about the MSS clamp not being applied, the missing clamp-mss-to-pmtu feature and the incorrect MSS limits are both still problems that PR 1557 addresses. I believe we can close this after those issues are addressed.
Nov 12 2022
I seem to have jumped the gun a bit as the issue seems to have been resolved via:
@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:
Nov 10 2022
Relevant PR:
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().
Nov 9 2022
@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:
Nov 5 2022
Relevant PRs:
Nov 3 2022
A patch to the WIDE DHCPv6 client seems to be sufficient to resolve this issue with respect to the way VyOS currently uses the daemon (one daemon per configured interface), PRs below:
Oct 19 2022
Oct 11 2022
Oct 4 2022
Sep 26 2022
It seems like I was wrong about the netfilter rule not working as intended (and in my testing the clamp was broken for some other reason that was an error on my part), the post has been edited to only indicate the remaining issue of an overly strict MSS clamping range.
Sep 24 2022
See https://unix.stackexchange.com/questions/672742/why-mss-clamping-in-iptables-nft-seems-to-take-no-effect-in-nftables for additional explanation why the iptables version do not work under iptables-nft.
Relevant PRs:
Sep 11 2022
Sep 10 2022
Sep 9 2022
Sep 6 2022
Sep 5 2022
The smoketest seems suspect, the error line has nothing to do with this issue and running the smoketest several times results in tests passing/failing arbitrarily on that line (across multiple tests).