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

[MeisterBob]

Hello,

we developed a proprietary protocol on top of IEEE 802.15.4 user zephyr on a nRF52833. 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.  I have promiscuous mode and pan coordinator enabled and added the address of the peer to the pending bit list. The address matching mode is set to IEEE802154_FPB_ADDR_MATCH_THREAD.

struct ieee802154_radio_api *radio_api = (struct ieee802154_radio_api *) dev->api;
struct ieee802154_config config;

/* set address matching mode */
config = { .auto_ack_fpb.enabled = true,
            .auto_ack_fpb.mode = IEEE802154_FPB_ADDR_MATCH_THREAD };
radio_api->configure(dev_data->ieee802154_dev, IEEE802154_CONFIG_AUTO_ACK_FPB, &config);

/* enable pan coordinator */
config = { .pan_coordinator = true };
radio_api->configure(mps_data->ieee802154_dev, IEEE802154_CONFIG_PAN_COORDINATOR, &config);

/* enable promiscuous mode */
config = { .promiscuous = true };
radio_api->configure(mps_data->ieee802154_dev, IEEE802154_CONFIG_PROMISCUOUS, &config);

/* add peer to FPB list */
config = { .ack_fpb.enabled  = true,
            .ack_fpb.addr     = peer, /* uint8_t* */
            .ack_fpb.extended = true };
radio_api->configure(mps_data->ieee802154_dev, IEEE802154_CONFIG_ACK_FPB, &config);

Before the update my device acked all frames (with ack req bit set) and set the pending bit for peers present in the pending bit list. How can I make the 'new' driver ack received frames without destination address?

[Marte Myrvold]

Hi,

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

Best regards,

Marte

[Marte Myrvold]

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.

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.

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

[MeisterBob]

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.

[Marte Myrvold]

Hi,

MeisterBob said:

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.

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

[MeisterBob]

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?