My question is, why is NM presuming to bypass the standard dhclient actions? There are other packages that have specifically been integrated with dhclient, and this integration is completely ignored when using NM. If the /sbin/dhclient-script default action is unsuitable, shouldn't we try to fix that - reducing complexity and divergence betwen the NM and non-NM use cases?
I ran into this bug when trying to figure out why my DHCP-provided WINS settings were not being recognized by my laptop. There are also hooks to tell the ntp package to use a local ntp server; a total of 7 different packages have hooks for this interface. The interface exists for a reason, it would be nice to not have to reimplement the axle.
Alexander,
My question is, why is NM presuming to bypass the standard dhclient actions? There are other packages that have specifically been integrated with dhclient, and this integration is completely ignored when using NM. If the /sbin/dhclient- script default action is unsuitable, shouldn't we try to fix that - reducing complexity and divergence betwen the NM and non-NM use cases?
I ran into this bug when trying to figure out why my DHCP-provided WINS settings were not being recognized by my laptop. There are also hooks to tell the ntp package to use a local ntp server; a total of 7 different packages have hooks for this interface. The interface exists for a reason, it would be nice to not have to reimplement the axle.