zcip, link-local ARP responses

[dbextern]

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? Even the windows misbehaviour would not matter if the one answering embedded device would send a broadcast ARP response.
Does anyone else have that problem and already found a solution?
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?
 
We are using busybox 1.12.4. There are a few patches for zcip up to 1.23, but they all seem unrelated to this issue.
 
I hope that wasn't a too confusing description of my problem.
 
Regards,
Sebastian