lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #49610] Sometimes, autoIP fails to reuse the same addr


From: Roberto Barbieri Carrera
Subject: [lwip-devel] [bug #49610] Sometimes, autoIP fails to reuse the same address
Date: Tue, 15 Nov 2016 12:22:51 +0000 (UTC)
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

URL:
  <http://savannah.nongnu.org/bugs/?49610>

                 Summary: Sometimes, autoIP fails to reuse the same address
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: sebulain
            Submitted on: Tue 15 Nov 2016 12:22:49 PM GMT
                Category: None
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 1.4.1

    _______________________________________________________

Details:

Hello

I use lwIP 1.4.1, but I compared the code and think that the new 2.0 should
show the same fault.

If the machine uses its assigned autoIP address for a while, in which some
network traffic with others is established, and then it restarts, sometimes
the newly assigned autoIP address is not the previous one.

I think I tracked this down to the autoip.c file not exactly implementing what
RFC3927 says.

The code is (autoip.c):

     /* RFC 3927 Section 2.2.1:
      * from beginning to after ANNOUNCE_WAIT
      * seconds we have a conflict if
      * ip.src == llipaddr OR
      * ip.dst == llipaddr && hw.src != own hwaddr
      */
      if ((ip_addr_cmp(&sipaddr, &netif->autoip->llipaddr)) ||
          (ip_addr_cmp(&dipaddr, &netif->autoip->llipaddr) &&
           !eth_addr_cmp(&netifaddr, &hdr->shwaddr))) {
        LWIP_DEBUGF(AUTOIP_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_STATE |
LWIP_DBG_LEVEL_WARNING,
          ("autoip_arp_reply(): Probe Conflict detected\n"));
        printf("autoip_arp_reply(): Probe Conflict detected\n");
        autoip_restart(netif);
      }


But it whould be:


     /* RFC 3927 Section 2.2.1:
      * from beginning to after ANNOUNCE_WAIT
      * seconds we have a conflict if
      * ip.src == llipaddr OR
      * ip.dst == llipaddr && hw.src != own hwaddr
      */
      if ((ip_addr_cmp(&sipaddr, &netif->autoip->llipaddr)) ||
          (ip_addr_isany(&sipaddr) &&
           ip_addr_cmp(&dipaddr, &netif->autoip->llipaddr) &&
           !eth_addr_cmp(&netifaddr, &hdr->shwaddr))) {
        LWIP_DEBUGF(AUTOIP_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_STATE |
LWIP_DBG_LEVEL_WARNING,
          ("autoip_arp_reply(): Probe Conflict detected\n"));
        printf("autoip_arp_reply(): Probe Conflict detected\n");
        autoip_restart(netif);
      }


The RFC states:
   If during this period, from the beginning of the probing process
   until ANNOUNCE_WAIT seconds after the last probe packet is sent, the
   host receives any ARP packet (Request *or* Reply) on the interface
   where the probe is being performed where the packet's 'sender IP
   address' is the address being probed for, then the host MUST treat
   this address as being in use by some other host, and MUST select a
   new pseudo-random address and repeat the process.  

Which is correctly implemented.

But then it says:
   In addition, if
   during this period the host receives any ARP Probe where the packet's
   'target IP address' is the address being probed for, and the packet's
   'sender hardware address' is not the hardware address of the
   interface the host is attempting to configure, then the host MUST
   similarly treat this as an address conflict and select a new address
   as above.  This can occur if two (or more) hosts attempt to configure
   the same IPv4 Link-Local address at the same time.

The code checks this without making sure that the received packet is strictly
a PROBE.

Probes must have the own address set to zero.

Any other node might send an ARP request with this address as the target,
without saying that it wants to use the address. This is normal in IP
exchanges.

A collision happens in this case only when the received packet is actually a
probe.

Kind regards,
Roberto Barbieri Carrera





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?49610>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]