Rawhide NetworkManager

[Dan Williams]

On Tue, 2005-03-22 at 16:37 +0100, Nils Philippsen wrote:
> What are the specific reasons to use an internal DHCP client instead of
> e.g. dhclient -- with the latter, I could (and did) use custom
> configuration files (to request some no standard DHCP options) as well
> as exit hooks which determined which network I plugged into and set up
> some custom things according to that information (e.g. forwarders for
> privoxy, named (with a static resolv.conf), ...).

1) Better error detection.  Since DHCP is an integral part of the
connection process, we need to determine at least 3 states: a) success,
b) failure, c) timeout.  This is necessary for wireless connections,
where there is no way to determine whether or not your WEP key is wrong,
therefore we need fairly detailed transaction outcome information.  I've
since learned that some of this functionality is exposed via OMAPI, but
I'm unsure how much.

2) dhclient-script.  This stomps all over what NetworkManager is
supposed to do and is incompatible with NetworkManager.  Anything that
interfaced with NetworkManager would have to supercede dhclient-script
and pass information to NM if it were running.

3) Full access to DHCP options.  NetworkManager provides a DBUS API for
applications to access DHCP options returned by the server.  For
example, ntpd could listen to NetworkManager events and then restart
itself with the new server address without ever having to read a config
file.  xchat could listen to events and find out the corporate IRC
server to connect to without ever needing user intervention.  There's a
wealth of information passed along in DHCP options that applications can
use.  I'm unaware of any method that "dhclient" has that could provide
this information to NetworkManager.

In the ideal world, there would be a DBUS wrapper to dhclient that
exposed what was needed.  That wrapper could communicate with dhclient
through OMAPI, but it would be better to just make dhclient DBUS-aware
in the first place to cut down on the "hordes of daemons" syndrome.  In
this manner, dhclient could publish its own DHCP options interface and
NetworkManager wouldn't need to care about it.  NM would simply become a
dbus client of dhclient.

Part of the idea here is to NOT use the "hack tower of shell scripts"
that are (1) hard to upgrade, (2) hard to cleanly augment, and (3) quite
prone to error.  ie, touching resolv.conf from 5 different places, which
presumes that resolv.conf follows the same format all the time (it does
not).

Dan