RFC6101 adds the DNS Search List option to router advertisements. This
allows stateless configuration of suffixes to try when doing DNS lookups.
Make sure we catch these when provided by the kernel and reconfigure
things appropriately.
NOTE: this commit depends on a kernel patch:
http://marc.info/?l=linux-netdev&m=129216173321352&w=2
RFC5006/RFC6106 specifies fairly clearly how to handle multiple RDDNS options.
Unfortunately the previous code didn't deal with this and hence would
misbehave in all but the simplest setups. The new code should be fully
compliant with the following exceptions:
- Router lifetime not respected
- No "sufficient number" management.
- DHCPv6 servers might not be prioritised over RDDNS ones.
Filter registered agents for each secrets request to ensure that the
connection for which secrets are requested is visible to that agent,
and add that agent to the queue. Ask each agent in the queue until
one returns usable secrets. Ensure that if new agents register
or existing agents quit during the secrets request, that the queue
is updated accordingly, and ensure that an agent that's already
been asked for secrets, unregisters, and re-registers before the
secrets request is comple, isn't asked for secrets twice.
Instead of a bizare mechanism of signals back to the manager
object that used to be required because of the user/system settings
split, let each place that needs secrets request those secrets
itself. This flattens the secrets request process a ton and
the code flow significantly.
Previously the get secrets flow was something like this:
nm_act_request_get_secrets ()
nm_secrets_provider_interface_get_secrets ()
emits manager-get-secrets signal
provider_get_secerts ()
system_get_secrets ()
system_get_secrets_idle_cb ()
nm_sysconfig_connection_get_secrets ()
system_get_secrets_reply_cb ()
nm_secrets_provider_interface_get_secrets_result ()
signal failure or success
now instead we do something like this:
nm_agent_manager_get_secrets ()
nm_agent_manager_get_secrets ()
request_start_secrets ()
nm_sysconfig_connection_get_secrets ()
return failure or success to callback
We only want to prevent regression to > READY after READY has
been reached, since the interface state will track the supplicant
connection state which legitimately jumps around.
If we find a "iface ..." line, add the interface to
well_known_interfaces no matter if there is a connection for it or not.
Otherwise we fail to mark devices as unmageded in cases like
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
as NM does not know how to parse such a interface configuration.
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569215
This branch now requires wpa_supplicant 0.7 or later with the new
D-Bus interface enabled. It also prefers the "nl80211" supplicant
driver over the WEXT one, but will ask the supplicant to fall back
to the WEXT driver if the device in question does not support the
kernel's nl80211/cfg80211 stack.
If the supplicant cannot be service activated, wait until it shows up
on the bus instead of sitting around doing nothing. This fixes a small
regression introduced when the _READY state was added to the supplicant
interface object.
Don't emit "unmanaged-specs-changed" signal in read_one_connection(),
because it causes that next connections are not listed (get_connections() is
called prematurely and only connections read so far are available).
Steps to reproduce the bug:
1) create ifcfg-fake
DEVICE=loremipsum
HWADDR=01:02:03:04:05:06
NM_CONTROLLED=no
2) restart NetworkManager
3) only connections read *before* ifcfg-fake are available
Thanks to Robert Vogelgesang <vogel@users.sourceforge.net> for updating
the patch and analysis!
New connections should not be pushed out in the Updated signal
because signals cannot be restricted to particular clients, and
some clients may not have permission to view the connection.
Upon receiving the Updated signal, clients should re-read the
connection using GetSettings to ensure that the client still
has permissions to view the connection, and to get the updated
settings.
GATEWAY0=0.0.0.0 was erroneously denied. Also, missing GATEWAY0 entry caused
ifcfg-rh plugin to regard the connection as invalid. The commit fixes that and
makes it behave in accordance with initscripts.
