Because Bluez5 dropped DUN support, NM must do that manually which
includes emulating the "connected" property for Bluetooth devices when
DUN is used. It does this by setting priv->connected = TRUE in
nm_bluez_device_connect_finish().
But for PAN, when NM does process the 'connected' property change
notification, priv->connected is already TRUE and
_take_variant_property_connected() does nothing. Hence the
corresponding GObject property notification is not emitted,
nm-device-bt.c::check_connect_continue() will never return success, and
the activation times out.
To fix this, ensure that GObject notifications are emitted when the
device is connected, even if emulated internally.
https://mail.gnome.org/archives/networkmanager-list/2015-October/msg00053.htmlhttps://bugzilla.redhat.com/show_bug.cgi?id=1255284
It might be that the user didn't supply the secrets in time and the dbus call
timed out. The agent should now hide the secrets dialog and we must let it know.
https://bugzilla.redhat.com/show_bug.cgi?id=1272023
NetworkManager-devel package contained development headers that
are useful without libnm-glib and without glib. But it is also
based on the legacy libnm-glib library as it has headers like
"/usr/include/NetworkManager/NetworkManager.h".
A glib-free devel package based on the new libnm library would
be needed to provide "/usr/include/libnm/nm-dbus-interface.h".
But that would amount to 4 devel packages. Instead, just move
the content of NetworkManager-devel into NetworkManager-glib-devel
package.
Note that NetworkManager-devel already contained several truely
libnm-glib dependent files, like the vala bindings (which require
libnm-glib). So that was another bug in the packaging and is fixed
by moving it all to NetworkManager-glib-devel.
https://bugzilla.gnome.org/show_bug.cgi?id=755938
Example:
before:
$ nmcli c add type gsm con-nameX aaa ifname fsd
Error: 'ifname' argument is required.
now:
$ nmcli c add type gsm con-nameX aaa ifname fsd
Error: mandatory 'ifname' not seen before 'con-nameX'.
It does more than intended; apart from denying messages to that particular
interface it also denies all messages non-qualified with an interface globally.
From the dbus-daemon manual:
Be careful with send_interface/receive_interface, because the
interface field in messages is optional. In particular, do NOT
specify <deny send_interface="org.foo.Bar"/>! This will cause
no-interface messages to be blocked for all services, which is almost
certainly not what you intended. Always use rules of the form: <deny
send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
We can just safely remove those rules, since we're sufficiently protected
by the send_destination matches and method calls are disallowed by default
anyway.
We changed the default value of MSettingVlan:flags from 0 to
1 (NM_VLAN_FLAG_REORDER_HEADERS). That means, that old libnm
clients will not serialize 0 (their default).
This change broke the D-Bus API. The D-Bus API allows to omit a value
when meaning the default value. That means, we cannot change the
default value (in the D-Bus API!) without breaking previous assumptions.
A newer libnm version should treat a missing flags argument as the
old default value and thus preserve the original default value (in the
D-Bus API).
This has the downside that for the future we will continue to treat a missing
value as the old default value (0), and in order to get the new default
value (1), the client must explicitly set the flags.
We also must restore the original default value in libnm-glib.
libnm-glib does not support _nm_setting_class_override_property()
and thus it must keep thinking that the default value for the GObject
property continues to be 0. Otherwise, it would not serialize a 1, which
a new libnm would now interpret as 0.
https://bugzilla.redhat.com/show_bug.cgi?id=1250225
Fixes: 687b651598
We changed the default value for the NMSettingVlan:flags from 0 to
1 (NM_VLAN_FLAG_REORDER_HEADERS). That means, we will no longer serialize
a value of 1 over D-Bus.
This breaks older libnm clients, which treat a missing flags property as
the old default (0).
-- old clients here means: clients that still use an older version of libnm
or clients that don't use libnm, but depend on the previous default value
in the D-Bus API.
Enforce to always serialize the flags properties. This workaround has almost
no downsides except that for new clients we serialize more then absolutely
necessary.
But it ensures that old clients still receive the proper value.
https://bugzilla.redhat.com/show_bug.cgi?id=1250225
Fixes: 687b651598
For an explicit user-request, we relax some checks when searching for a suitable
device; such as requiring-carrier.
Without this patch, a connection-up while the device has no carrier yet,
would fail right away with "No suitable device found for this connection."
https://bugzilla.redhat.com/show_bug.cgi?id=1079353
Fixes: 0bfe635119
GLib introspection requires all types returned by public functions to
be GObjects, basic types or boxed types in order to correctly manage
resources. NMLldpNeighbor was a plain struct and GI complained with:
Warning: NM: nm_lldp_neighbor_new: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip)
To fix this define NMLldpNeighbor as a boxed type.
Fixes: d3d2b49400
Initscripts do:
oldifs=$IFS;
IFS=';';
[ -n "${ETHTOOL_DELAY}" ] && /bin/usleep ${ETHTOOL_DELAY}
for opts in $ETHTOOL_OPTS ; do
IFS=$oldifs;
if [[ "${opts}" =~ [[:space:]]*- ]]; then
/sbin/ethtool $opts
else
/sbin/ethtool -s ${REALDEVICE} $opts
fi
IFS=';';
done
IFS=$oldifs;
thus, we want to split on ';', otherwise we parse
"wol d;something else"
wrong.
Also, g_strsplit_set() returns multiple empty tokens. So
we must skip over empty tokens in case of "wol d".
The @use_password was wrong, because we would warn if sopass is specified
before wol:
"sopass AA:BB:CC:DD:EE:FF wol g"
More resilently handle wrong configurations:
"wol pu wol m" => gives m.
"wol pu wol" => should give NONE and warn (instead of "pu").
Also accept tab as separator.
Add a new 'ignore' option to NMSettingWired.wake-on-lan which disables
management of wake-on-lan by NetworkManager (i.e. the pre-existing
option will not be touched). Also, change the default behavior to be
'ignore' instead of 'disabled'.
https://bugzilla.gnome.org/show_bug.cgi?id=755182
When a VLAN connection was added with command:
nmcli c add type vlan ifname v10 id 10 dev 00:11:22:33:44:55
nmcli tried to assign a byte-array value to the ethernet.mac-address
string property, resulting in a invalid connection which failed to
verify. Fix this and set the value as plain string.
