How to intercept 802.15.4 frames while using Thread

[Jochen0x90h]

Hi!

I read that your Thread stack uses a different 802.15.4 implementation than the MAC driver. Is it possible to intercept special broadcast data packets e.g. from energy harvesting switches while using thread?

The special packets that I want to intercept have a MAC header that looks like this:

Frame Control: 0x0801 (use short addresses)

Sequene Number: 1 byte

Address field: 0xffffffff (short destination address and pan id)

Source address and pan are not included

Is there a possibility to use Thread and set a callback to intercept these packets and process them "by hand" and pass everything else on to Thread?

Thanks,

Jochen

[Edvin]

Hello Jochen,

Sorry for the late reply.

Were you able to receive non-network packets using otLinkSetPcapCallback()?

These energy harvesting switches typically do not have enough power to run the radio in RX mode, so they will not be part of the network. Just so you know, this means that if you do an action on these switches, this will be vulnerable to reply attacks. But it would be you who decide whether or not this is an issue. Even if you have some sort of key, the keys in Thread networks are regularly updated to prevent replay attacks. This is just an FYI.

Best regards,

Edvin

[Jochen0x90h]

Yes it seems to work. The switch that I use even has a sequence counter and a checksum generated by some encryption algorithm so replay is not (easily) possible like in car keys. The next question if this still works when thread and zigbee are used simultaneously. otLinkSetPcapCallback() is an openthread function, how do packets get forwarded to the zigbee stack?

[Jochen0x90h]

Does the Zigbee stack use the same radio driver like the thread stack? Or is the radio driver part of the closed source Zigbee stack? It would still be interesting if it is possible to receive raw data packets using the Zigbee stack.

[Jochen0x90h]

Other question would be if you will release the source code of the 802.15.4 packet sniffer in the future. It seems to me that it just forwards the packets to the USB port, but would be handy for experimenting.

[Edvin]

This sniffer doesn't use Zigbee or OpenThread. As far as I know there isn't plans to release the source code for this.

The function nrf_802154_received_timestamp_raw from SDK\nrf5\external\zboss\osif\zb_nrf52_transceiver.c is the function you are looking for in Zigbee. It is called by the radio driver whenever a frame is received, in which the function will pass the frame to the ZBOSS stack when it is called. Because this is called from an interrupt, and it is in charge of passing the packets to the zboss stack, you should not do any further processing of the packet here. You can forward it to your application, and do the processing there, so that the interrupt handler is immediately ready for a new packet. In addition, the ZBOSS stack will decide to free up this buffer when it is processed, so you should copy the data to your own buffer (and not just send the pointer to the original buffer).

Best regards,

Edvin

[Jochen0x90h]

Thanks for the info. What is the correct way to notify the application from the interrupt and prevent race conditions on the copied data? Is there an example for this? Is it OK for Thread to do the processing in the callback or is it also called in the interrupt handler?

[Edvin]

We don't have any examples doing this, unfortunately.

I would suggest to study how the BLE examples use the ble event handler in the ble_examples to propagate an event to main.c. E.g. how the ble_app_uart example receives an event in ble_nus_on_ble_evt() in ble_nus.c, and use the on_write() function to send the event BLE_NUS_EVT_RX_DATA to main.c.

Remember to make a copy of the message in your own buffer before sending the message through to the ZBOSS stack, because after this, it may be freed at any time (possibly before you have time to handle it in main.c).