IEEE802.15.4: received frames without destination address aren't acked since zephyr v2.7.0

RE: IEEE802.15.4: received frames without destination address aren't acked since zephyr v2.7.0

Marte Myrvold — Tue, 21 Dec 2021 09:57:55 GMT

Hi,

For information regarding roadmap, please contact our regional sales manager in your area. If you do not know who that is or do not have their contact information, please let me know and I can send it to you.

Best regards,

Marte

RE: IEEE802.15.4: received frames without destination address aren't acked since zephyr v2.7.0

MeisterBob — Mon, 20 Dec 2021 15:37:51 GMT

I was busy in an other project, now I'm back into 802.15.4 things.

According to the IEEE standard it's absolutely valid to have frames without destination address, so the frame should pass the filter. But it doesn't because in https://github.com/zephyrproject-rtos/hal_nordic/blob/master/drivers/nrf_802154/driver/src/mac_features/nrf_802154_filter.c#L415 it is discard. Even the comment a few lines below mentions that it should let frames without destination address pass the filter (under the right conditions). This bug is already fixed in the nRF Connect SDK (https://github.com/nrfconnect/sdk-nrfxlib/blob/main/nrf_802154/driver/src/mac_features/nrf_802154_filter.c#L415).

When can we expect an update of the radio driver in zephyrs hal_nordic?

RE: IEEE802.15.4: received frames without destination address aren't acked since zephyr v2.7.0

Marte Myrvold — Tue, 09 Nov 2021 09:45:51 GMT

Hi,

[quote user="MeisterBob"]num_data_bytes gets changed in dst_addressing_end_offset_get() -> dst_addressing_end_offset_get_2006() from 3 to PANID_CHECK_OFFSET (6) and so m_flags.frame_filtered isn't set to true.[/quote]

This is expected behavior. Since the frame does not have any destination address, it will not pass all the steps of the filtering procedure:

2. When destination address fields (PAN ID and address) are present and received (second BCMATCH event), the driver checks if the frame is destined to this node (broadcast or unicast).

As mentioned earlier, in order for the MAC layer to automatically send ACK frames, the frame must pass all filter steps. However, the driver will notify the higher layer that it received a frame regardless of destination address in promiscuous mode. In this case, the next higher layer should send the ack.

Best regards,

Marte

RE: IEEE802.15.4: received frames without destination address aren't acked since zephyr v2.7.0

MeisterBob — Mon, 08 Nov 2021 13:29:22 GMT

The frame I'm trying to ack looks like this:

23 d0 6c cd ab 20 00 00 2f da c2 50 00 00 88 ef be 00 80

2 bytes fcf (Command Frame, ACK Requested, Version 2006, Long Src Address)
1 byte sequence number
2 bytes PAN id (0xABCD)
8 bytes src address (00:50:c2:da:2f:00:00:20)
1 byte command identifier (0x00)
5 bytes payload

in nrf_802154_trx_receive_frame_bcmatched() the filter_result after nrf_802154_filter_frame_part() is NRF_802154_RX_ERROR_NONE but num_data_bytes gets changed in dst_addressing_end_offset_get() -> dst_addressing_end_offset_get_2006() from 3 to PANID_CHECK_OFFSET (6) and so m_flags.frame_filtered isn't set to true.

RE: IEEE802.15.4: received frames without destination address aren't acked since zephyr v2.7.0

Marte Myrvold — Mon, 08 Nov 2021 12:04:53 GMT

Hi,

Does the frame pass the filter? In order to send ACK, the received frame must pass the steps of the filtering procedure (see Receiving and filtering frames), even if you have enabled promiscuous mode. When using promiscuous mode, the frame can pass only step 3 and the frame will still be reported to the MAC layer. However, the driver will not automatically transmit an ACK if any of the steps fail.

The source code of the 802.15.4 Radio Driver, as well as documentation, was added to nRF Connect SDK in v1.6.0. You can now find the source code in <ncs_root>/nrfxlib/nrf_802154 now, and the documentation and API can be found here: nRF 802.15.4 Radio Driver and nRF 802.15.4 Radio Driver » API documentation.

[quote user=""]Everything was fine with hal_nordic on commit 74b3b21f60aa3dc9a4364ffc28dbb47ad8b699a9. After updating to zephyr v2.7.0 the radio doesn't ack frames without destination address.[/quote]

You can find the changelog for the nRF5 802.15.4 Radio Driver in our documentation, see nRF 802.15.4 Radio Driver » Changelog. The latest version of the nRF Connect SDK use Zephyr v2.6.99, so there might be changes in Zephyr v2.7.0 that are not in the latest version of nRF Connect SDK yet.

Best regards,

Marte

RE: IEEE802.15.4: received frames without destination address aren't acked since zephyr v2.7.0

Marte Myrvold — Fri, 05 Nov 2021 13:49:32 GMT

Hi,

I have started looking into your issue, and I will come back to you at the beginning of next week.

Best regards,

Marte