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>
When the PendingActivation removal changes landed, it required all
connections to be in a device's AvailableConnections property. Of
course since hidden networks don't broadcast the SSID, there's no
way to match them up with connections and put them into the
AvailableConnections property, so this was just plain broken.
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'.
Replace '\r' and '\n' chareacter with a space in the configuration.
libteamdctl sends the config to team daemon using its usock interface that
separates parameters with '\n'.
Related: rh #1051517
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.
nmcli con add type team-slave ifname em2 master team-master0
nmcli con add type team-slave ifname em2 master id/team-master0
It helps to disambiguate values for cases where they may overlap,
e.g. "team0" -> "ifname/team0" or "id/team0"
nmcli con add type *-slave ifname em1 master <ifname|UUID|name>
'master' property of 'connection' setting has to be either interface name or
connection UUID of master connection. However, to make nmcli more convenient
for users, we also allow specifying connection name and translating it to UUID
automatically.
https://bugzilla.redhat.com/show_bug.cgi?id=1057494
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.
