ifcfg-rh wasn't updated for WEP passphrases after that capability
got added. Can't use KEY for passphrases since there's no way
to distinguish some WEP passphrases from some WEP Hex and ASCII
keys, so we use KEY_PASSPHRASE instead.
The error case was as follows. When using 'ifupdown,keyfile' plugins
and 'eth0' present in /etc/network/interfaces on a Debian-based system,
'ifupdown' plugin, in unmanaged mode, load_connections() prematurely
and thus effectively blocked reading connections from 'keyfile' plugin.
Patch by Dan and tested by me.
Poll the device's IPv6 flags so we're notified when the RA has
been parsed and what the flags are. Only when that's complete
and the device's target state has been reached (or Managed mode
was indicated by the RA) should we continue with IP configuration.
Where we can do so, let's use ifindex since that's actually unique
and doesn't change when the interface name changes. We already use
ifindex in a bunch of places, and netlink *only* uses ifindex, so
this will make it easier later when we move over to ifindexes fully.
The non-blocking connection is really only good for listening for
events. It doesn't work for request/response operations (like
refilling link and address caches) because the message receive loop
in libnl will break out from the EAGAIN before it gets the response
it needs to update the cache with.
This is most evident with link cache refills when requesting the
interface index from the name, or vice-versa; the refill request
exits early with EAGAIN (due to the non-blocking nature of the
connection's socket) and the cache isn't refilled, and the index
lookup fails. We need to use blocking netlink operations in quite
a few places besides index lookups, from address/route operations
to getting the initial device carrier state.
So, split the montior's netlink connection into a non-blocking
event listener connection, and a synchronous connection which gets
used for immediate operations. This also has the effect of
validation the synchronous operations for security, which wasn't
done before in nm-netlink.c (though it wasn't really a problem).
Got the flags wrong in the previous commit; MULTI isn't about
multicast/unicast, but about multi-part packets. Instead we need
to check the netlink sockaddr structure for the group mask.
The RA flags aren't in the link flags, they are in the special
PROTINFO flags that the IPv6 stack sends. To get these, because
libnl doesn't have native support for them, we get to parse the
netlink messages directly. Furthermore, the PROTINFO message
isn't sent unless it's explicitly requested with a
RTM_GETLINK/AF_INET6 message, meaning we get to poll for it
periodically.
So switch over to the netlink monitor object (killing a lot of
duplicate code) and start requesting the PROTINFO bits from
netlink.
We need the IFLA_PROTINFO messages, and these are apparently sent
(still by the kernel) but with our own PID. So the current checks
that limit the netlink PID to zero block these messages out. Instead
(like udev) we should be checking the actual sender of the message
usign unix socket credentials.
Second, at least at this point only privileged processes can send
netlink multicast messages, so as long as the:
* the other end of the socket is UID 0 AND
* the netlink PID is 0 OR
* the message is multicast and sent to our netlink PID
the we accept the message and process it as normal. For another
example of this, see 'netlink.c' from the dhcp6s program; do a
Google search for "IFLA_PROTINFO" to find it.
Ensure it still works correctly if something tries to set the
'addresses' property using the old GType. Also make sure that
the various IP6 address comparison operations and string conversion
functions handle the gateway.
We can change the property's D-Bus signature (and thus API) here
because querying the IP6Config object's properties caused NM to
crash. Apparently we forgot to change the type of the Address
property when we C&P-ed the IP4Config into the IP6Config, and
DBUS_TYPE_G_ARRAY_OF_ARRAY_OF_UINT is certainly the wrong type
to use since the backing object that dbus-glib would marshal
into the ARRAY_OF_ARRAY_OF_UINT wasn't that type, causing a
crash in dbus-glib when a client got the IP6Config.
Instead of not including the IP4 setting, set its method to disabled.
In reality either one is legal, but including the IP4 setting wtih
the method set to 'disabled' is more explicit.
