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
