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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
