zcip, link-local ARP responses
walter harms
wharms at bfs.de
Tue Aug 4 11:00:39 UTC 2015
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 <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
>
> 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
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
More information about the busybox
mailing list