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

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

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 as the HTTP proxy


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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]