n-dhcp4 only supports calling ACCEPT during the GRANTED state. Not during a EXTENDED event. So usually, we would not want to call accept in that case.
And we didn't. During EXTENDED event, we would usually skip ACD (because it's either not enabled or we already have an ACD state for the current address). In that case, in _nm_dhcp_client_notify() we hit the line
if (client_event_type == NM_DHCP_CLIENT_EVENT_TYPE_BOUND && priv->l3cd_curr
&& nm_l3_config_data_get_num_addresses(priv->l3cd_curr, priv->config.addr_family) > 0)
priv->l3cfg_notify.wait_dhcp_commit = TRUE;
else
priv->l3cfg_notify.wait_dhcp_commit = FALSE;and would not set wait_dhpc_commit. That means, we never called _dhcp_client_accept().
For nettools, that doesn't really matter because calling ACCEPT during EXTENDED
is invalid anyway. However, for dhclient that is fatal because we wouldn't reply the
D-Bus request from nm-dhcp-helper. The helper times out after 60 seconds and dhclient
disconnects.
We need to fix that by also calling _dhcp_client_accept() in the case, when we don't need to wait (the EXTENDED case).
However, previously _dhcp_client_accept() was rather peculiar and didn't like to be called in unexpected state. Relax that. Now, when calling accept in an unexpected state, just do nothing and signal success. That frees the caller from the complexity to understand when they must/must not call accept.
https://bugzilla.redhat.com/show_bug.cgi?id=2109285
Fixes: 156d8421 ('dhcp/dhclient: implement accept/decline (ACD) for dhclient plugin')