Zephyr / UDP bind not working

637 views
Skip to first unread message

Ken Bass

unread,
Apr 21, 2021, 5:01:42 PM4/21/21
to openthread-users
I am running Openthread under Zephyr (within Nordic Connect SDK).

I am trying to receive an IPv6 multicast datagram via the openthread API (not BSD sockets). This for this particular application I'd like to get the RSSI. I am subscribed to 'ff02::fd' (made up by me) multicast and the UDP callback is never invoked. Originally I tried 'ff02::2' since that is already subscribed but same problem.

Something inside openthread (or zephyr) is filtering this. Under 'counters mac' I see responseRxDestAddrFiltered increment on the receipt of the UDP multicast datagram.

All I really want is the RSSI of the incoming packet but apparently this is not available with Zephyr BSD sockets. So I have resorted to OT API. Am I missing some magical steps for this to work?

On the FTD I see that I am subscribed:

uart:~$ ot ipmaddr
ff02:0:0:0:0:0:0:fd

Yet,
uart:~$ ot counters mac
...
            responseRxDestAddrFiltered: 107
...

My code is basically:
  memset(&listen_sockaddr, 0, sizeof(listen_sockaddr));

  otIp6AddressFromString("ff02::fd", &listen_sockaddr.mAddress);
  error = otIp6SubscribeMulticastAddress(ot_instance, &listen_sockaddr.mAddress);
  error = otUdpOpen(ot_instance, &udp_socket, udp_rx_handler, NULL);

  memset(&listen_sockaddr, 0, sizeof(listen_sockaddr));
  otIp6AddressFromString("::", &listen_sockaddr.mAddress);
  listen_sockaddr.mPort = 6666;
 
  error = otUdpBind(ot_instance, &udp_socket, &listen_sockaddr);

No error codes are returned, unless I try to pass "fd02::fd" to the bind, so I am using "::".

The 'udp_rx_handler' above is never invoked.

Jonathan Hui

unread,
Apr 21, 2021, 6:19:36 PM4/21/21
to Ken Bass, openthread-users
When using OpenThread APIs directly, you should be able to receive multicast messages.

Some details that might help:
  1. What OpenThread git commit are you using?
  2. How are you sending the UDP message?
I just ran the following with the latest main branch (8467a3d).

Node 1:

> dataset init new
Done
> dataset commit active
Done
> ifconfig up
Done
> thread start
Done
> dataset
Active Timestamp: 1
Channel: 23
Channel Mask: 0x07fff800
Ext PAN ID: 094ce87a6cfcf499
Mesh Local Prefix: fd13:ea9c:33e6:8b90::/64
Master Key: 3543388fae4b41b1f41094aab3fc8803
Network Name: OpenThread-1df9
PAN ID: 0x1df9
PSKc: 7391b14e2eff1649a072de1d1e2a33cd
Security Policy: 672 onrcb
Done
> udp open
Done
> udp send ff02::fd 1234 hello
Done

Node 2:

> dataset masterkey 3543388fae4b41b1f41094aab3fc8803
Done
> dataset commit active
Done
> ifconfig up
Done
> thread start
Done
> ipmaddr add ff02::fd
Done
> udp open
Done
> udp bind :: 1234
Done
> 5 bytes from fe80:0:0:0:881b:9b8c:853b:b274 49155 hello

The OpenThread CLI uses the OpenThread APIs directly (see src/cli/cli_udp.cpp).

--
Jonathan Hui



--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/6ef340a0-ce34-f563-763c-607b988ce4d9%40kenbass.com.

Ken Bass

unread,
Apr 21, 2021, 6:38:58 PM4/21/21
to openthread-users
I am using Nordic Connect SDK - I just spent the past hour or so updating it to the their 'latest master'. That branch still has an older Openthread (around March 3):

' openthread: Merge up to commit: 8f7024c'

I am sending this using basically:

  memset(&messageInfo, 0, sizeof(messageInfo));
 
  otIp6AddressFromString("ff02::fd", &messageInfo.mPeerAddr);
  messageInfo.mPeerPort = 6666;

  error = otUdpOpen(ot_instance, &udp_socket, mcast_scan_task_udp_rx_handler, NULL);

  otMessage *       message         = NULL;

  message = otUdpNewMessage(ot_instance, NULL);
  error = otMessageAppend(message, "TEST", 4);
  error = otUdpSend(ot_instance, &udp_socket, message, &messageInfo);
  if (error != OT_ERROR_NONE && message != NULL)
  {
    otMessageFree(message);
  }

I have verified via wireshark packet sniffer that my data is being sent...

256329    1619043995.762529    fe80::e89d:5e90:e2e1:a4f0    ff02::fd    UDP    67    49152 → 6666 Len=4    -50dBm    172

I found this mailing list post and several PR's which makes me wonder if there is a problem still.

https://groups.google.com/g/openthread-users/c/gfB6e1W-opM/m/YfYEQhqQFQAJ

I have no idea how to update Nordic Connect SDK with the latest Openthread (or what that might break).

Your CLI example below does not work on my setup. It results in the same exact increment of the 'responseRxDestAddrFiltered' MAC counter on the receiver.

Jonathan Hui

unread,
Apr 21, 2021, 6:53:55 PM4/21/21
to Ken Bass, openthread-users
I ran the same commands as in my previous message on OpenThread commit 8f7024c and it worked fine. Note that I am not using nRF Connected, but a bare metal build directly out of OpenThread.

Can you provide the wireshark packet trace for more visibility? The MAC counters occur on the IEEE 802.15.4 header, not the IPv6 header, which is not visible in the line that you copied.

The issue in the message you linked only applies to OpenThead on posix platform where OpenThread is managing both a network interface on the host OS and Thread itself. I don't believe the same issue would apply to nRF Connect SDK.

--
Jonathan Hui

Ken Bass

unread,
Apr 21, 2021, 7:06:54 PM4/21/21
to openthre...@googlegroups.com

Does this show the detail you are looking for? One thing got me thinking and it might be my lack of details on the 802.15.4.. There is a destination of 0x0800 in there... If it is broadcast why? Then I remember...
For this test I am running. The receiver is FTD with 0x800 and the sender is a SED (whose parent is 0x800) - perhaps that matters?

Frame 258028: 67 bytes on wire (536 bits), 67 bytes captured (536 bits) on interface /tmp/wireshark_extcap_-dev-ttyACM2_20210418200846_t4ULVn, id 0
IEEE 802.15.4 TAP
IEEE 802.15.4 Data, Dst: 0x0800, Src: ea:9d:5e:90:e2:e1:a4:f0
    Frame Control Field: 0xd869, Frame Type: Data, Security Enabled, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2006, Source Addressing Mode: Long/64-bit
    Sequence Number: 119
    Destination PAN: 0x4638
    Destination: 0x0800
    Extended Source: ea:9d:5e:90:e2:e1:a4:f0 (ea:9d:5e:90:e2:e1:a4:f0)
    Auxiliary Security Header
    MIC: 9fa55bee
    [Key Number: 0]
    [Ack In: 258029]
6LoWPAN, Src: fe80::e89d:5e90:e2e1:a4f0, Dest: ff02::fd
    IPHC Header
    [Source: fe80::e89d:5e90:e2e1:a4f0]
    Destination: ff02::fd
    UDP header compression
    Source port: 49152
    Destination port: 6666
    UDP checksum: 0xb0b0
Internet Protocol Version 6, Src: fe80::e89d:5e90:e2e1:a4f0, Dst: ff02::fd
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
    .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 12
    Next Header: UDP (17)
    Hop Limit: 64
    Source: fe80::e89d:5e90:e2e1:a4f0
    Destination: ff02::fd
User Datagram Protocol, Src Port: 49152, Dst Port: 6666
    Source Port: 49152
    Destination Port: 6666
    Length: 12
    Checksum: 0xb0b0 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 352]
    [Timestamps]
Data (4 bytes)
    Data: 54455354
    [Length: 4]

Jonathan Hui

unread,
Apr 21, 2021, 7:20:19 PM4/21/21
to Ken Bass, openthread-users
If the sender is a SED, then it will send an IPv6 multicast message using a unicast IEEE 802.15.4 message. If the parent's RLOC is 0x0800, then the MAC destination address is as expected. If the parent is also subscribed to ff02::fd, then the parent should receive the UDP message.

Can you provide the output of the child table command on the router?

--
Jonathan Hui



Ken Bass

unread,
Apr 21, 2021, 8:09:47 PM4/21/21
to openthre...@googlegroups.com

Sorry, the parent is actually the border router, not the FTD.  It is the border router that is RLOC 0x800

On the FTD, the child table is empty. 

I tried to enable more logging, but it gets truncated. I do see a bunch of:

[00:04:22.302,246] <dbg> net_openthread.[DEBG]-MAC-----: Frame rx failed, error:Desti~

Oddly, adding debug prints, I do not see OT_ERROR_DESTINATION_ADDRESS_FILTERED being set by any conditions hitting in the

void Mac::HandleReceivedFrame(RxFrame *aFrame, otError aError) routine.

Ken Bass

unread,
Apr 21, 2021, 8:40:27 PM4/21/21
to openthre...@googlegroups.com
Jonathan, one more *key* piece of info...

I rebooted the OTBR and now the receiver is getting the multicast message.
- The sender is now actually a child of the receiver rather than the OTBR.
- Does the OTBR, because it was a parent, need to be subscribed to the ff02::fd multicast group? (I don't believe this worked earlier today when I tried to reuse ff02::2, but I can try to retest that)
- Or maybe this indicates a problem with the OTBR code? The OTBR, not being tied to Nordic,  is the very latest commit as of yesterday.

Jonathan Hui

unread,
Apr 21, 2021, 8:45:51 PM4/21/21
to Ken Bass, openthread-users
ff02:: multicast messages have link-local scope, which means that they will only traverse at most one hop in Thread.

When the sender is a child (SED in this case) sends to ff02::fd, only the parent will be able to receive that message and only if the parent is subscribed to ff02::fd. If you need the multicast message to traverse multiple hops, then you should use a larger scope such as realm-local (ff03::).

--
Jonathan Hui



Ken Bass

unread,
Apr 21, 2021, 8:56:35 PM4/21/21
to openthre...@googlegroups.com

Maybe I have a fundamental misunderstanding here...please correct me. What I am trying to do is emulate the MLE Parent Request and Parent Response(s) mechanism. If I call otThreadBecomeDetached(), the SED broadcasts to ff02::02 and say 3 potential parents respond. I am trying to do the same thing without detaching from the thread network. Is this not possible?  Does a detached thread node play by different rules?

Jonathan Hui

unread,
Apr 21, 2021, 9:09:42 PM4/21/21
to Ken Bass, openthread-users
By default, Thread enables link-layer security on all link frames. To receive a link frame from a neighboring device, the receiver must have a security association established with the sender. A SED only maintains a security association to a single parent at any given time.

Thread uses MLE to establish security associations with neighboring devices. MLE messages in Thread are sent with link security disabled, so any neighboring device that accepts unsecure link traffic on the MLE UDP port can receive the message.

If you want to implement similar behavior with your own UDP messages, you can do so by:
  1. Disabling link security on a given UDP message before sending - see the otMessageSettings argument in otUdpNewMessage.
  2. Opening an unsecure UDP port on the receiver side - see otIp6AddUnsecurePort.
Hope that helps.

--
Jonathan Hui



Ken Bass

unread,
Apr 21, 2021, 9:48:15 PM4/21/21
to openthre...@googlegroups.com
Thank you for that explanation and your help. Would it be correct for me to assume that emulating this behavior is less 'disruptive' to a Thread network / topology than nodes periodically calling otThreadBecomeDetached()?

Ken Bass

unread,
Apr 22, 2021, 2:19:41 PM4/22/21
to openthre...@googlegroups.com
Jonathan, I must still be missing a concept here. During the MLE 'Parent Request', a node sends to ff02::02 and multiple/nearby router radio devices receive that (since it is a 802.15.4 bcast) and process it. Is that a special case when a device is detached?

If I send an (unsecure) UDP like that to ff02::fd it is link local and not being received at the application layer by anyone but the parent. Does the hop limit need to be set to 255 for it to be not filtered? What am I missing? I want all nearby single radio link router devices to receive without forwarding / routing. Even if I am a child node, how can I force an application message to be sent to 802.15.4 broadcast. I tried creating a IPv6 packet by hand, even setting otMessageSetDirectTransmission(), but OT sets the destination to my parent.

Jonathan Hui

unread,
Apr 22, 2021, 6:26:53 PM4/22/21
to Ken Bass, openthread-users
Apologies, the implementation was not actually inline with what I had thought.

I just submitted openthread/openthread#6503 that should enable you to achieve what you want.

Try it out and let me know if that allows you to achieve your goals.

--
Jonathan Hui



To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/fad48350-091b-6c1a-92c8-b16538721376%40kenbass.com.

Ken Bass

unread,
Apr 27, 2021, 11:42:22 AM4/27/21
to openthre...@googlegroups.com
Yes that PR works for me, thank you very much!

Jonathan Hui

unread,
Apr 27, 2021, 12:47:36 PM4/27/21
to Ken Bass, openthread-users
Great to hear. Thanks for the update.

--
Jonathan Hui



To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/ad305662-a038-8041-6fe3-9b41c2d8b326%40kenbass.com.
Reply all
Reply to author
Forward
0 new messages