Re: Late to the party - multiple search domains on the network.
- From: Simon Kelley <simon thekelleys org uk>
- To: Dan Williams <dcbw redhat com>
- Cc: networkmanager-list gnome org
- Subject: Re: Late to the party - multiple search domains on the network.
- Date: Mon, 11 Apr 2005 16:29:09 +0100
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]