udhcpd - FEATURE_UDHCPC_ARPING broken?

Denys Vlasenko vda.linux at googlemail.com
Sun May 1 01:30:50 UTC 2011


On Tuesday 26 April 2011 10:16, Andreas Fertig wrote:
> Hello,
> 
> I ran into problems lately with using udhcpd with
> ENABLE_FEATURE_UDHCPC_ARPING enabled. Most times the DHCP-client uses
> the IP-address given by the server, but in some cases it was rejected
> with a DHCP-DECLINE message. I checked the code and found that in
> dhcpc.c:1417 the check is performed.
> There is a call to arpping() which checks whether or not the IP given by
> the server is in use.
> 
>    if (!arpping(packet.yiaddr,
>            NULL,
> 	   (uint32_t) 0,
> 	   client_config.client_mac,
> 	   client_config.interface)
>    ) {
>         bb_info_msg("Offered address is in use "
> 	"(got ARP reply), declining");
> 	send_decline(xid, server_addr, packet.yiaddr);
>         ...
> 
> Now look at the second parameter of arpping() which is NULL. If you look
> into the code of arpping.c you can see that this is the parameter
> safe_mac, a pointer in fact.

This is correct.

safe_mac is a MAC of the machine we are trying to give the lease to.
If the machine _already_ has this IP configured, it _will_ respond
to ARPs, but it doesn't mean that this lease is taken by somebody else.
So, if ARP reply contains MAC == safe_mac, it is not classified as
"someone else responded to ARP request".

If safe_mac is NULL, then we don't have such MAC, and any ARP reply
means "someone else responded to ARP request".


> In arpping.c:115 a check is performed, 
> whether or not safe_mac is NULL, if not a memcmp is done:
> 
>    if (!safe_mac || memcmp(safe_mac, arp.sHaddr, 6) != 0)
> 	rv = 0;
> 
> If safe_mac is NULL, the if-statement will always be true and reset rv
> from 1 to 0 which leads the client send its DECLINE. I asume this is not
> the intend.

No, it's right. We got ARP reply, safe_mac is NULL, thus
"someone else responded to ARP request", and we can't use this IP.

-- 
vda


More information about the busybox mailing list