Note that:
- carrier_changed_notify() has only one implementation: NMDeviceEthernet
to call get_link_speed() when carrier comes back.
- currently, calling carrier_changed_notify() with carrier=FALSE
has no effect, because NMDeviceEthernet only acts on carrier=TRUE.
- when carrier appears, nm_device_set_carrier() will call
carrier_changed() right away. We only call carrier_changed()
with carrier=TRUE only at one place. The change merley moves
carrier_changed_notify() out of the function. Apart from
that it has no effect.
- when carrier disappears, previoulsy we would delay action for
4 seconds. Hence, we would delay carrier_changed_notify() as well
-- although it has no effect.
The last point is at least ugly. Fix it by moving
carrier_changed_notify() to nm_device_set_carrier().
If there is value in such a helper function (there is), then
it should go alongside the other nm_connection_get_setting*()
helpers. NMDevice is already large enough.
The plugins may use stuff from core, but not the other way around.
Including "bluetooth/nm-bluez-common.h" is wrong.
The UUID argument is always "nap" in the NAP case. We don't need
the flexibility that it might be anything else. Just drop it.
As far as NMDevice is concerned, it anyway wouldn't (or shouldn't
know what the uuid is. It says register, and NMBluez5Manager should
figure out the details.
Changes:
- merge reserve_shared_ip() into shared4_new_config().
shared4_new_config() needs to register release_shared_ip(). However, it
wrongly would always register release_shared_ip(), even for user-supplied
addresses. To fix that, we would need yet another argument to
reserve_shared_ip() and coupling it even more with shared4_new_config().
At that point, it's cleaner to just merge the two functions.
- only create the shared_ips hash when needed, and delete it when
it's empty. The idea is, that NetworkManager possibly runs for a long
time, and most of the time no shared connection is active. Just clean
up the empty hash while we don't need it.
Otherwise a device which was set as unmanaged (updated to the REMOVED
internal sys-state) will never update its own sys-state if later set
back as managed.
Manage either when setting explictly the device to managed either when
just upping a connection on an unmanaged device.
On cleanup, unconditionally release a device from its master if the
link is missing or it doesn't have a master, otherwise the master
would later try to release the slave, hitting the following assertion:
"nm_platform_link_release: assertion 'slave > 0' failed"
#0 g_logv
#1 g_log
#2 g_return_if_fail_warning
#3 nm_platform_link_release
#4 release_slave
#5 nm_device_master_release_one_slave
#6 slave_state_changed
#7 ffi_call_unix64
#8 ffi_call
#9 g_cclosure_marshal_generic
#10 g_closure_invoke
#11 signal_emit_unlocked_R
#12 g_signal_emit_valist
#14 _set_state_full
#15 nm_device_state_changed
#16 nm_device_unrealize
#17 _platform_link_cb_idle
#18 g_main_context_dispatch
#19 g_main_context_dispatch
#20 g_main_context_iterate
#21 g_main_loop_run
#22 main
Fixes: 9e8218f99ahttps://bugzilla.redhat.com/show_bug.cgi?id=1448907
Use nm_device_get_ip_ifindex() to obtain the right ifindex for the
device. Fixes the following:
nm_platform_ip4_address_get_all: assertion 'ifindex > 0' failed
#0 _g_log_abort () from target:/lib64/libglib-2.0.so.0
#1 g_logv () from target:/lib64/libglib-2.0.so.0
#2 g_log () from target:/lib64/libglib-2.0.so.0
#3 nm_platform_ip4_address_get_all (self=self@entry=0x1181020, ifindex=ifindex@entry=0) at src/platform/nm-platform.c:2640
#4 nm_ip4_config_capture (platform=0x1181020, ifindex=ifindex@entry=0, capture_resolv_conf=capture_resolv_conf@entry=0) at src/nm-ip4-config.c:271
#5 ip4_config_merge_and_apply (self=self@entry=0x1254a70, config=config@entry=0x0, commit=commit@entry=1) at src/devices/nm-device.c:5447
#6 activate_stage5_ip4_config_commit (self=0x1254a70) at src/devices/nm-device.c:8299
#7 activation_source_handle_cb (self=0x1254a70, family=family@entry=2) at src/devices/nm-device.c:4421
#8 activation_source_handle_cb4 (user_data=<optimized out>) at src/devices/nm-device.c:4358
#9 g_idle_dispatch () from target:/lib64/libglib-2.0.so.0
#10 g_main_context_dispatch () from target:/lib64/libglib-2.0.so.0
#11 g_main_context_iterate.isra () from target:/lib64/libglib-2.0.so.0
#12 g_main_loop_run () from target:/lib64/libglib-2.0.so.0
#13 main (argc=<optimized out>, argv=<optimized out>) at src/main.c:435
Fixes: a21b8882cc
with the rework in commit #87a3df2e572ed47b5f76f6d1cad63ce622296e21
the check of the return value of _device_activate () is no more needed.
Remove useless check and var.
ip link add name $'d\xccf\\c' type dummy
Use nm_utils_str_utf8safe_escape() to sanitize non UTF-8 sequences
before exposing them on D-Bus. The operation can be reverted client
side via nm_utils_str_utf8safe_unescape() or simply g_strcompress().
Note that this preserves all valid UTF-8 sequences as-is, with exception
of the backslash escape character and ASCII control characters. Thus, this
is a change in behavior for strings that contain such characters.
Note that nmcli is not changed to somehow unescape the string before
printing. As the string is not valid UTF-8 (or contains ASCII characters
that need escaping), they are not printable as-is, so unescaping before
printing makes little sense.
If the platform signaled that the external configuration changed (and
thus update_ipX_config() is scheduled) and we are doing a commit of
the new configuration, update priv->ext_ipX_config. Without this, the
commit will remove addresses added externally but not yet captured in
the external configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1449873
platform: signal: link changed: 2: eth0 <DOWN;broadcast,multicast> mtu ...
...
device[0x7f90c29c64d0] (eth0): bringing up device
...
platform: signal: link changed: 2: eth0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu ...
...
device (eth0): link connected
...
device[0x7f90c29c64d0] (eth0): add_pending_action (2): 'carrier wait'
Note how we schedule the pending action 'carrier-wait', although the device
already has carrier. That means, the pending action will not be removed
until timeout, 5 seconds later.
Avoid scheduling 'carrier-wait' if we already have carrier.
However, don't just add the pending action 'carrier-wait' only during
nm_device_bring_up(). Instead, always schedule the carrier_wait timeout.
This gives a grace period during which we keep setting 'carrier-wait' whenever
we have no carrier. This should prevent two cases:
- during nm_device_bring_up() the platform state might not yet have
caught up. If we don't add the pending action there, we will add
it a moment later when carrier goes away.
- bringing the interface up might cause carrier to get lost for a
moment (flapping). If that happens within the timeout, also add the
pending action.
nm_device_set_carrier_from_platform() is only called from two places.
- both check for NM_DEVICE_CAP_CARRIER_DETECT, so move that check
inside the function.
- drop the logging in realize_start_setup(). nm_device_set_carrier() already
does logging.
- always set the fake carrier in nm_device_set_carrier_from_platform().
For the fake carrer, we anyway expect it to be already TRUE in most
case, so usually this should have no effect.
Also emit a property changed signal. That is necessary to refresh the
D-Bus property.
Adding/Removing a pending action with assert_not_yet_pending/
assert_is_pending means that we expect that no action is taken.
Downgrade the logging level in those cases to <trace>.
Don't give the subclass the ability to override the parents
behavior. The parent implementation is not intended to allow
for that. Instead, restrict the flexibility of how the virtual
function integrates with the larger picture. That means, the
virtual function is only called at one place, and there is only
one implementation in NMDeviceEthernet (and it doesn't really
matter whether the implementation chains up the parent implementation
or not).
It's not the correct thing to do, but is the same behavior we've done
previously.
DAD is not even going to start until there's carrier and the client would
just wait indefinitely. Ideally, the client would choose not to waiat, but
it currently there's no way the client would discover what is going on.
https://bugzilla.redhat.com/show_bug.cgi?id=1446367
Set the @was_active flag for external activations with DHCP, so that
DHCP is retried multiple times in case of failure, as we do for
managed connections when the lease expires and for assumed
connections.
Fixes test: renewal_gw_after_dhcp_outage_for_assumed_var1
Fixes: e3113fdc4b
We check the return value of _get_stable_id(); when it is NULL
priv->ndisc would stay NULL too and we would crash when dereferencing
@error.
Actually, _get_stable_id() can never return NULL, so replace the check
with an assertion.
Most of the IPv6 methods require a non-tentative link local address
configured on the interface; we look at priv->ip6_config to determine
if such address exist. If the configuration is out-of-sync, we may
proceed with configuration when the link-local address does not exist
or is still tentative, especially because we toggle the "disable_ipv6"
sysctl parameter just before, which clears all IPv6 addresses on the
interface.
Ensure that priv->ext_ip6_config_captured is up-to-date before
continuing with the IPv6 configuration, and use it to determine
whether suitable addresses are present.
Fixes test: @ipv6_set_ra_announced_mtu
Fixes: 8f4caab601
update_ip6_config() also removes addresses and routes no longer
present externally from the configuration, so it can't be called
before the changes are committed.
This reverts commit 8f4caab601.
Most of the IPv6 methods require a non-tentative link local address
configured on the interface; we look at priv->ip6_config to determine
if such address exist. If the configuration is out-of-sync, we may
proceed with configuration when the link-local address does not exist
or is still tentative, especially because we toggle the "disable_ipv6"
sysctl parameter just before, which clears all IPv6 addresses on the
interface.
Ensure that priv->ip6_config is up-to-date before continuing with the
IPv6 configuration.
Fixes test: @ipv6_set_ra_announced_mtu
nm_device_update_firewall_zone() would only reconfigure the firewall
zone when the device is fully activated. That means, while the device
is activating, changing the firewall zone is not working. Activation
might take a long time with DHCP, or with master devices waiting
for their slaves.
For example:
nmcli connection add type team con-name t-team ifname i-team autoconnect no
nmcli connection up t-team
Note how t-team/i-team is waiting for a slave device. During stage3,
we already set firewall.zone to default.
nmcli connection modify t-team connection.zone external
Note how changing the firewall zone does not immidiately take
effect. Only later, during IP_CHECK state the firewall zone
is reset -- but only for devices with differing ip_ifindex.
https://bugzilla.redhat.com/show_bug.cgi?id=1445242
For regular devices that don't have a separate ip_iface/ip_ifindex,
the ip_ifindex is left at zero. Hence, the condition is always
true and does not work as intended, resulting in setting the
firewall zone twice.
Fixes: 7cf5c326bc
When a DHCP connection is active and the DHCP server is temporarily
unreachable, we restart DHCP for some times before failing the
connection. From the user point of view, restarting NM (and thus
assuming the existing connection) should not change this behavior.
However, if NM is restarted while the server is temporarily down, at
the moment we immediately fail because we consider the DHCP
transaction our first try. Fix this by restoring the multiple tries
when we detect that DHCP was active before because the connection is
assumed.
We call nm_device_activate_stage3_ipX_start() in various places,
e.g. after a carrier change or when a master enslaves a new device to
configure IP for the device. If the device is a slave in state
IP_CONFIG, this makes it transition to IP_CHECK, while it should stay
in IP_CONFIG until the master becomes ready. When the master is ready,
it will move slaves directly to SECONDARIES, skipping IP configuration
entirely.
The dad_counter is hashed into the resulting address. Since we
want the hashing to be independent of the architecture, we always
hash 32 bit of dad_counter. Make the dad_counter argument of
type guint32 for consistency.
In practice this has no effect because:
- for all our (current!) architectues, guint is the same as
guint32.
- all callers of nm_utils_ipv6_addr_set_stable_privacy() keep
their dad-counter argument as guint8, so they never even pass
numbers larger then 255.
- nm_utils_ipv6_addr_set_stable_privacy() limits dad_counter
further against RFC7217_IDGEN_RETRIES.
