Does herdsman support APS fragmentation?

[canardos]

Per the title, does Zigbee Hersdman support fragmentation at the APS level? I'm using the ZStack3v0 20240710 firmware.

Having some issues with fragmented ZCL attribute read response and would like to confirm support before delving too deep.

Thanks

[Koenkk]

I was not aware that Zigbee has such feature (so zigbee-herdsman doesn't support it). I'm not sure if this is exposed on the API level? Seem to be something quite low level in the stack: https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/3.10.00.53/exports/docs/zigbee/html/zigbee/z-stack-overview.html#fragmentation

[canardos]

It's implemented at the APS level. If the payload is too large to fit into a single frame (i.e. > about 70 bytes), then the sender confirms with the destination that fragmentation is supported, and then sends the packet over multiple frames (with the meta data needed to reassemble - total size, packet 1/n etc.).

It's supported by the TI ZStack (my application is CC2652 based). It does require fragmentation to be enabled before compilation, but we can see that it's enabled because everything is working with fragmented payloads below about 220 bytes (I'm doing a ZCL read in z2m of an attribute with long char str data type).

I've done some testing, and determined what is happening.

You are correct that the ZStack/ZNP handles the fragmentation transparently and so zigbee-herdsman does not need to handle it. The issue is that the ZStackAdpater does not handle large data packets from the ZNP correctly.

The ZNP sends AF_INCOMING_MSG and AF_INCOMING_MSG_EXT messages when data is received. The AF_INCOMING_MSG_EXT message is used when the incoming data is over a certain length (or if INTER_PAN is used).

These are handled in the onZnpRecieved method of the ZStackAdapter class:

 if (object.subsystem === [Subsystem.AF](http://subsystem.af/)) {
     if ([object.command.name](http://object.command.name/) === "incomingMsg" || [object.command.name](http://object.command.name/) === "incomingMsgExt") {
         const payload: Events.ZclPayload = {
             clusterID: object.payload.clusterid,
             data: object.payload.data,
             header: Zcl.Header.fromBuffer(object.payload.data),
             address: object.payload.srcaddr,
             endpoint: object.payload.srcendpoint,
             linkquality: object.payload.linkquality,
             groupID: object.payload.groupid,
             wasBroadcast: object.payload.wasbroadcast === 1,
             destinationEndpoint: object.payload.dstendpoint,
         };

         this.waitress.resolve(payload);
         this.emit("zclPayload", payload);
     }
 }

The problem is that they are treated the same, but the AF_INCOMING_MSG_EXT message must be handled differently. From the TI ZNP docs:

An AF_INCOMING_MSG_EXT with a huge data byte count indication shall not
contain any data bytes. The huge data buffer must be retrieved separately as a sequence of one or more AF_DATA_RETRIEVE requests. Note that the incoming huge message is timed-out in 15 seconds after receiving it; thus all AF_DATA_ RETRIEVE requests must be completed within 15 seconds of an AF_ INCOMING_MSG _EXT with a huge data byte count. Note that multiple AF_INCOMING_MSG_EXT indications with huge data byte counts may be queued, and each will be timed-out separately.

Currently, the the onZclPayload method of the controller fails when it tries to parse the payload as it has no data. The src address is also not handled correctly, as it assumes a 64-bit address, but incomingMsgExt uses 16-bit address sometimes.

AF_DATA_ RETRIEVE (dataRetrieve) is present in the AF subsystem definitions, but it is not used.

I added the required code to handle incomingMsgExt and retrieve the data and it appears to work correctly. If you're happy to include this, then I'll submit a PR with the changes for review.

[Koenkk]

Thanks for the in-depth analysis!

If you're happy to include this, then I'll submit a PR with the changes for review.

Sounds good!