• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 92 subscribers
  • Views 958 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 286716
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SDK Known Issue KRKNWK-11602: Zigbee device becomes not operable after receiving malformed packet

BrandonE

The project I work on is considering updating from SDK version 1.71 to 1.9.0 to benefit from some updates. (Thanks!)

As I was looking over the Known Issues I noticed KRKNWK-11602.

> When any Zigbee device receives a malformed packet that does not match the Zigbee packet structure, it causes ZBOSS to assert. The device is not automatically restarted.

I have a few questions.

  • This issue is listed as being in 1.8.0, 1.9.0 and 1.9.1. Does that mean it doesn't exist in 1.7.1, or it wasn't discovered until after 1.8.0 was released?
    • If it exists in 1.7.1 the other questions become moot, and we may as well upgrade.
  • This issue mentions a malformed packet. Shouldn't a malformed packet be tossed due to an invalid checksum?  
  • Do we know how frequently this issue occurs? Is there a way to trigger this issue? 
  • I see the workaround is to restart the system. Is there a fix in the works? If so what does the timeline look like?
  • 0

    > Shouldn't a malformed packet be tossed due to an invalid checksum?

    A buggy or malicious peer can send packets with malformed data structures inside them, but a good checksum on the packet.

    I'm guessing that this ticket doesn't refer to just any random corrupted packet; it's probably a bug in the handler for some specific operation.  I agree that it would be helpful to get as much detail as possible about this errata.

    I have a test case that I can run locally to get ZBOSS to lock up.  I'd like to debug it, but ZOI has not been helpful with respect to providing source code.  This is my first time using Zigbee and I'm wondering if I picked the wrong stack...

  • +1 in reply to mytzyiay

    Hello,

    It is correct that a packet can be corrupt even if the CRC checks out. It has an invalid payload. I believe that the issue was present in earlier versions as well, even though e.g. 1.7.1 is not listed. 

    Do we know how frequently this issue occurs? Is there a way to trigger this issue? 

    It shouldn't occur as long as all nodes in the network behave as they should. One of the nodes must generate a malformed packet for it to trigger the issue. 

    One way to reproduce the issue is apparently to use the Shell sample from the SDK, and send the following command:

    zcl raw <short address> <cluster> 000 104 FFFF

    I have not tested this myself. I have not tested this myself, but as you see, it is possible to create a malformed/"illegal" packet, but this packet needs to come from a node from within the network. So I wouldn't say that the risk of this happening in a real situation for a product is very high.

    I believe that there is a patch coming up, but when this patch is released, I don't know. Besides, we don't discuss roadmap details here on DevZone. If you need to know details around the roadmap, you need to contact our Regional Sales Manager for your country. Please send me a private message (here on DevZone) with your location if you want the contact information.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Edvin, thanks for your responses.  

    I have the contact information for our Sales Manager. The fact that the issue is likely in earlier versions makes our path forward clear.

    I have the contact information for our sales manager. 

    Thanks again,

    Brandon

  • 0 in reply to BrandonE

    Hello Brandon,

    I got a confirmation now that the patch is enabled since v1.9.x, so if you are using v1.9.1, it should be fine. The patch is to reset on a malformed packet, so there is no need to power cycle the device. 

    They will update the known-issues list to make this more clear.

    Best regards,

    Edvin

Related
Terms of service