gcc complains with the following warning:
"comparison between 'enum <anonymous>' and 'enum vlan_flags'"
Cast one side of the comparison to avoid that.
Fixes: ee7414ebc8
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
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.
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
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
Also do a major cleanup of the tests:
- Have utility functions in "test-common.h" with a new prefix "nmtstp_".
The prefix indicates that these are test functions for platform.
- Add functions to add/remove IP addresses that either use external
iproute2 command or platform function itself. These commands also
assert whether the command had the expected result.
- Randomize, whether we use the external command for adding
ip-addresses. Both approaches should yield the same result
for linux-platform.
I did this now for address-tests, but effectively this doubled
all our previous tests to use both internal and external ways
to configure the address.
- Enable all address tests for fake-platform. They now
automatically don't call external iproute2 but fallback
to fake-platform implementation. This adds more coverage
to the fake-platform, which we want to behave identical
to linux-platform.
- Setup a clean test device before every address-test.
Kernel allows to add the same IPv4 address that only differs by
peer-address (IFL_ADDRESS):
$ ip link add dummy type dummy
$ ip address add 1.1.1.1 peer 1.1.1.3/24 dev dummy
$ ip address add 1.1.1.1 peer 1.1.1.4/24 dev dummy
RTNETLINK answers: File exists
$ ip address add 1.1.1.1 peer 1.1.2.3/24 dev dummy
$ ip address show dev dummy
2: dummy@NONE: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
link/ether 52:58:a7:1e:e8:93 brd ff:ff:ff:ff:ff:ff
inet 1.1.1.1 peer 1.1.1.3/24 scope global dummy
valid_lft forever preferred_lft forever
inet 1.1.1.1 peer 1.1.2.3/24 scope global dummy
valid_lft forever preferred_lft forever
We must also consider peer-address, otherwise platform will treat
two different addresses as one and the same.
https://bugzilla.gnome.org/show_bug.cgi?id=756356
Also change the semantic of nm_ip6_config_address_exists()
to ignore the prefix length. It seems more correct this way,
but as there are no users of the function it doesn't actually
matter.
Kernel treats IPv4 addresses with different netmask/prefix-length as
different addresses.
It is wrong to merge them together in nm_ip4_config_add_address().
For IPv6 addresses that is not the case and you cannot configure
two IPv6 addresses that only differ by plen (on the same interface).
The peer-address seems less important then the prefix-length.
Also, nm_platform_ip4_address_delete() has the peer-address
argument as last.
Soon ip4_address_get() also receives a peer-address argument,
so get the order right first.
A separate instance of the support plugin is spawned for each connection with
a different bus name. The bus name is passed via --bus-name <name> argument.
Plugins that support the feature indicate it with
support-multiple-connections=true key in the [VPN Connection] section.
The bus name is currently generated by adding a .<connection.uuid> to the VPN
service name. It's guarranteed unique, but if it proves to be too long or ugly
it can easily be replaced with something more meaningful (such as the same number
as is used for connection's DBus name).
NMVpnService has been removed and folded into NMVpnConnection. A
NMVpnConnection will spawn a service plugin instance whenever it is activated
and notices the bus name it needs is not provided.
The NMVpnManager no longer needs to keep track of the connections in use apart
for compatibility purposes with plugins that don't support the feature.
This adds a LldpNeighbors property to the Device D-Bus interface
carrying information about devices discovered through LLDP. The
property is an array of hashes and each hash describes the values of
LLDP TLVs for a specific neighbor.
