It's worth adding the no-default-route to the dhcp-options and adding a line like
Sat, Sep 18
Wed, Sep 8
Mon, Aug 30
Aug 25 2021
I found a new and exciting way to break it though. And maybe what we were talking about in Slack will be able to correct some of this.
Looks good to me now
Aug 22 2021
Aug 18 2021
Definitely seems to me a op-mode command to trigger a container rebuild would be appropriate.
To wit, I already had this working with multiple networks (I had named them podman0/1/2/3/4/etc), but I wanted to simplify the initial PR here.
Network re-creates every time after reboot and gets configuration from "container network" section.
So there is podman decide how to name this network.
In a different case, it tried to create a network which already been created.
Aug 13 2021
Fixed by PR966
Aug 12 2021
Duplicate of T3499
It appears things are in such a state where that network doesn't actually exist:
To add to this, it looks like I'm not going to be able to get rid of that without rebooting:
Aug 11 2021
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: