computing:dhcpcd
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| computing:dhcpcd [2026/09/07 16:47] – oemb1905 | computing:dhcpcd [2026/09/07 19:49] (current) – oemb1905 | ||
|---|---|---|---|
| Line 80: | Line 80: | ||
| ------------------------------------------- | ------------------------------------------- | ||
| - | === Updates | + | === Update |
| It is not enough to simply instruct dhcpcd to not set routes for the bridges, you also have to tell Network Manager the same. To do this, open nm-connection-editor and open the routes submenu in each bridge. Click both the options there for all the IoT or restricted bridges; leave the primary or private bridge untouched. Then, restart networking and NetworkManager and you should only see the default route for the private subnet/lan. Here is what that looks like: | It is not enough to simply instruct dhcpcd to not set routes for the bridges, you also have to tell Network Manager the same. To do this, open nm-connection-editor and open the routes submenu in each bridge. Click both the options there for all the IoT or restricted bridges; leave the primary or private bridge untouched. Then, restart networking and NetworkManager and you should only see the default route for the private subnet/lan. Here is what that looks like: | ||
| Line 86: | Line 86: | ||
| {{ : | {{ : | ||
| + | This worked flawlessly on two machines. However, one machine insisted on making routes no matter what I did. So, for that machine, I additionally stopped Network Manager from doing that using nmcli: | ||
| - | --- // | + | nmcli connection modify br1 ipv4.ignore-auto-routes yes ipv6.ignore-auto-routes yes |
| + | nmcli connection modify br2 ipv4.ignore-auto-routes yes ipv6.ignore-auto-routes yes | ||
| + | nmcli connection modify br3 ipv4.ignore-auto-routes yes ipv6.ignore-auto-routes yes | ||
| + | |||
| + | If you instead want the routes, but just don't want them to be default, then: | ||
| + | |||
| + | nmcli connection modify br1 ipv4.never-default yes ipv6.never-default yes | ||
| + | nmcli connection modify br2 ipv4.never-default yes ipv6.never-default yes | ||
| + | nmcli connection modify br3 ipv4.never-default yes ipv6.never-default yes | ||
| + | |||
| + | Just adapt this command to whatever your bridges are named. This final change took care of the most stubborn machine I had. | ||
| + | |||
| + | === Update to the Update === | ||
| + | |||
| + | As it turns out, the above commands were not the fix. The issue was in fact due to phantom route entries that Network Manager populated. In nm-connection-editor > bridges > ipv4 > routes, there were invalid ipv4 entries. After deleting those bogus entries and restarting both services, the phantom routes did not return. In short, make sure there are no entries other than ones you've created in that location! I have no idea where those came from and they were not on every box I updated. | ||
| + | |||
| + | --- // | ||
computing/dhcpcd.1788799658.txt.gz · Last modified: by oemb1905
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
