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