In update_connection(), pickup the configuration of
the vlan interface from platform and create the proper
NMSettingVlan setting.
And during stage1, configure the flags of the device.
Also, change all the ingress/egress mappings at once
instead of having a netlink request for each mapping.
Also, ensure we *clear* all other mappings so that
only those are set, that were configured (done by
the *gress_reset_all argument).
Instead of using libnl-route-3 library to serialize netlink messages,
construct the netlink messages ourselves.
This has several advantages:
- Creating the netlink message ourself is actually more straight
forward then having an intermediate layer between NM and the kernel.
Now it is immediately clear, how a platform request translates to
a netlink/kernel request.
You can look at the kernel sources how a certain netlink attribute
behaves, and then it's immediately clear how to set that (and vice
versa).
- Older libnl versions might have bugs or missing features for which
we needed to workaround (often by offering a reduced/broken/untested
functionality). Now we can get rid or workaround like _nl_has_capability(),
check_support_libnl_extended_ifa_flags(), HAVE_LIBNL_INET6_TOKEN.
Another example is a libnl bug when setting vlan ingress map which
isn't even yet fixed in libnl upstream.
- We no longer need libnl-route-3 at all and can drop that runtime
requirement, saving some 400k.
Constructing the messages ourselves also gives better performance
because we don't have to create the intermediate libnl object.
- In the future we will add more link-type support which is easier
to support by basing directly on the plain kernel/netlink API,
instead of requiring also libnl3 to expose this functionality.
E.g. adding macvtap support: we already parsed macvtap properties
ourselves because of missing libnl support. To *add* macvtap
support, we also would have to do it ourself (or extend libnl).
The peer-address (IFA_ADDRESS) can also be all-zero (0.0.0.0).
That is distinct from an usual address without explicit peer-address,
which implicitly has the same peer and local address.
Previously, we treated an all-zero peer_address as having peer and
local address equal. This is especially grave, because the peer is part
of the primary key for an IPv4 address. So we not only get a property of
the address wrong, but we wrongly consider two different addresses as
one and the same.
To properly handle these addresses, we always must explicitly set the peer.
Usually, the peer-address is the same as the local address.
In case where it is not, it is the peer-address that determines
the IPv4 device-route. So we must use the peer-address.
Also, don't consider device-routes with the first octet of zero,
just like kernel does.
Also, nm_ip4_config_get_subnet_for_host() is effectively the same
as nm_ip4_config_destination_is_direct(). So drop it.
We already have nm_platform_tun_get_properties(). Rename the function
as they both sidestep the platform cache to lookup some link-specific
properties.
For recent kernels, the peer-ifindex of veths is reported as
parent (IFA_LINK). Prefer that over the ethtool lookup.
For one, this avoids the extra ethtool call which has the
downside of sidestepping the platform cache. Also, looking
up the peer-ifindex in ethtool does not report whether the
peer lifes in another netns (NM_PLATFORM_LINK_OTHER_NETNS).
Only use ethtool as fallback for older kernels.
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
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
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.
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.
The unmanaged-flag NM_UNMANAGED_EXTERNAL_DOWN is initially set during
nm_device_finish_init(). But it was only set if the device was down at
that point.
If due to a race the platform device was not yet initialized, a later
initialization in device_link_changed() would clear NM_UNMANAGED_PLATFORM_INIT.
If the device is not external-down (because it was already up during
nm_device_finish_init()), the device will be managed right away with
reason NM_DEVICE_STATE_REASON_NOW_MANAGED.
Together with commit e29ab54335, this
is a race that causes a failure to assume the external-down device.
https://bugzilla.redhat.com/show_bug.cgi?id=1269199
When a VLAN has a bond as parent device the MAC address of the bond
may change when other devices are enslaved and then the VLAN would
have a MAC which is different from parent's one.
Let the VLAN device listen for changes in hw-address property of
parent and update its MAC address accordingly.
https://bugzilla.redhat.com/show_bug.cgi?id=1264322
Executing:
# brctl addbr lbr0
# ip addr add 10.1.1.1/24 dev lbr0
# ip link set lbr0 up
can result in a race so that NetworkManager would manage the device
(and clear the IP addresses).
It happens, when NetworkManager first receives platform signals that
the device is already up:
signal: link changed: 11: lbr0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 1500 arp 1 bridge* not-init addrgenmode eui64 addr D2:A1:B4:17:18:F2 driver bridge
Note that the device is still unknown via udev (not-init). The
unmanaged-state NM_UNMANAGED_EXTERNAL_DOWN gets cleared, but the
device still stays unmanaged.
Only afterwards the device is known in udev:
signal: link changed: 11: lbr0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 1500 arp 1 bridge* init addrgenmode eui64 addr D2:A1:B4:17:18:F2 driver bridge
At this point, we also clear NM_UNMANAGED_PLATFORM_INIT, making
the device managed with reason NM_DEVICE_STATE_REASON_NOW_MANAGED.
That results in managing the external device.
Fix that by only clearing NM_UNMANAGED_EXTERNAL_DOWN after the device
is no longer NM_UNMANAGED_PLATFORM_INIT.
https://bugzilla.redhat.com/show_bug.cgi?id=1269199
schedule_stage3() used to set the firewall before really
scheduling the stage3. In that case, fw_change_zone_cb() would
then directly call:
activation_source_schedule (self, activate_stage3_ip_config_start, AF_INET);
This was different from all other places. Usually, only the
nm_device_schedule_*() functions would directly call to
activation_source_schedule().
Change this, to behave similar as when we wait for master-ready
while scheduling stage2. As such, it is more idiomatic, and
it would still work correctly even if there were multiple conditions
that would block scheduling-stage3.
Instead of adding explicit logging lines while scheduling and processing
the activation-stages, only log them in activation_source_schedule()
and activation_source_handle_cb().
Effectively, lines like:
"Activation: Stage 1 of 5 (Device Prepare) started..."
are now:
"activation-stage: invoke activate_stage1_device_prepare,2 (id x)"
The function name is logged, so change them to be more suitable:
- drop the "nm_device_" prefix. It is redundant in the logging,
and usually our static functions don't have an nm-prefix.
- have all functions now start with "activate_stagex_". The
stage number corresponds to what we are currently logging
during activation:
"Activation: Stage 1 of 5 (Device Prepare)..."
No other functions start with a "activate_stagex_" prefix,
so it's easy to grep.
Every activation-source handler first cleared the current
activation-source (activation_source_clear()) and later
returned FALSE/G_SOURCE_REMOVE.
Do not directly attach the handlers to g_idle_add().
Instead wrap the actual handler. This wrapper
- always clears the activation source first
- always returns G_SOURCE_REMOVE
- does trace logging about invoking the handler
This also avoids a possibility for a bug where the handler returns
G_SOURCE_REMOVE, without also clearing activation_source_clear().
Don't handle master-ready at the beginning of stage2, but instead while
scheduling (and then possibly delaying the scheduling of stage2).
This seems more idiomatic:
When inside a stage and your part is done: call schedule-next-stage.
That is, always schedule the next stage, not the current one.
schedule-next-stage then might delay to really scheduling until the
device is ready for the next state.
Fixes: 85ac903bb8
During stage2, if the slave detected that it would need to wait for
the master, it would return FALSE (which removes the g-idle-handler).
However, it would not clear the activation-source, so later, when
the master becomes ready, its attempt to schedule stage2 again would
result in an error-log and the idle-handler would not be scheduled
again.
Fixes: 85ac903bb8https://bugzilla.redhat.com/show_bug.cgi?id=1268797https://bugzilla.redhat.com/show_bug.cgi?id=1183444
When activating for example a team device which is to be enslaved to a
bridge, nm_device_activate_stage1_device_prepare() will postpone
stage 2.
In that case, we didn't register the "master-ready" of the team
device and thus never progressed the slave from stage2.
Reproduce:
# nmcli connection delete t-br0
# nmcli connection delete t-team0
nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1
nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0
nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge
nmcli connection up t-team0
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
For certain types of connection as PPP and WWAN the IP interface is
created during stage3 (IP config) but we are setting the firewall zone
at the beginning of stage3 and thus the zone is only set on the
underlying interface.
Add a check at the start of IP check phase to ensure that the firewall
zone is set again if the device interface is different from IP
interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1110465
Depending on the network and the values of the 'dad_transmits' and
'retrans_timeout_ms' sysctls, DAD for the IPv6LL address can take
quite a while. Obviously there must be some upper bound on the
timeout, but 5 seconds seems a bit low. In this case it was observed
to be ~12 seconds but the sysctl values are unknown. In any case,
we can't predict the network/config so being a bit more lenient here
makes sense.
https://bugzilla.redhat.com/show_bug.cgi?id=1101809
Always take a reference to the manager when scheaduling an asynchronous
operations. In fact, all callers want to keep the manager alive as long
as there are operations in progress.
Refactor NMFirewallManager to have consistent semantics about
asynchronous calls.
- the callback is always invoked exactly once, but never
synchronously when starting the operation.
- while cancelling the request, the callback is invoked
synchronously with respect to the cancel operation.
- you can cancel a request once (and once only).
- you cannot cancel the request once the callback is invoked.
- when disposing the object with requests pending, the
callbacks are invoked synchronously.
- Add a callback argument to nm_firewall_manager_remove_from_zone().
Otherwise, the user never knows whether a call is still pending and
cancellable (as complete operations cannot be cancelled).
In fact, it makes no sense trying to cancel a call if you don't care
about when it completes.
- get rid of PENDING_CALL_DUMMY. The dummy callback allows cancellation
any number of times. We want to catch wrong usage by asserting that an
operation is only cancelled once.
- nm_firewall_manager_cancel_call() doesn't need the manager argument.
Either the call-id is valid (and has a valid pointer to the manager),
or there is a bug and it is a dangling pointer.
