On Tue, Aug 4, 2015 at 12:00 PM, Sebastian Fett <db_ext...@gmx.de> wrote: >> On Tue, Jul 21, 2015 at 2:03 PM, dbextern <db_ext...@gmx.de> wrote: >>> For our link local functionality I'm using udhcpc together with zcip out >>> of busybox on a Blackfin BF-537 CPU without MMU. >>> >>> The base functionality is there. >>> But when I connect two networks with stable IP addresses, and both >>> networks had the same IP(s) in them, the conflict stays unresolved. >>> My setup is one master PC or MAC and several embedded boards. >>> >>> What I would expect (following RFC3927 >>> https://tools.ietf.org/html/rfc3927#page-10[https://3c.gmx.net/mail/client/dereferrer?redirectUrl=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3927%23page-10]; >>> chapter 2.x and 4) is that after a while the ARP messages will resolve the >>> problem because the still running zcip sees ARP responses on it's own IP and >>> reacts accordingly. >>> What really happens is: >>> * Windows only sends broadcast ARP requests as long as it never got an >>> answer. After that there is only unicast. And the requested device answers >>> with a unicast as well. >>> * the MAC always sends broadcasts. And both embedded devices with the >>> conflicting IP answer. But with a unicast ARP reply to the MAC. >>> >>> As I understand the specification (last paragraph in chapter 2.5) then >>> all ARP messages between devices with link local addresses should be link >>> layer broadcasts. >>> Did I get that right? And if yes, why does zcip not follow that rule? >> >> >> zcip does use bcast for all packets it sends: >> >> # tcpdump -nliwlan0 -s0 -vv -e arp >> tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size >> 65535 bytes >> <zcip runs> >> 02:49:51.078369 00:04:e2:64:23:c2 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 42: arp who-has 169.254.194.171 tell 0.0.0.0 >> 02:49:52.391711 00:04:e2:64:23:c2 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 42: arp who-has 169.254.194.171 tell 0.0.0.0 >> 02:49:54.254628 00:04:e2:64:23:c2 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 42: arp who-has 169.254.194.171 tell 0.0.0.0 >> 02:49:55.305731 00:04:e2:64:23:c2 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 42: arp who-has 169.254.194.171 (00:04:e2:64:23:c2) >> tell 169.254.194.171 >> 02:49:57.307788 00:04:e2:64:23:c2 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 42: arp who-has 169.254.194.171 (00:04:e2:64:23:c2) >> tell 169.254.194.171 >> 02:49:59.309844 00:04:e2:64:23:c2 > ff:ff:ff:ff:ff:ff, ethertype ARP >> (0x0806), length 42: arp who-has 169.254.194.171 (00:04:e2:64:23:c2) >> tell 169.254.194.171 > > > Thanks for looking into that. > > These are the probing and announcement messages from zcip. They need to be > and are bcasts. > What it does not do is answer normal ARP requests with a broadcast. Which is > specified in RCF3927 as the right thing to do.
Looking at the code, it should answer to them: // packets arriving, or link went down case 1: ... switch (state) { ... case MONITOR: // If a conflict, we try to defend with a single ARP probe. if (source_ip_conflict) { VDBG("monitor conflict -- defending\n"); state = DEFEND; timeout_ms = DEFEND_INTERVAL * 1000; arp(/* ARPOP_REQUEST, */ /* ð_addr, */ ip, ð_addr, ip); } break; The call to arp() in the code snippet above should send a broadcast ARP probe. _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox