Perhaps you should ask this question on the linux net or kernel mailing list. Explain the problem and ask for a solution. These guys can change the behavior of the kernel if needed.
re, wh Am 04.08.2015 12:00, schrieb Sebastian Fett: >> On Tue, Jul 21, 2015 at 2:03 PM, dbextern <[email protected]> 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 > > 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. > > After some time with this problem I think the main reason for this is > that we can not keep the kernel from answering normal ARP requests. And > zcip does not want to double the answer. > And from what has been said in the netdev mailing list keeping bcasts > out of your system is more important than following the specs. > > I have a device (a Dante Brooklyn Modul for an audio stream) that does > exactly what I expected. But that modul does not have any ARP code in > the kernel. I assume it uses the option of completely taking care of ARP > in userspace. > > My current solution is to send an extra ARP response from zcip. That > means two replies to every request (one from zcip, one from kernel). But > that is better for my usecase than not having a bcast answer. And I am > not part of a big network but only a small single purpose one. So nobody > else gets hurt. > >> >> >>> 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... >> > _______________________________________________ > busybox mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/busybox > _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
