- User Since
- Sep 15 2018, 11:31 PM (150 w, 1 h)
Mar 2 2021
Feb 17 2021
Sorry. Yep. Can confirm, problem fixed.
Jan 2 2021
Just to add to the knowledge surrounding this issue...
Dec 31 2020
Nov 21 2020
Nov 13 2020
@c-po It was thought that possibly the nftables migration was doing something funny here because of the potential overlaps.
The check on DH length is backwards.
Nov 3 2020
@dmbaturin It should. It was vyos-hostsd and some of the rewrite to python that caused the issue initially.
This PR should fix this for now.
Duplicate of https://phabricator.vyos.net/T2465
Oct 25 2020
Oct 5 2020
Honestly it's not anything I've ever used. But from asking around some people still use it (not specifically in VyOS, just in general)
Oct 1 2020
This PR should correct it. Fortunately it appears that that this node was the only place this existed.
Sep 26 2020
That’s how it is now and it doesn’t work.
This is a problem again.
Sep 25 2020
PR should correct this
I think I know what's happening here.
Sep 16 2020
set interfaces bridge br0 member interface wlan0
Sep 11 2020
Aug 28 2020
Jul 14 2020
Jul 13 2020
Jul 5 2020
This PR should correct the issue.
It should. This should really be a non-breaking change as it's a fallback for something else that already exists in /etc/hosts.
Jul 4 2020
default as an IP address is in the end more useful then a resolved PTR
This also has a measurable impact on CPU. You can tell exactly when I applied the nsswitch.conf fix.
Jul 3 2020
To add to this, this link pointed me at the correct solution:
Jun 27 2020
Go for it. Just to confirm, this did work on the rolling from the 8th of this month, so it was something that got gobbled up in the rewrite.
Then I believe the best course of action is to restore that error condition, but have it reference the “alias” config then.
To add, maybe it's just the content of the error message that's misleading here if there other ways to do it. Or maybe the problem is that there are multiple ways to accomplish this
I guess there's two ways to approach it. This is the correct way:
This PR should correct.
Jun 19 2020
Jun 18 2020
Revising this since I nailed down the issue.
Jun 17 2020
Can confirm. This bug is corrected in the the latest rollings (for at least a month or more)
Jun 10 2020
Jun 9 2020
This one works good too
Seems like this might be VRF related
Jun 8 2020
Changed this around a bit to load the modules automatically if necessary. Only adds about half a second to initial execution
Jun 7 2020
Jun 4 2020
May 20 2020
This PR419 should take care of this and the parent task
No worries. I think I've got a simple fix for this. Just needed to step away for a bit
This is related to this change:
PR416 should be the real fix here and PR413 should be reverted.
May 19 2020
Yep. Confirmed, and that's the root issue here.
This PR should hopefully correct this.