lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #55433] LwIP 2, IPv6, ANYADDR, Site-local Multicast an


From: Grant Erickson
Subject: [lwip-devel] [bug #55433] LwIP 2, IPv6, ANYADDR, Site-local Multicast and Source Address Selection
Date: Wed, 9 Jan 2019 19:20:21 -0500 (EST)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

URL:
  <https://savannah.nongnu.org/bugs/?55433>

                 Summary: LwIP 2, IPv6, ANYADDR, Site-local Multicast and
Source Address Selection
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: marathon96
            Submitted on: Thu 10 Jan 2019 12:20:20 AM UTC
                Category: IPv6
                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: git head

    _______________________________________________________

Details:

I am presently working on extensions to the Weave Inet IPv4/IPv6 portability
layer to add full IPv4/IPv6 join/leave group multicast support
<https://github.com/openweave/openweave-core/issues/115>.

I have working functional tests against BSD sockets that work well on Linux
and Mac OS X. In running the same functional tests against LwIP, I’ve
encountered what I believe to be a bug in one of two places.

For IPv6, the functional test uses several IPv6 site-local scoped multicast
address groups sent from several nodes with only a link-local address and
bound to the interface with that LLA. On sockets, we see that the LLA is
selected as the source address. On LwIP, using top-of-tree, we see the
any/unspecified address (assigned as address index 1 on the interface) as the
selected source. This seems incorrect or at least inconsistent.

To address this, assuming the bug / issue is in ip6_select_source_address, the
patch that fixed the issue and makes the behavior consistent with Linux and
Mac OS X and, by my read of RFC 6724 Section 5, still RFC-compliant is (see
also attached):

--- a/src/core/ipv6/ip6.c
+++ b/src/core/ipv6/ip6.c
@@ -281,6 +281,12 @@ ip6_select_source_address(struct netif *netif, const
ip6_addr_t *dest)
     }
     /* Determine the scope of this candidate address. Same ordering idea. */
     cand_addr = netif_ip6_addr(netif, i);
+
+    if (ip6_addr_isany(cand_addr) || ip6_addr_ismulticast(cand_addr)) {
+        LWIP_DEBUGF(IP6_DEBUG | LWIP_DBG_LEVEL_WARNING, ("unspecified /
multicast address assigned as unicast address on %c%c%u\n", netif->name[0],
netif->name[1], netif->num));
+        continue;
+    }
+
     if (ip6_addr_isglobal(cand_addr)) {
       cand_scope = IP6_MULTICAST_SCOPE_GLOBAL;
     } else if (ip6_addr_islinklocal(cand_addr)) {

Now, it is also possible that the any/specified address on the interface
should never be marked IP6_ADDR_PREFERRED; however, I know that is a valid
source for some ND6 DAD use cases, so perhaps that assignment on the interface
is intentional. However, if not, then the bug lies elsewhere perhaps and the
patch to ip6_select_source_address is unneeded, though probably still good
defense.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 10 Jan 2019 12:20:20 AM UTC  Name:
ip6_select_source_address-anyaddr-fix.patch  Size: 847B   By: marathon96
Proposed fix for anyaddr issue in ip6_select_source_address
<http://savannah.nongnu.org/bugs/download.php?file_id=45924>

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?55433>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

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