This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to intercept 802.15.4 frames while using Thread

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

Parents
  • 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

Reply
  • 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

Children
  • 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?

  • You can't run thread an zigbee simultaneously. I don't think there is a similar function in Zigbee. The Zigbee stack is a closed source stack (developed by an external company), so I don't have access to check how the packets are forwarded to the zigbee stack. Knowing that you can't use Thread and Zigbee simultaneously, is that still a valid question? Whether or not it is possible to receive raw data packet when using the Zigbee Stack?

  • 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.

  • 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.

  • 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

Related