Inter-PAN Transmission between ZR and ZC

Hi,

Can you share the sniffer log ?
Might be useful for us to see the contents of it.

Have you tried commissioning the device ?
It looks like the device will need a valid short address before it's handled :

In <zr_*>/Stack/zmac/zmac_cb.c  --   MAC_CbackEvent :

  if ( event == MAC_MCPS_DATA_IND )
  {

// ...

    MAP_MAC_MlmeGetReq( MAC_SHORT_ADDRESS, &tmp );
    if ( (tmp == INVALID_NODE_ADDR) ||
         (tmp == NWK_BROADCAST_SHORTADDR_DEVALL) ||

// ...

         (pData->dataInd.msdu.len == 0) )
    {
      MAP_mac_msg_deallocate( (uint8_t **)&pData );
      return;
    }

Regards,
Toby

I've imported clean ZR and ZC projects from the latest SDK and tested everything again (without commissioning).

I send Inter-PAN message from ZR, I see the message in the sniffer and now I have the triggered breakpoint on the ZC side:

MAP_mac_msg_deallocate()

as in the snipped code you have sent before.

So looks like the Interpan message is delivered.

How should I handle the message on the high level now? I want to get access to the payload of a received InterPan message.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/interpan_5F00_zr_5F00_to_5F00_zc_5F00_without_5F00_comissioning.pcapng.7z

Thanks for the update.

Just to note, inter-pan is non-secure and is targeted for touchlink use cases; perhaps refer to how it is used in touchlink_target_app.c (or touchlink_initiator_app.c).

Can you share details on what you'd be using inter-pan for, if not touchlink ?

I know that it is non-secure, but we can encrypt payload, so it is not a question. The main purpose of using Inter-PAN messages is transmission our manufacturer data between two coordinators. Now I'm testing Inter-PAN for different configurations of ZED,ZR,ZC.

I found another issue. If I send an Inter-PAN message from a ZC that hasn't been commissioned before (after chip erasing and programming a new firmware) and then start commissioning, it gets stuck in Main_assertHandler() with assertReason=3.

If I reset ZC, don't send Inter-PAN and start commissioning, it works. But if I reset ZC, start inter-PAN first, then start commissioning, it doesn't work.

There is a piece of code that starts Inter-PAN transmission:

Why does it happen and how could it be fixed?

Thanks for sharing your fix.

Makes sense, since valid channel range is [11, 26].
This is further confirmed by touchlink commissioning setting the channel in the _NIB beforehand (which offers an alternative solution of setting the NIB/channel before any inter-pan messaging) :

void initiatorSelectNwkParams( void )
{

// ...

  if ( _NIB.nwkLogicalChannel == 0 )
  {
    // Select randomly one of the TouchLink channels as our logical channel
    _NIB.nwkLogicalChannel = touchLink_GetRandPrimaryChannel( );
  }

I'll pass your findings along to our development team.

Also I found why ZC didn't receive Inter-PAN messages. If I comment the line of the code, Inter-PAN messages are passed by the condition and I get events  zstackmsg_CmdIDs_AF_INCOMING_MSG_IND in zclSampleLight_processZStackMsgs().

So now it looks working and I can receive inter-PAN messages, but are there any unwanted consequences of this fix?

Is this after the ZC has formed a network ?

Once a device is in a network, its short address should be assigned/initialized to a valid value (i.e. should not be a broadcast address).

Commenting this out means that the device could receive messages before it has a valid short address (which may be ok for your use case).
In steady state operation (device operating in network), the device would have a valid short address throughout its lifetime in the network, so the condition for this if block will evaluate true.

Another consideration for inter-PAN would be security related. Having some kind of screening procedure could be useful (e.g. filtering out unknown commands).

Toby Pan said:

Is this after the ZC has formed a network ?

Yes, but only on the same channel. If I send interPAN message on a different channel, it gets stuck in some time after calling StubAPS_SetIntraPanChannel().

I found that ZMacSetReq( ZMacChannel, &(_NIB.nwkLogicalChannel) ) returns error code 0x1A.

But _NIB.nwkLogicalChannel is 11, so it should be okay.

I didn't find ZMacStatus_t status value 0x1A in the zcomdef.h file.

What does status 0x1A mean?

Looks like 0x1A is MAC_NO_RESOURCES

#define MAC_NO_RESOURCES 0x1A /* The operation could not be completed because no

memory resources were available */

But why?

It looks like I found a bug in the zstacktask.c

Thanks for pointing this out.
The struct zstack_devForceNetworkSettingsReq_t does not have a logicalChannel field here, so I will check with development team if this was intentional.

At a glance, I'd agree that _NIB.nwkLogicalChannel should not be set to channelList (which is a bitmask of channels).

Are you using this API in your code ? (The SDK examples do not use it by default).

The MAC_NO_RESOURCES is the status returned when the MAC channel change api (i.e. MAP_macRadioSetChannel) is unsuccessful.

It looks like StubAPS_SetIntraPanChannel and StubAPS_SetInterPanChannel both are changing the active channel.
However, StubAPS_SetInterPanChannel is calling StubAPS_SetNewChannel,   vs   StubAPS_SetIntraPanChannel which is calling ZMacSetReq( ZMacChannel, ...) directly.
As such, can you try something like this :

ZStatus_t StubAPS_SetIntraPanChannel( void )
{
  uint8_t currChannel;
  uint8_t rxOnIdle;

  if ( channelChangeInProgress )
    return ( ZFailure );

  ZMacGetReq( ZMacChannel, &currChannel );
  if ( currChannel == _NIB.nwkLogicalChannel )
    return ( ZSuccess );

  return StubAPS_SetInterPanChannel(_NIB.nwkLogicalChannel);

}

Thanks for sharing your solution here!

I'll file a ticket to have the documentation updated accordingly.