[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    zcip, link-local ARP responses
From:       dbextern <db_extern () gmx ! de>
Date:       2015-07-21 12:03:31
Message-ID: trinity-4a04f9a8-b88a-4dd8-bf67-713cb67c8013-1437480211611 () 3capp-gmx-bs38
[Download RAW message or body]

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
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]