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).
Exposure of this property on D-Bus would be useful for the GUIs to encourage
the users to enter a PIN or push a button.
We'll also use it to decide whether a connection will initiate WPS
enrollment unless the user overrides the default.
- anticipate missing callback/ctx->result
- always invoke the result callback when given
- fix leaking GVariant in disconnect_done()
- fix crash due to non-initialized ctx->result
- pass cancellable to g_dbus_proxy_call()
And some fixes:
- proxy creation may fail. Don't handle it by retrying,
but at least don't access the invalid proxy instance.
- quering "DefaultAdapter" did not take a reference to @self
nor was the operation cancellable. This leads to crash
if the instance gets destroyed early.
And some fixes:
- proxy creation may fail. Don't handle it by retrying,
but at least don't access the invalid proxy instance.
- get_properties_cb() did not take a reference to @self
nor was the operation cancellable. This leads to crash
if the instance gets destroyed early.
Fix two issues of the previous code:
- the D-Bus proxy for the modem manager should not get created
synchronously.
- NMModemManager is a singleton, let it track the name-owner
change and the D-Bus proxy, instead of having one per NMDeviceBt.
Don't do non-trivial initialization in nm_device_bt_init(). At
this point, the object is not yet fully created. As we already have
a constructed() implemented, move the initialization there.
Also, bluetooth plugin uses NMModem from the wwan plugin. Don't
include such a foreign header in a "nm-device-bt.h". Instead, forward
declare what we need.
Most of the functions are strictly related to ModemManager. Their
name should hint to that, so that they are clearly separated from
the ofono functions and general purpose functions.
Same for data fields.
It is often wrong to take a reference to keep the instance alive during
the asynchronous request, because it means the instance cannot be
destroyed as long as the (non cancellable) request is bending.
Fix that for NMModemManager and pass a cancallable along.
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.
src/devices/nm-device-ip-tunnel.c:257:8: warning: Branch condition evaluates to a garbage value
if (local4)
^~~~~~
src/devices/nm-device-ip-tunnel.c:264:8: warning: Branch condition evaluates to a garbage value
if (remote4)
^~~~~~~
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
