From: Ken Sharp <[email protected]> During link-local IP resolution, if a regular ARP request is received during the ARP probe period, it will incorrectly cause a target IP conflict. This then leads to a new IP being picked unnecessarily.
Per RFC 3927, section 2.2.1, we should flag a target IP conflict only if the source IP is null, the target IP matches our IP, and the source hw addr does not match our hw addr. Signed-off-by: Ken Sharp <[email protected]> Signed-off-by: Ben Shelton <[email protected]> --- Note that we reproduced the issue and tested the fix on an ARM A9-based board as follows: - Connect two machines via a crossover cable or on a network with no DHCP server available. - Continuously ping the machine running busybox from the other - Reboot the busybox machine (the one being pinged) - When the busybox machine comes back up it will have a different IP address because of the incorrect target IP conflict networking/zcip.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/networking/zcip.c b/networking/zcip.c index 7314ff8..cdb6bcd 100644 --- a/networking/zcip.c +++ b/networking/zcip.c @@ -506,9 +506,18 @@ int zcip_main(int argc UNUSED_PARAM, char **argv) ) { source_ip_conflict = 1; } + + /* + * According to RFC 3927, section 2.2.1: + * Check if packet is an ARP probe by checking for a null source IP + * then check that target IP is equal to ours and source hw addr + * is not equal to ours. This condition should cause a conflict only + * during probe. + */ if (p.arp.arp_op == htons(ARPOP_REQUEST) + && memcmp(p.arp.arp_spa, &null_ip, sizeof(struct in_addr)) == 0 && memcmp(p.arp.arp_tpa, &ip.s_addr, sizeof(struct in_addr)) == 0 - && memcmp(&p.arp.arp_tha, ð_addr, ETH_ALEN) != 0 + && memcmp(&p.arp.arp_sha, ð_addr, ETH_ALEN) != 0 ) { target_ip_conflict = 1; } -- 2.0.2 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
