In some cases, a container requires specific services (like mDNS) to be initiated, not just between containers. I hope this general case can also be addressed. Thank you.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Today
Yesterday
I did some testing with patch. Counters started working and I started to
get usage in freeradius interim accounting updates. But I also noticed
another issue if I kick a user using reset command all users are
disconnected. Tomorrow I will share stats as well and will do some more
testing. Idle timeout and session timout I will check these as well
tomorrow
added PR implementing option 2
Same bug, with a second cost beyond CPU/log noise, plus a tested workaround.
Tue, Oct 20
Confirmed issue and resolution using option 1 on 2026.10.20-0026-rolling release (manually edited geoip.py).
Tomorrow I will give it a try and update you.
PR https://github.com/vyos/vyos-build/pull/1331 but the fix for T9493 must be merged before. I can't create teh PR in the moment cause the PR number limit.
I reproduced this and tested Kea 3.2.1 on a rolling VM (2026.10.16-0024-rolling).
@saadinnocent909 there is no ISO or rolling image with the fix, the PR (https://github.com/accel-ppp/accel-ppp-ng/pull/42) is still in review. Here is a test build of the three changed files that you can put on an existing rolling system:
I reproduced this on a rolling VM and have a fix. I can not open a pull request for it: GitHub limits me to 5 open pull requests in vyos/vyos-1x and all 5 are in use. The commit is on my fork, anyone can take it as it is or I open the PR as soon as a slot is free:
can you share me patched iso or lates rolling release includes the PR ?
Two additions: how serious the open CVEs are, and a simpler way to get to 5.x through T7557.
I prepared this as a draft PR so that someone else can continue if needed: https://github.com/vyos/vyos-1x/pull/5585
I implemented option one with PR https://github.com/vyos/vyos-build/pull/1329
Summary of what I found, and a question on the direction.
@Viacheslaw I will take care. Can you assign it to me?
I think we are OK to use even pdns-recursor-5.4.6
Be sure that it fixes the issue, and feel free to add a PR with package build, you can find an example of build HAProxy
I can test
@saadinnocent909 can you test my PR in your environment?
Merged:
Mon, Oct 19
Thanks for doing the work to replicate the issue.
I was testing vyos as BNG for my network especially with vpp. But I faced same issue. I hope issue will be resolved soon
Reproduced on a VM (rolling, kernel 6.18.55-vyos) with the steps from the description:
I reproduced this on a VM with rolling (PowerDNS Recursor 4.8.8, pdns-recursor 4.8.8-1+deb12u1) and the cause is in the recursor, not in vyos-hostsd or the addNTA lines. The addNTA lines only set DNSSEC negative trust anchors, they do not take part in resolving names.
We do not have the iso flavor
vyos_bld@fae3ff9bbe25:/vyos/work/tmp/vyos-build$ sudo make iso ./build-vyos-image iso I: Checking if packages required for VyOS image build are installed I: using build flavors directory data/build-flavors E: Build flavor "iso" does not exist! make: *** [Makefile:39: iso] Error 1
I have created a PR for this
https://github.com/vyos/vyos-1x/pull/5561
- Same result: no stuck VLAN in any test, including 15 full-table bond rebuilds each. The PR defers the sync, because that also handles other VPP-side changes made during a resync, not only the MTU.
@a.kudientsov thanks for the detailed report and the reproducer. You wrote that you have local patches for both parts (skipping the drain in lcp_nl_pair_add_cb when
there is no socket, and the state sync during the resync window) that remove the stuck state in your tests.
I checked this against current rolling and the description matches what I see in the sources:
Because of that the fix belongs in FRR: batch a hard clear (BGP_CLEAR_SOFT_NONE) also when a family is given. Then clearing a group with a family filter is fast as well.
FRR issue: https://github.com/FRRouting/frr/issues/23771. I also opened a patch with a topotest: https://github.com/FRRouting/frr/pull/23779.
I looked at this in the FRR source (stable/10.5 and master, same code), and the cause is a bit wider than the ip token.