zcip, link-local ARP responses

[Denys Vlasenko]

On Tue, Jul 21, 2015 at 2:03 PM, dbextern <db_extern at gmx.de> wrote:
> Hello!
>
> 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


> And a more general question: when I handle an ARP packet in zcip, how does the kernel know not to work on it as well?

I don't know...