DNS problem (forwarding order?)

[David MacMahon]

I have Fedora Core 4 and NetworkManager installed.  When I use
NetworkManager I experience DNS problems that prevent me from using
NetworkManager on a regular basis.  Here are the details...

I am on a private network (10.12.0.0) with a DHCP server, a name server
(at 10.12.0.1) that maps names to the private IP addresses, and a
gateway (also at 10.12.0.1) out to the Internet.  My computer gets
assigned IP address 10.12.50.12.  The name server at 10.12.0.1 maps the
name "dhcp-10-12-50-12.dhcp.pvt" to the address 10.12.50.12.

Most of the time (when using NetworkManager), I am not able to do a
reverse lookup on my ip address, but sometimes I can.  It seems as if
the forwarders are not called in the given order.  For example, if I run
the following three commands repeatedly...

# service NetworkManager restart
# md5sum /etc/resolv.conf /var/named/data/NetworkManager-named.conf
# host 10.12.50.12

...I can tell from that the md5sums that the config files' contents do
not change from restart to restart, but the "host 10.12.50.12" command
sometimes fails and sometimes succeeds.  FWIW, forward lookups of names
on the private network (e.g. "dhcp-10-12-50-12.dhcp.pvt") also
fail/succeed in the same way.  The command "host 10.12.50.12 10.12.0.1"
always succeeds.

Here are the versions of NetworkManager and bind that I have installed...

# rpm -q NetworkManager bind
NetworkManager-0.4-18.FC4
bind-9.3.1-4

The NetworkManager-named.conf file that NetworkManager generates looks
like this (I've masked the ips of my external DNS servers)...

// Named configuration, generated by NetworkManager

options {
         directory "/";
         query-source address * port *;
         forward only;
         forwarders {  10.12.0.1; <ip of dns2>; <ip of dns3>; };
         listen-on  { 127.0.0.1; };
         pid-file "/var/named/data/NetworkManager-pid-named";
};

// Disable rndc
controls { };

And the /etc/resolv.conf file looks like this...

; generated by NetworkManager, do not edit!

; Use a local caching nameserver controlled by NetworkManager

nameserver 127.0.0.1

If I change /etc/resolve.conf to...

nameserver 10.12.0.1
nameserver <ip of dns2>
nameserver <ip of dns3>

...then "host 10.12.50.12" always succeeds.  This leads me to believe
that the forwarders listed in the named.conf file are not always used in
the given order.

Is there anything I can do get DNS lookups to always work when using
NetworkManager?  As I mentioned above, this prevents me from using
NetworkManager.

Thanks for any insights,
Dave
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Thu, 2005-07-07 at 12:06 -0700, David MacMahon wrote:

> I have Fedora Core 4 and NetworkManager installed.  When I use
> NetworkManager I experience DNS problems that prevent me from using
> NetworkManager on a regular basis.  Here are the details...
>
> I am on a private network (10.12.0.0) with a DHCP server, a name server
> (at 10.12.0.1) that maps names to the private IP addresses, and a
> gateway (also at 10.12.0.1) out to the Internet.  My computer gets
> assigned IP address 10.12.50.12.  The name server at 10.12.0.1 maps the
> name "dhcp-10-12-50-12.dhcp.pvt" to the address 10.12.50.12.
>
> Most of the time (when using NetworkManager), I am not able to do a
> reverse lookup on my ip address, but sometimes I can.  It seems as if
> the forwarders are not called in the given order.  For example, if I run
> the following three commands repeatedly...
>
> # service NetworkManager restart
> # md5sum /etc/resolv.conf /var/named/data/NetworkManager-named.conf
> # host 10.12.50.12
>
> ...I can tell from that the md5sums that the config files' contents do
> not change from restart to restart, but the "host 10.12.50.12" command
> sometimes fails and sometimes succeeds.  FWIW, forward lookups of names
> on the private network (e.g. "dhcp-10-12-50-12.dhcp.pvt") also
> fail/succeed in the same way.  The command "host 10.12.50.12 10.12.0.1"
> always succeeds.
>
> Here are the versions of NetworkManager and bind that I have installed...
>
> # rpm -q NetworkManager bind
> NetworkManager-0.4-18.FC4
> bind-9.3.1-4
>
> The NetworkManager-named.conf file that NetworkManager generates looks
> like this (I've masked the ips of my external DNS servers)...
>
> // Named configuration, generated by NetworkManager
>
> options {
>          directory "/";
>          query-source address * port *;
>          forward only;
>          forwarders {  10.12.0.1; <ip of dns2>; <ip of dns3>; };
>          listen-on  { 127.0.0.1; };
>          pid-file "/var/named/data/NetworkManager-pid-named";
> };
>
> // Disable rndc
> controls { };
>
> And the /etc/resolv.conf file looks like this...
>
> ; generated by NetworkManager, do not edit!
>
> ; Use a local caching nameserver controlled by NetworkManager
>
> nameserver 127.0.0.1
>
> If I change /etc/resolve.conf to...
>
> nameserver 10.12.0.1
> nameserver <ip of dns2>
> nameserver <ip of dns3>
>
> ...then "host 10.12.50.12" always succeeds.  This leads me to believe
> that the forwarders listed in the named.conf file are not always used in
> the given order.
>
> Is there anything I can do get DNS lookups to always work when using
> NetworkManager?  As I mentioned above, this prevents me from using
> NetworkManager.

Can you file a bug with exactly this information against 'bind' in Red
Hat bugzilla?  This sounds like a caching nameserver problem more than a
NetworkManager one.  If you could add me to the CC-list of the bug that
would be great too.

Thanks!
Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[David MacMahon]

Dan Williams wrote:
> Can you file a bug with exactly this information against 'bind' in Red
> Hat bugzilla?  This sounds like a caching nameserver problem more than a
> NetworkManager one.  If you could add me to the CC-list of the bug that
> would be great too.

I'm reluctant to file a bug without first verifying that the forwarders
are in fact supposed to be called in order.  I've looked through the
copy of the BIND 9 Administrator's Reference Manual included with FC4,
but I couldn't find any explicit statement about whether forwarders MUST
be tried in the order given or MAY be tried in some arbitrary/random order.

Do you know where this would be spelled out?

Thanks,
Dave
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Colin Walters]

On Thu, 2005-07-07 at 12:52 -0700, David MacMahon wrote:

> Dan Williams wrote:
> > Can you file a bug with exactly this information against 'bind' in Red
> > Hat bugzilla?  This sounds like a caching nameserver problem more than a
> > NetworkManager one.  If you could add me to the CC-list of the bug that
> > would be great too.
>
> I'm reluctant to file a bug without first verifying that the forwarders
> are in fact supposed to be called in order.  I've looked through the
> copy of the BIND 9 Administrator's Reference Manual included with FC4,
> but I couldn't find any explicit statement about whether forwarders MUST
> be tried in the order given or MAY be tried in some arbitrary/random order.
>
> Do you know where this would be spelled out?

Most likely in the BIND code.  My guess though given the behavior is it
does round-robin.

I think the key here is not what BIND does, but what the DHCP
specification says.  If it says that clients must resolve names using
the nameservers given in order, than what NetworkManager is doing is
broken.  If however it does not specify (this is my guess), then
NetworkManager is not doing anything wrong, and the bug would lie in
your network setup for giving non-internal nameservers in the DHCP
response.  In the latter case the internal server should simply forward
queries for external names.



_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Thu, 2005-07-07 at 16:08 -0400, Colin Walters wrote:

> On Thu, 2005-07-07 at 12:52 -0700, David MacMahon wrote:
> > Dan Williams wrote:
> > > Can you file a bug with exactly this information against 'bind' in Red
> > > Hat bugzilla?  This sounds like a caching nameserver problem more than a
> > > NetworkManager one.  If you could add me to the CC-list of the bug that
> > > would be great too.
> >
> > I'm reluctant to file a bug without first verifying that the forwarders
> > are in fact supposed to be called in order.  I've looked through the
> > copy of the BIND 9 Administrator's Reference Manual included with FC4,
> > but I couldn't find any explicit statement about whether forwarders MUST
> > be tried in the order given or MAY be tried in some arbitrary/random order.
> >
> > Do you know where this would be spelled out?
>
> Most likely in the BIND code.  My guess though given the behavior is it
> does round-robin.
>
> I think the key here is not what BIND does, but what the DHCP
> specification says.  If it says that clients must resolve names using
> the nameservers given in order, than what NetworkManager is doing is
> broken.  If however it does not specify (this is my guess), then

But NetworkManager doesn't control which nameservers get used first, it
just dumps them to bind/caching-nameserver.  So NetworkManager isn't
really doing wrong stuff here, its the behavior of bind that's causing
the problem...  It just so happens that we have a much more intelligent
resolver now than with glibc.

-----------------------------
3.8. Domain Name Server Option

   The domain name server option specifies a list of Domain Name System
   (STD 13, RFC 1035 [8]) name servers available to the client.  Servers
   SHOULD be listed in order of preference.
-----------------------------

So it appears to say in the RFC (2132) that the servers should be
contacted in order returned from the DHCP server.  How do we tell bind
that's how we want it to work?

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Colin Walters]

On Thu, 2005-07-07 at 16:44 -0400, Dan Williams wrote:

> -----------------------------
> 3.8. Domain Name Server Option
>
>    The domain name server option specifies a list of Domain Name System
>    (STD 13, RFC 1035 [8]) name servers available to the client.  Servers
>    SHOULD be listed in order of preference.
> -----------------------------
>
> So it appears to say in the RFC (2132) that the servers should be
> contacted in order returned from the DHCP server.  

Well...yes, the spec says it's order of preference, but it's critical to
note here that DNS (being UDP based) is not a reliable protocol.  If for
instance the first (internal) server is heavily loaded and misses a
query from the client, then the client will fall back to one of the
secondary servers which won't have the internal addresses, and then he
loses.

So regardless, I think this is a bug in the network setup at wherever
David is.  He (and everyone else, regardless of whether or not they're
using NetworkManager, Windows, or whatever) will see this behavior
periodically if the internal server or the network is heavily loaded.
The network admins should fix it so only the internal server is
returned, and it forwards external requests.

That said, it is reasonable to try to make things more pleasant for him
to work around this bug.  From a quick look at the BIND source though I
don't see a way to change the policy :/



_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[David MacMahon]

Dan Williams wrote:
> But NetworkManager doesn't control which nameservers get used first, it
> just dumps them to bind/caching-nameserver.  So NetworkManager isn't
> really doing wrong stuff here, its the behavior of bind that's causing
> the problem...

If NetworkManager is taking an order-is-significant list from DHCP and
using it as an order-is-not-significant list in named.conf, then
NetworkManager is doing wrong stuff.  The question I've not yet
resolved, so to speak :-), is whether or not order is significant in the
named.conf file's forwarders option.  If order is supposed to be
significant in named.conf, then bind seems to have a problem.  If order
is not significant in named.conf, then NetworkManager seems to have a
problem.

> It just so happens that we have a much more intelligent
> resolver now than with glibc.

Can you please expand on that?  I suppose local caching is a slight
benefit, but is there anything else that makes using named preferable to
just putting...

nameserver ns1
nameserver ns2
nameserver ns3

...into /etc/resolv.conf?

Thanks,
Dave
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Thomas Hood-2]

David MacMahon wrote:

> Can you please expand on that?  I suppose local caching is a slight
> benefit, but is there anything else that makes using named preferable
> to just putting...
>
> nameserver ns1
> nameserver ns2
> nameserver ns3
>
> ...into /etc/resolv.conf?


Changes made to resolv.conf only affect new processes, not already
running processes.  Changes made to the caching nameserver configuration
can benefit already running processes.

--
Thomas Hood
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[David MacMahon]

Colin Walters wrote:
> So regardless, I think this is a bug in the network setup at wherever
> David is.  He (and everyone else, regardless of whether or not they're
> using NetworkManager, Windows, or whatever) will see this behavior
> periodically if the internal server or the network is heavily loaded.

The network is very lightly loaded, so I don't think that's causing my
problems.  I think named is caching the negative response(s) so once I
miss out on a lookup, it's toast (at least until the negative response
times out of the cache or named is restarted).  Doing "traditional"
name lookups (i.e. no named and no caching) would maybe fail once in a
while, but that failure wouldn't doom that name "forever".

> The network admins should fix it so only the internal server is
> returned, and it forwards external requests.

That's a good point.  I'll talk to them about that.

> That said, it is reasonable to try to make things more pleasant for him
> to work around this bug.  From a quick look at the BIND source though I
> don't see a way to change the policy :/

Did you see the policy somewhere in there?  I briefly looked at the
sources, but didn't see any obvious indications of what the policy was.

Thanks,
Dave
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Peter Jones-18]

On Thu, 2005-07-07 at 12:06 -0700, David MacMahon wrote:
[snip]

> nameserver 127.0.0.1
>
> If I change /etc/resolve.conf to...
>
> nameserver 10.12.0.1
> nameserver <ip of dns2>
> nameserver <ip of dns3>
>
> ...then "host 10.12.50.12" always succeeds.  This leads me to believe
> that the forwarders listed in the named.conf file are not always used in
> the given order.

Are you running nscd?

If you're using bind+forwarders _and_ nscd, that'll effectively mean
that the round robin behavior only applies to new queries; repeated
queries will always be resolved from the cache.
--
        Peter

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Thu, 2005-07-07 at 14:47 -0700, David MacMahon wrote:

> Dan Williams wrote:
> > But NetworkManager doesn't control which nameservers get used first, it
> > just dumps them to bind/caching-nameserver.  So NetworkManager isn't
> > really doing wrong stuff here, its the behavior of bind that's causing
> > the problem...
>
> If NetworkManager is taking an order-is-significant list from DHCP and
> using it as an order-is-not-significant list in named.conf, then
> NetworkManager is doing wrong stuff.  The question I've not yet
> resolved, so to speak :-), is whether or not order is significant in the
> named.conf file's forwarders option.  If order is supposed to be
> significant in named.conf, then bind seems to have a problem.  If order
> is not significant in named.conf, then NetworkManager seems to have a
> problem.
>
> > It just so happens that we have a much more intelligent
> > resolver now than with glibc.
>
> Can you please expand on that?  I suppose local caching is a slight
> benefit, but is there anything else that makes using named preferable to
> just putting...
>
> nameserver ns1
> nameserver ns2
> nameserver ns3
>
> ...into /etc/resolv.conf?

1) (as already mentioned) changes are not immediately visible to running
applications, it sucks to have to either quit and relaunch mozilla, or
to wait 1 minute for stuff to work
2) apps in the middle of a DNS query return immediately and don't wait
the full 30s timeout for DNS queries
3) Split DNS allows us to only resolve certain domains with certain
servers, as opposed to everything through 1 server.  Useful for VPN
where we want only *.redhat.com to go to Red Hat DNS, everything else
through our local nameserver from DHCP

Dan


_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[David MacMahon]

Dan Williams wrote:
> So it appears to say in the RFC (2132) that the servers should be
> contacted in order returned from the DHCP server.  How do we tell bind
> that's how we want it to work?

I don't know whether bind has an option to always query the forwarders
in the order given.

A possible alternative would be run bind listening on MAXNS (3 on FC4)
ports with each port's server having only one forwarder.  Then
resolv.conf could contain MAXNS nameserver entries; one for each of the
different ports.  The "only" hitch is that the man page for resolv.conf
(on FC4) doesn't mention anything about how to use different ports in
resolv.conf.

Dave

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Thomas Hood-2]

David MacMahon wrote:

> Dan Williams wrote:
>
>> So it appears to say in the RFC (2132) that the servers should be
>> contacted in order returned from the DHCP server.  How do we tell bind
>> that's how we want it to work?
>
> I don't know whether bind has an option to always query the forwarders
> in the order given.
>
> A possible alternative would be run bind listening on MAXNS (3 on FC4)
> ports with each port's server having only one forwarder.  Then
> resolv.conf could contain MAXNS nameserver entries; one for each of
> the different ports.  The "only" hitch is that the man page for
> resolv.conf (on FC4) doesn't mention anything about how to use
> different ports in resolv.conf.

Here is a good reason, then, to use dnsmasq rather than bind.
When dnsmasq is run with the --strict-order option it always
consults nameservers in the specified order.  (Its default
behavior is to try to be smart: Start with no current server,
in this state queries are sent in parallel to all servers. The
first one to reply becomes the current server. Subsequent
queries are sent to that server alone. If a query to the
current server times out without a reply, revert to the
initial state and retransmit to all in parallel, select a ne
current server based on who wins the race.)

Another reason: the dnsmasq package in Debian is one third the size of
the bind9 package.

Another reason: dnsmasq is designed from the ground up as a caching
nameserver.

Another reason: dnsmasq does not need to be restarted or
even signalled when the list of nameservers chagnes.  dnsmasq
can be configured to poll a file which lists the nameservers it
should use.

Another reason: If dnsmasq is used then there is no need for it
to be run as NM's private instance.  dnsmasq naturally coexists
with bind running as an authoritative nameserver.

There may be reasons for preferring bind but if they were
mentioned then that was before I joined the list.  Hopefully
someone will clue me in if that is the case.
--
Thomas Hood

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Colin Walters]

On Mon, 2005-07-11 at 20:52 +0200, Thomas Hood wrote:

> Here is a good reason, then, to use dnsmasq rather than bind.
> When dnsmasq is run with the --strict-order option it always
> consults nameservers in the specified order.

But again, this would only help most (i.e. not all) of the time.  The
network setup where David is is just broken.

>  (Its default
> behavior is to try to be smart: Start with no current server,
> in this state queries are sent in parallel to all servers. The
> first one to reply becomes the current server. Subsequent
> queries are sent to that server alone. If a query to the
> current server times out without a reply, revert to the
> initial state and retransmit to all in parallel, select a ne
> current server based on who wins the race.)

Actually this looks to me like it would make things worse; in David's
case, suppose that one of the external servers happens to win the race.
It will give back a negative reply for an internal name.  If that's then
cached, then one loses.

> Another reason: the dnsmasq package in Debian is one third the size of
> the bind9 package.
>
> Another reason: dnsmasq is designed from the ground up as a caching
> nameserver.

Ok, but these reasons aren't very convincing on their own.

> Another reason: dnsmasq does not need to be restarted or
> even signalled when the list of nameservers chagnes.  dnsmasq
> can be configured to poll a file which lists the nameservers it
> should use.

Sending SIGHUP or whatever it is is a pretty trivial amount of code.

> Another reason: If dnsmasq is used then there is no need for it
> to be run as NM's private instance.  dnsmasq naturally coexists
> with bind running as an authoritative nameserver.

When NetworkManager handles servers too we can be concerned about the
possibility of running an authoritative nameserver alongside it, but for
now I'm just not too worried about it.

> There may be reasons for preferring bind but if they were
> mentioned then that was before I joined the list.  Hopefully
> someone will clue me in if that is the case.

Basically just that it was there and worked.  I had a lot of code
already written in eggcups for managing cupsd (writing out a conf file,
etc), it was easy enough to port to named.

If you really really care it shouldn't be too difficult to implement
nm-named-manager-dnsmasq.c and do conditional compilation.  Not sure if
Dan would take the patch, but it's probably not too much of a
maintenance burden.

Personally though I don't really see the value of spending developer
time on replacing bits of NetworkManager's internals (which is
essentially what bind is now); better to spend time on the user-visible
issues and features like VPN support, reliability, etc.



_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Mon, 2005-07-11 at 15:05 -0400, Colin Walters wrote:
> If you really really care it shouldn't be too difficult to implement
> nm-named-manager-dnsmasq.c and do conditional compilation.  Not sure if
> Dan would take the patch, but it's probably not too much of a
> maintenance burden.

Yeah, I'd take a patch.

> Personally though I don't really see the value of spending developer
> time on replacing bits of NetworkManager's internals (which is
> essentially what bind is now); better to spend time on the user-visible
> issues and features like VPN support, reliability, etc.

However, now that Jason's given bind some dbus awareness, we could
ignore the config file stuff altogether and just talk to it over dbus
like we do for DHCP.  The same could be done for dnsmasq.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[David MacMahon]

Colin Walters wrote:
> But again, this would only help most (i.e. not all) of the time.  The
> network setup where David is is just broken.

Actually, it was was broken, but now its fixed!  I'm now happily using
NM all the time (except I still have to change ntpd so it starts up
after NM).

I think it is desirable to address nameserver ordering not to support
broken configs like at my site, but because it would make DNS lookups
under NM follow the DHCP spec more closely with regard to search order
preference of the supplied nameservers.

Just my two cents' worth,
Dave
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Simon Kelley]

Dan Williams wrote:
> On Mon, 2005-07-11 at 15:05 -0400, Colin Walters wrote:
>
>>If you really really care it shouldn't be too difficult to implement
>>nm-named-manager-dnsmasq.c and do conditional compilation.  Not sure if
>>Dan would take the patch, but it's probably not too much of a
>>maintenance burden.
>
>
> Yeah, I'd take a patch

I plan to produce one when I get some spare time. (and when I've
released dnsmasq 2.23, which has DBus support.) A question arises as to
how the code determines which DNS forwarder to use. Obvious options are:

1) Conditional compilation
2) Runtime configuration.
3) Try options in turn and use the first one which is on the DBus.

Dan, do you have a preference?
>
Cheers,

Simon.
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[Dan Williams]

On Tue, 2005-07-12 at 11:05 +0100, Simon Kelley wrote:

> Dan Williams wrote:
> > On Mon, 2005-07-11 at 15:05 -0400, Colin Walters wrote:
> >
> >>If you really really care it shouldn't be too difficult to implement
> >>nm-named-manager-dnsmasq.c and do conditional compilation.  Not sure if
> >>Dan would take the patch, but it's probably not too much of a
> >>maintenance burden.
> >
> >
> > Yeah, I'd take a patch
>
> I plan to produce one when I get some spare time. (and when I've
> released dnsmasq 2.23, which has DBus support.) A question arises as to
> how the code determines which DNS forwarder to use. Obvious options are:
>
> 1) Conditional compilation
> 2) Runtime configuration.
> 3) Try options in turn and use the first one which is on the DBus.

I'd rather have dynamic configuration so that it "just works," like your
option 3.  If the user has both bind/caching-nameserver and dnsmasq
running, there would have to be a table in there for 'try x first, then
y', but nobody would likely be running both.  It may take some
abstraction of the current named-manager/*.c files but I think the more
dynamic we can be here, the less pain for the user.

The same goes for the DHCP stuff, it would be nice to have that
dynamically choose as well.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list