udhcpc: DHCPDECLINE on lease renewal when ARP replies are echoed back

[Stormont, Brian]

While using udhcpc, we ran into an issue where udhcpc consistently declines
a lease upon its renewal attempt.  An analysis of the behavior is described
below:

When run with -a (arping), udhcpc performs the RFC 2131 section 3.1
post-DHCPACK ARP check by calling arpping() with safe_mac == NULL. With a
NULL safe_mac, arpping() treats any ARP reply for the tested address as a
conflict, including a reply whose sender hardware address is our own MAC.

Some networks echo a station's own broadcast frames back to it. RFC 5227
section 2.1.1 explicitly calls this out ("many wireless access points may
'rebroadcast' any received broadcast packets to all recipients, including
the original sender itself") and includes a precaution to ignore ARP
packets whose sender hardware address is one of the host's own interfaces.

We hit this with an Aruba access point configured to convert broadcast ARP
requests to unicast ("broadcast filtering" in ARP mode): the AP delivers
the client's own ARP frames back to it. Because the address is still
assigned during a renewal, the host answers the echoed request itself, and
arpping() then sees an ARP reply for the just-ACKed address carrying our
own MAC and reports a conflict, so udhcpc sends a DHCPDECLINE.

This ARP check runs for DHCPACKs in the RENEWING, RENEW_REQUESTED and
REBINDING states as well as REQUESTING, so the client repeatedly declines
the address it is actively using at each renewal (T/2) and churns to a new
address. On the server this also exhausts the pool, since declined
addresses are held down (e.g. ISC Kea's default decline-probation-period
is 24h).

It appears a simple fix for this would be to pass client_data.client_mac as
safe_mac, as udhcpd already does in its arpping() call in dhcpd.c, so a
reply from our own hardware address is not treated as a conflict.

Is there a reason the safe_mac parameter isn't already used for DHCP client
requests?

An alternative (or complementary) fix would be to run the post-ACK ARP
check only on initial acquisition (REQUESTING) and not on renewal/rebind,
since RFC 2131 3.1 frames the check as part of first-time configuration
and the address is already in active use on renewal. The one-line
safe_mac change suggested is a more general fix and also covers the case
where the AP proxy-answers on the client's behalf.

Best regards,
Brian


________________________________
- CONFIDENTIAL-

This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20260708/b6b97a57/attachment.htm>