IPoIB "hardware addresses" are only partly based on the hardware, and
partly based on the InfiniBand configuration. So when checking if a
configuration matches a device, we should only match the fixed part.
Fix infiniband_partition_add() to put the newly-created device into
the link_cache before returning. Fix link_is_software() to recognize
partition devices as software, so that link_get() is willing to return
them even before we get the udev info.
If there are no specs, then the device can't match, so don't call the
virtual method (which might do work like building comparison strings
even when the list is empty).
The problem is that there is only a single variable in ifcfg file holding dns
domains - DOMAIN. Thus NetworkManager writes both IPv4 and IPv6 dns-search into
it. While reading there is no way to distinguish between IPv4 and IPv6 values,
so the DOMAIN value is read and only put into IPv4 dns-search.
But, when IPv4 is disabled or invalid, the domains got lost. So in such case
we put DOMAIN variable into IPv6 instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1004866
These are expected errors if the supplicant can't be launched
for some reason. We should only log entirely unexpected errors
like wrong method arguments or types, really odd failures, etc.
NetworkManager[1312]: <error> [1379601146.148818] [supplicant-manager/nm-supplicant-interface.c:853] interface_add_cb(): (wlan0): error adding interface: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
NetworkManager[1312]: <error> [1379601171.160742] [supplicant-manager/nm-supplicant-interface.c:853] interface_add_cb(): (wlan0): error adding interface: Activation of fi.w1.wpa_supplicant1 timed out
Since 2688ae4950, bridge device creation
fails with "(br0): cannot use existing bridge for 'Bridge'" warning.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Currently, ethernet-based VLANs can specify the hardware address of
the parent device (and, in theory, the cloned hardware address and MTU
of the VLAN device) by using an NMSettingWired in addition to the
NMSettingVlan.
The theory was that non-ethernet-based VLANs, when we eventually
supported them, would likewise use the setting type corresponding to
their parent device. However, this turns out to be both complicated
(the settings plugins and connection editor would have a
hard-to-impossible time figuring out which setting type to use in some
cases) and incorrect (for most L2 settings [eg, BSSID, bond mode,
etc], the VLAN can't have its own values separate from the parent
device).
What we should have done was just have :mac-address,
:cloned-mac-address, and :mtu properties on NMSettingVlan. However, at
this point, for backward-compatibility, we will just stick with using
a combination of NMSettingVlan and NMSettingWired, but we will use
NMSettingWired regardless of the underlying hardware type.
Rather than having NMManager know how to parse various settings to
create each kind of software device, add a _new_for_connection()
constructor to each of them and let them call NMPlatform to create the
device correctly themselves.
Rather than setting the VLAN maps when the device is created, set them
at activation time, which is more in line with how other device types
work.
Like the old code, this doesn't attempt to reset any existing
ingress/egress mappings on the device.
They look exactly like normal Ethernet interfaces, but they are managed
entirely by the Open vSwitch tools in software, so NM shouldn't (yet)
touch them. Treat them instead as generic devices that only get touched
through direct user requests.
Cache externally added IP details and represent them via the D-Bus
interface, and also merge them into the final device config to ensure
they aren't lost if DHCP renews or RA changes occur.
Since Debian 7 (Wheezy) / Ubuntu 11.04 (Natty Narwhal) ifupdown supports
the source stanza to source in other configuration files from
/etc/network/interfaces.
Add support to the ifupdown plugin to include configuration files via
source.
Patch did not apply cleanly and was slightly modified by Thomas Haller.
https://bugzilla.gnome.org/show_bug.cgi?id=707276
Signed-off-by: Thomas Haller <thaller@redhat.com>
Reviewed-by: Sebastian Harl <tokkee@debian.org>
Add a flag to indicate that the device is owned by NM.
This is interesting for software/virtual devices, that were created by
NM and should be deleted when the interface gets deactivated.
This flag is not implemented as a glib property.
Maybe this flag can be consolidated with the managed flag. For now it is
unclear how to do it, so add this flag. It should be easy later to
replace it again.
https://bugzilla.gnome.org/show_bug.cgi?id=695705https://bugzilla.redhat.com/show_bug.cgi?id=953300
Signed-off-by: Thomas Haller <thaller@redhat.com>
Old clients might expect 802-11-wireless.security being set for secured Wi-Fi
connections. So to be on a safer side, we set the property in D-Bus GetSettings()
result.
The manager has already disposed of the ActiveConnections by the time
the Policy is disposed, but the manager wasn't clearing the
active_connections list, so the Policy got a stale list of freed
objects. Next, the manager wasn't always emitting ACTIVE_CONNECTION_REMOVED
when disposing of ActiveConnections, which the Policy listens to
for cleanup. This lead to warnings on shutdown when the Policy
attempted to clean up for already disposed objects
Fix all this by ensuring the Manager signals when removing
ActiveConnections, which the Policy then uses to clean up
it's stuff, and ensuring the manager properly cleans up its
ActiveConnection list.
