NRF Connect SDK missing mesh-local UDP6 broadcasts from openthread

RE: NRF Connect SDK missing mesh-local UDP6 broadcasts from openthread

Edvin — Wed, 06 Jan 2021 08:40:27 GMT

Thank you as well! I noted the Thread team about your Zephyr issue and pull request. They will look into this from Monday, and figure out how to make sure that either this zephyr patch or a workaround is implemented in our future releases.

Thank you for bringing this bug up.

Best regards Edvin

RE: NRF Connect SDK missing mesh-local UDP6 broadcasts from openthread

frazieje — Wed, 06 Jan 2021 02:17:24 GMT

Thank you for the reply Edvin. I am aware Nordic does not write openthread in zephyr. At the time I submitted the original ticket, I thought the issue may be tied to NCS implementation since I was seeing it was reproducible in NCS but not in Zephyr. However after further looking, I am confirming the issue is actually with Zephyr.

Yesterday I recorded a Zephyr issue to highlight the problem. I think the fix belongs there in the openthread shim layer of Zephyr. I have opened a pull request to resolve the issue (using my last suggestion above to join any mesh-specific openthread multicast addresses), and am awaiting review from Zephyr developers. See the issue and PR for details

Thank you

RE: NRF Connect SDK missing mesh-local UDP6 broadcasts from openthread

Edvin — Tue, 05 Jan 2021 07:26:03 GMT

Hello,

Thank you for the information. I ran this by our Thread team, and they say that your suggested workarounds seems reasonable. They will look into this in more details, and whether there is a reasonable way to patch this in NCS. Please note that it is not Nordic Semiconductor that writes the openthread implementation in Zephyr. Perhaps you can file a bug report there as well. I guess our Thread team will do so, but it may be pushed into an earlier release if reported from several holds.

Best regards,

Edvin

RE: NRF Connect SDK missing mesh-local UDP6 broadcasts from openthread

frazieje — Sun, 03 Jan 2021 21:43:37 GMT

After doing more investigation, i found that a recent change to Zephyr causes the above change in behavior. This change is included with the current (1.4.99) NRF Connect SDK fork of Zephyr, but the Zephyr version I was building my original app against was older and did not have this change yet.

This Zephyr commit adds code to net_ipv6_input() to filter multicast messages coming from lower layers, specifically those destined for a non all-nodes multicast address that is not joined.

This change is made to reflect IPV6 Addressing RFC 4291 Section 2.7.1 and 2.8, which specifies that a host must respect all-nodes addresses FF01::1 and FF02::1, as well as any joined multicast group addresses. This differs from Thread which also specifies FF03::1 as a mesh-local all-nodes multicast address.

The above change caused my issue of packet drop when using Zephyr's bsd sockets api on a mesh L2, because Zephyr doesn't respect FF03::1 as an all-nodes multicast address by default, and multicast addresses added to Zephyr through the openthread integration are not joined by default, so the packets are dropped.

a few ways around this:

Use OpenThread API directly instead of bsd sockets api - Not ideal for portability but works around issue
Create and join an application-specific multicast group from all application nodes - Preferable solution
Application itself can call net_if_ipv6_maddr_join() manually to join FF03::1 and other desired thread-specific multicast addresses - works but seems improper to 'join' a reserved all-nodes address
Zephyr's net_ipv6_input() multicast packet filtering could be modified to exempt FF03::1 from packet drop. could be ok because zephyr has function net_ipv6_is_addr_mcast_mesh() which could be used to prevent drop of multicast packets from mesh-local all-nodes addresses, but this seems improper because IPV6 implementation shouldn't know about mesh addresses
Zephyr openthread bridge could be modified to call net_if_ipv6_maddr_join() on FF03::1 by default during the process of adding an openthread multicast address to Zephyr - this also works but again involves calling join on a reserved all-nodes address which feels strange.

Any thoughts from Nordic on this issue and best way to solve it for NRF Connect SDK applications?