Unexpected Payload/Packet sent to MDot on a successful Network Join

[Ajay K]

Since Build 2.0.17 and the 2.0.17-1 build of the libmdot, we are suddenly seeing an unexpected payload of 10 bytes being sent on a successful join request. Although the custom firmware is guarding against this unexpected payload, however I am concerned that this payload was even presented to the custom firmware and is this expected in the first place and not sure if there are other scenarios where an additional payload will be received.

Here is the custom payload that was as received by the logs.

5/11/2017 3:01:35 PM: [DEBUG] Mac command index: 5 cmd: 0x03

5/11/2017 3:01:35 PM: [DEBUG] ADR settings accepted
5/11/2017 3:01:35 PM: [DEBUG] ADR DR: 0 PWR: 0 Ctrl: 01 Mask: ff00 NbRep: 1 Stat: 07
5/11/2017 3:01:35 PM: [DEBUG] mDotEvent – PacketRx

5/11/2017 3:01:35 PM: [TRACE] Payload: 0340080071030000ff11

5/11/2017 3:01:35 PM: [TRACE] Event: OK
5/11/2017 3:01:35 PM: [TRACE] Flags Tx: 0 Rx: 1 RxData: 1 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
5/11/2017 3:01:35 PM: [TRACE] Info: Status: 0 ACK: 1 Retries: 4 TxDR: 0 RxPort: 0 RxSize: 10 RSSI: -117 SNR: 214 Energy: 0 Margin: 0 Gateways: 0
5/11/2017 3:01:35 PM: [DEBUG] Rx 10 bytes

Thanks,
Ajay

[Jason Reiss]

Packets received on port 0 are Network messages.
This one is an ADR command controlling the channels and datarate of the Dot.
The channels are set to the 8 configured on the gateway

Two ADR commands are present
0340080071 – Disable all 125kHz channels and 1 500 kHz set to DR4
030000ff11 – Enable the 8 125 kHz channels set to DR0

ID DR/PWR CHMASK CTRL/REP
03 40 0800 71

This allows a device to join configured in 64+8 channel mode and then be assigned the proper channels. Of course a device using 64+8 channels may need multiple attempts to join as it is must guess the gateway channels.

[Ajay K]

Thanks Jason for the explanation, however shouldn’t this packet be shielded from the custom application or not handed to it, as it is not of much of use to the custom firmware and since this packet is required only the libmdot to deal with DR changes?

Thanks,
Ajay

[Jason Reiss]

Depends on the application. I’d rather leave that decision to the application. The port value is provided to filter them.

[Ajay K]

Jason I am confused, is this payload not required by the libmdot? If so any application consuming libmdot to communicate with the conduit, can not ignore this packet with ADR enabled correct? Also like I mentioned previously at the beginning of this thread, the application never received this payload before, even if it did the libmdot may have consumed it and not have handed it over to the custom firmware. It seems to be happening since the latest build 2.0.17 of the libmdot.

Until the explanation above what the payload was, I had no clue what that payload was, so my concern again is that we transmit custom payloads which gives specific configurations/directions to the mdot and I don’t want to handle these payloads that have no meaning to my firmware. But as you suggested I could apply some filter, which I don’t understand how to do that yet? But filtering that payload would it prevent the libmdot from ignoring that payload?

Thanks,
Ajay

[Jason Reiss]

Just ignore all message received on port 0 if they have no meaning to your application.

Would be best to accept packets only on port values you expect to receive.

info->RxPort contains the port value, 1 is default AppPort

[Ajay K]

Thanks a lot Jason, that helps.

[Author]

Posts