Re: Late to the party - multiple search domains on the network.

[Simon Kelley <simon thekelleys org uk>]

Dan Williams wrote:

> Well, in a NetworkManager world, NM controls the interface's address and
> up/down state, not the DHCP client.  Ideally, the DHCP client would
> simply publish that information via DBUS, and also a few assorted
> signals like:
>
> 1) DHCP transaction failed
> 2) DHCP Lease ended
> 3) DHCP rebind/renew completed
>
> etc, and NetworkManager (or _any_ client of the DHCP service) would do
> what it needed to with that information.  I guess that if you kept that
> logic in the DHCP client, NM would notice that the interface was down
> and simply reactivate it right away.

In principle, it's absolutely fine to give NetworkManager all the 
responsibility for changing the state of the interface. There are a 
couple of real life caveats that have to be thought about.

. The DHCP client needs the interface to be up during the configuration 
process so that it can send and receive packets. NM can't start with a 
downed interface and ask the DHCP client to get it an address.

. Hosts which obtain a DHCP lease are making a strong promise to the 
DHCP server that before the lease period expires, unless it's renewed, 
they _will_ stop using the lease address. It makes me happier if the 
DHCP client has sole responsibility for that - less to go wrong.

Of course, ceasing to use a leased address and downing the interface are 
two different things. Consider an interface which has two IP addresses, 
one from DHCP and one locally allocated. If the DHCP lease expires, it's 
necessary to remove the DHCP-allocated address, but the interface can 
stay up and continue to use the locally allocated address.

Probably the best approach would be that the DHCP client expects that 
the interface is up when it gets asked to obtain a lease, and just 
returns the address, without inserting it into the interface. If a DHCP 
lease expires without being renewed,  the DHCP client should remove the 
address from the interface (just to make _sure_ that it happened) and 
signal NM that the address is no longer valid.

> The problem I run into a lot is that too many other programs try to do
> too much, because nobody is thinking about the larger picture.  The
> dhclient scripts are a pile of crap right now because they try to do
> everything, which is one reason I didn't use dhclient in the first
> place.  Second, things like "nifd" send out interface up/down events,
> which is what NetworkManager also does.  Then we have things like
> "wpa_supplicant" that do their _own_ WEP key configuration, their own
> wireless scanning, their own interface up/down stuff.  Its all quite a
> mess.

Agree completely

> > Does that sound like it might be useful for networkmanager? I wouldn't 
> > expect you to commit to it ATM ("show us the code" and all that), but it 
> > will certainly happen, so you might want to bear it in mind. OTOH that 
> > might be the sort of thing Jason VasDias is doing with dhclient, so I 
> > could pick  up his work for the applications I have in mind.
>
>
> I think that it would be really, really, really great to standardize
> (more or less) on a DHCP service model using dbus that both dnsmasq and
> dhclient could provide.  That way, it wouldn't matter which client
> people used, and most DHCP clients provide the same information.  As
> soon as I can toss the internal dhcpcd to the dogs, I certainly will.

Small correction: this putative DHCP client isn't dnsmasq. It doesn't 
currently have a name.

Does NetworkManager have a model for network connection-related 
information? My take is that there should be a place on the D-bus where 
anything running on the host can come to find out the address of the DNS 
server, the NIS server, the NTP server, the HTTP proxy. All that 
information is available (or soon will be) via DHCP, and it should be 
possible to configure a machine to say

when connected via interface "foo" use 1.2.3.4 as the HTTP proxy

or

when connected via interface "foo" get the address via DHCP, and get the 
HTTP proxy address from the DHCP server.

The DHCP client will make that information available to NM, but the same 
sort of information might come from other places too (explicit 
configuration, in my first example, or a PPP connection) so it needs to 
be integrated by NM. There's also a need for callbacks, so if the HTTP 
proxy in use changes, the web-browser can be told.

> Thanks for the interest!  The more we can do with dbus and the less with
> hack-tower shell scripts, the better.

Strong agreement.


Cheers,

Simon.