User Tools

Site Tools


computing:dhcpcd

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
computing:dhcpcd [2026/09/07 16:26] oemb1905computing:dhcpcd [2026/09/07 17:01] (current) oemb1905
Line 78: Line 78:
 You can now reboot, restart each service and DNS is not altered, nor is the gateway. This only took about a year to figure out. It was much easier in isc-dhcp-client; you just prepended your DNS and removed domain-name-servers from the request block and done. Until today, I ran isc-dhcp-client as a temporary solution to avoid figuring this out. Glad it's sorted. Now I can benefit from fully modern Network Manager and logging in Cockpit. Along with custom vnet names, this allows for granular monitoring of vm/container traffic. Additionally, by DNS being unaltered, I can ensure that my hosts stay on the private subnet/vlan and route all traffic through the designate pihole+unbound. And, the vms/containers can tap the bridges and route via the segregated vlans/subnets without issue. Likewise, you can use these same strategies to make sure you don't get sideways traffic on any dual-NIC/purposed IoT devices you have. If you don't do this, Network Manager and dhcpcd will just make DNS and route choices for you and traffic will go wherever based on however it decides to prioritize your router advertisements. You can now reboot, restart each service and DNS is not altered, nor is the gateway. This only took about a year to figure out. It was much easier in isc-dhcp-client; you just prepended your DNS and removed domain-name-servers from the request block and done. Until today, I ran isc-dhcp-client as a temporary solution to avoid figuring this out. Glad it's sorted. Now I can benefit from fully modern Network Manager and logging in Cockpit. Along with custom vnet names, this allows for granular monitoring of vm/container traffic. Additionally, by DNS being unaltered, I can ensure that my hosts stay on the private subnet/vlan and route all traffic through the designate pihole+unbound. And, the vms/containers can tap the bridges and route via the segregated vlans/subnets without issue. Likewise, you can use these same strategies to make sure you don't get sideways traffic on any dual-NIC/purposed IoT devices you have. If you don't do this, Network Manager and dhcpcd will just make DNS and route choices for you and traffic will go wherever based on however it decides to prioritize your router advertisements.
  
- --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/09/07 16:03//+-------------------------------------------
  
 +=== Updates ===
 +
 +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:
 +
 +{{ :computing:screenshot_20260907_104547.png?direct&600 |}}
 +
 +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.
 +
 + --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/09/07 16:54//
computing/dhcpcd.1788798408.txt.gz · Last modified: by oemb1905