zcip, link-local ARP responses

[Denys Vlasenko]

On Tue, Aug 4, 2015 at 12:00 PM, Sebastian Fett <db_extern at gmx.de> wrote:
>> On Tue, Jul 21, 2015 at 2:03 PM, dbextern <db_extern at gmx.de> wrote:
>>> 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.

Looking at the code, it should answer to them:

                // packets arriving, or link went down
                case 1:
...
                switch (state) {
...                      case MONITOR:
                                // If a conflict, we try to defend
with a single ARP probe.
                                if (source_ip_conflict) {
                                        VDBG("monitor conflict -- defending\n");
                                        state = DEFEND;
                                        timeout_ms = DEFEND_INTERVAL * 1000;
                                        arp(/* ARPOP_REQUEST, */
                                                /* &eth_addr, */ ip,
                                                &eth_addr, ip);
                                }
                                break;

The call to arp() in the code snippet above should send a broadcast
ARP probe.