Create a new NMConnection for PAN devices if no compatible connection
exists and export it via DBUS. This has the effect of always exposing
any usable PAN-capable device.
https://bugzilla.gnome.org/show_bug.cgi?id=701078
Signed-off-by: Thomas Haller <thaller@redhat.com>
This method returns true, if the connections are already loaded (and the
connection_loaded signal already emited).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Modify BlueZ 5 device to have the same behaviour as BlueZ 4, i.e. a
pre-configured connection must exist for the device to show up in
NetworkManager's device list.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The files nm-bluez-device.c and nm-bluez5-device.c are similar.
Merge them together into one file and handle the differences
using #if directives.
This commit does not actually change any functionality. All it does, is
merging the files together and separating the differences with #if#else.
The next commit will further add common functionality, so this
reduces code duplication for now.
Signed-off-by: Thomas Haller <thaller@redhat.com>
These two files share much code, so they will be merged
into one file.
As a first step, make some trvial renaming to make the two
files more similar and easier to merge.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At this moment we only support one of BlueZ 4 and 5,
which has to be defined at build time.
Patch rewritten by Thomas Haller <thaller@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
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
Bonding options are related and some combinations don't make sense. Basically,
MIIMON and ARP monitoring mode (and related options) are mutually exclusive.
When nmcli set arp_interval of "0" (the default value),
nm_setting_bond_add_option() cleared the MIIMON options (miimon, updelay and
downdelay).
This commit works around libnm-util's nm_setting_bond_add_option() that clears
miimon options when arp_interval is being set and vice versa, but doesn't
take into account the value of "0" that should be regarded as 'disable'.
https://bugzilla.redhat.com/show_bug.cgi?id=1007355
The commands performing actions without an output only printed a successfull
message for --pretty mode. Some users don't like this silent operation.
This commit makes nmcli print operation success unconditionally. I think that
doesn't hurt; scripts/users can ignore the message if not interested.
https://bugzilla.redhat.com/show_bug.cgi?id=1006444
Also allow leading/trailing white spaces, and more white spaces between IP and
gateway. (Spaces in values and around / are not allowed).
All of these are accepted:
' 1.2.3.4/11 1.2.3.254 '
' 1.2.3.4 '
' fe80::215:ff:fe93:ffff/128 ::1 '
...
https://bugzilla.redhat.com/show_bug.cgi?id=1007368
