James Coleman
b3dd8e8118
Setting DNS rewrote the connection profile and stopped there, so the running device kept resolving through whatever it had before. Nothing noticed while something else always activated the device afterwards: the profile was written first and NetworkManager picked the resolvers up when it got round to the interface on its own. Turning a DHCP client off now applies the profile when the device is not activated, which moved that activation ahead of the DNS write. A caller that sets an address, disables DHCP, and then sets resolvers -- the order a static configuration is naturally applied in -- ends with the device activated on a profile that had no DNS in it yet, and the write that follows never reaches the system. The profile carries the resolvers, resolv.conf carries none, and ipv4.ignore-auto-dns has by then ruled out the lease's resolvers as well: an interface holding an address, a route, and no way to resolve a name. Reapply the device after the change. Unlike turning a client off, this risks nothing for a caller connected over the interface -- reapply changes the device in place and does not tear the link down -- so it is not conditioned on the device being unactivated, which is exactly the case that needs it.
7 lines
579 B
Text
7 lines
579 B
Text
connection modify main ipv4.method manual ipv4.addresses 1.2.3.4/24,1.2.3.43/24 ipv4.gateway 1.2.3.1
|
|
connection modify main ipv6.method auto ipv6.addresses fc00::2/64 ipv6.gateway fc00::1
|
|
connection modify test ipv4.routes 10.253.2.0/24 203.0.113.22 100
|
|
connection modify test ipv6.routes abcd:ef12:3455:10::/64 abcd:ef12:3456:10::1 100
|
|
connection modify test_eth0 ipv4.dns 8.8.8.8,1.1.1.1 ipv4.dns-search example.com ipv4.ignore-auto-dns yes
|
|
connection modify test_eth0 ipv6.dns 2001:4860:4860::8888 ipv6.dns-search example.com ipv6.ignore-auto-dns yes
|
|
device reapply test_eth0
|