buglwIP - A Lightweight TCP/IP stack - Bugs: bug #55433, LwIP 2, IPv6, ANYADDR, Site-local...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #55433: LwIP 2, IPv6, ANYADDR, Site-local Multicast and Source Address Selection

Submitted by:  Grant Erickson <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 Planned Release:  None
lwIP version:  git head

Thu 14 Mar 2019 04:11:32 PM UTC, comment #1: 

Any further thoughts on this issue?

Grant Erickson <marathon96>
Thu 10 Jan 2019 12:20:20 AM UTC, original submission:  

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.

Grant Erickson <marathon96>

 

Attached Files
file #45924:  ip6_select_source_address-anyaddr-fix.patch added by marathon96 (847B - application/octet-stream - Proposed fix for anyaddr issue in ip6_select_source_address)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by marathon96 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-10 marathon96 Attached File- => Added ip6_select_source_address-anyaddr-fix.patch, #45924

    Back to the top


    Powered by Savane 3.5