krish2718
commented
2 years ago Spoke too early, my colleague has pointed out this already exists and implemented using NET_EVENT_ETHERNET_CARRIER_OFF/ON and can be triggered by net_eth_carrier_off/on (though there doesn't seem to be any registered users for this) and we also have the interface events NET_EVENT_IF_DOWN/UP triggered by net_if_down/up.
Also, the DHCP client even has a callback registered dhcpv4_iface_event_handler, so, this should be enough to address above two bugs.
DHCP client starts at boot and keeps retrying for DHCP lease using a capped exponential backoff algorithm. But till the underlying L2 link is UP, this doesn't work, and even for a positive case of L2 link being UP during boot, we still loose a few retries and end up with higher delay in triggering a lease request (DHCP discover).
Linux has a mechanism of L2 drivers intimating network stack about their
carrierstatus usingnetif_carrier_*APIs, this triggers a netlink multicast to all the interested applications including DHCP client which can then use this knowledge to trigger DHCP actions (send discover, release etc).To the point in Question, using nrf700x L2 Wi-Fi we see a significant delay in getting DHCP lease as wifi connection is initiated after the DHCP client has reach maximum exponential backoff (64secs as per
RFC2131 4.1), this is not quite acceptable.The second bug here is that once the DHCP client gets a lease, it doesn't release, even when L2 has reconnected. E.g., see below steps
The same solution applies to both, once we make DHCP/Networking stack L2 carrier aware, then we can tie DHCP release/discover to the L2 link/carrier status and both above problems i.e., delay and re-leasing (release + discover) are solved.
For now, we are using below workaround to get by