nm_device_deactivate() is used when deactivating a device, but also
when initializing it when it is first managed. Rename it to
nm_device_cleanup(), and use a different log message ("preparing
device") in the NM_DEVICE_STATE_REASON_NOW_MANAGED case.
If a device had its carrier ignored, and did not have a carrier on startup,
then NetworkManager would not re-check autoconnect connections when the
device's carrier appeared. Because ignore-carrier devices are always
in DISCONNECTED state when they are managed, the nm-device.c::carrier_changed()
code essentially did nothing when the carrier appeared. It needs to
also trigger an auto-activation recheck signal when the carrier appears
to ensure that now-valid connections (like those that require DHCP or
IPv6) can be auto-activated.
When a VPN goes down, like at suspend, and the link has already
disappeared, the new platform logging code tries to print the
link information using a link object with only the ifindex filled
in. When adding/removing/changing links, internal code often fills
in just the ifindex (becuase that's all you need). Thus
to_string_link() will always fail if that operation fails.
at platform/nm-linux-platform.c:688
at platform/nm-linux-platform.c:1835
at vpn-manager/nm-vpn-connection.c:274
Work around that for now and live with the warnings until
we decide what to actually do about to_string_link().
Devices disconnected explicitly by user should stay disconnected, preventing
auto-connecting until manual request.
Introduction of NM_DEVICE_STATE_DEACTIVATING state broke this feature.
disconnect_cb() correctly set autoconnect device property to FALSE, however
nm_device_state_changed() put it to TRUE again. Thus only the active connection
was blocked instead of the whole device.
https://bugzilla.gnome.org/show_bug.cgi?id=726239
When we kill a client, we usually get a DHCP event afterwards that cannot
be associated with the client anymore (because we forgot about its PID).
Do not log a warning in that case, but only a debug message.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When an interface gets renamed, we first receive a libnl update with
the changed interface name.
This results in the following chain of calls:
- event_notification()
- announce_object()
- link_init()
- link_extract_type()
- link_type_from_udev()
Then link_type_from_udev() looks up the name in the udev data (getting
the previous name, because we did not yet recieve the udev notification)
and passes the name to wifi_utils_is_wifi(), which eventually calls
nm_platform_link_get_ifindex() -- doing a lookup by the old name.
Fix this, by passing the ifname from libnl to link_type_from_udev().
Also, change hack_empty_master_iff_lower_up() because it is called
from event_notification(), at a moment when the link cache possibly
does not yet know the ifindex -- so that the call chain to
link_extract_type(), link_type_from_udev(), wifi_utils_is_wifi()
again might lead to lookup for something that does not yet exist.
Note, that in this case the name would not yet exist, because we
did not yet put the libnl object into the link cache.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Because not all clients set the 'hidden' property in a connection for
hidden/non-SSID-broadcasting networks, they may not show up in
the device's available-connections property. After the
PendingActivation object removal, all activations require the
connection to be in available-connections, and thus hidden SSID
networks could not be activated.
Unfortunately check_connection_available() is used both during
activation and to populate the available-connections array, but we
only want to special-case activation paths, and still ensure that
SSIDs not found in the scan list are not in available-connections.
To make it clear this is a WiFi only hack, and that we should
remove it at some point in the future, create another class method
specifically for hidden WiFi and use that in activation paths to
special-case hidden WiFi connection activation.
If an AP object is not given, and no compatible AP can be found
in the scan list, the AP is most likely not broadcasting its SSID
and should be marked as 'hidden'.
The config is owned by teamd and will be freed by teamdctl_free(). Also use
teamdctl_config_get_raw_direct() instead of teamdctl_config_get_raw() to be
sure we have current data.
Notes and changes by jklimes:
- fix reading TeamPort without TYPE=Ethernet
- fix tests
Ideally this should be solved on initscripts side. But teamd doesn't want to do
any changes to initscripts, so we make a workaround here.
https://bugzilla.redhat.com/show_bug.cgi?id=1074160
When an existing connection profile has IPv6 method 'ignore', NM doesn't simply
care about IPv6. Thus we should allow matching such a profile to devices with
just a link-local address.
The example can be a simple configuration like this:
/etc/sysconfig/network-scripts/ifcfg-ens3:
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="aa17d688-a38d-481d-888d-6d69cca781b8"
BOOTPROTO=dhcp
HWADDR="52:54:00:32:77:59"
TYPE=Ethernet
NAME="ens3"
https://bugzilla.redhat.com/show_bug.cgi?id=1073824
Instead of only passing the ifindex to the callback, pack
additional data. This allows for better logging by also
writing the g_idle_add id which allows to associate the scheduling
with cancel calls.
Also, this fixes that the callback could not clear the
@delete_on_deactivate_id of the device, so that a following
delete_on_deactivate_unschedule() would think that there is
still something to cancel.
Signed-off-by: Thomas Haller <thaller@redhat.com>
check_timestamps() was mixing up absolute and relative timestamps,
which meant that IPv6 expiration checks more-or-less stopped happening
after a while, allowing expired IPv6 routes, etc, to remain applied.
This fixes queued activation request to be aborted because the software
device gets removed before the device reaches the PREPARED state.
This happens, because when the previous connection disconnects, the
device will schedule its removal.
https://bugzilla.redhat.com/show_bug.cgi?id=1073015
Signed-off-by: Thomas Haller <thaller@redhat.com>
We kill the dhcp process synchronously, so waiting for up to 3 seconds
is really painful. Instead, give the client only 0.5 to terminate before
sending SIGKILL.
The proper solution would be to kill it asynchronously and dhcp manager
making sure that it does not start a new instance before the old process
was killed.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since vxlan is new-ish, and vxlan IPv6 support in particular has only
been in the kernel since 3.11, we include our own copy of the vxlan
netlink constants rather than depending on the installed headers.
The nla_policy struct declarations for GRE, etc, were originally
copied from the kernel sources, where they used tabs to align the "="
columns. Fix them to use spaces instead.
NMDeviceGre and NMDeviceMacvlan didn't deal with the possibility that
the virtual device might be created before its parent's NMDevice is
created. Mostly fix this by having them put off the call to
nm_manager_get_device_by_ifindex() until someone actually requests the
device.
This is not perfect; if someone listening to notify::parent checks
right away, they may find that the parent property is still NULL, and
notify::parent will not be emitted again when it gets filled in. But
it's better than what's there now, when parent would remain NULL
forever in this case.
NMDeviceVeth did not have this problem, but it did have another
possible problem because it wasn't cleaning up its weak references
properly.
When activating a master, it reenables the auto activation of slave
connections for this master. Do not only match the device name, but also
check the connection UUID.
Signed-off-by: Thomas Haller <thaller@redhat.com>
f3c2851c (port NMAgentManager, etc, to use NMAuthSubject) made it
unnecessary for callers to nm_settings_connection_get_secrets() to
decide whether to filter agents by UID or not, but NMVPNConnection was
still doing it itself anyway.
Before, when adding a gateway route to a destination within the
current subnets, it would be skipped because of the wrong assumption
that we already have a prefix route to that destination.
This assumption is wrong, because we want to reach the more specific
subnet via a gateway and not directly on the link.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The IPv6 spec say that when performing SLAAC, you should sent at most
3 RSes, at least 4 seconds apart. We were previously continuing to
send RSes forever if we didn't get back a response. Fix that.
(Since the fix involves making nm-lndp-rdisc use NMPlatform, it was
necessary to rewrite the rdisc test program a bit, to not try to
include <net/if.h>, which is incompatible with <linux/if.h>.)
