This is a followup to a previous Topic where I thought packet length verification was incorrect and it still may be. This is a bit more information,
The Previous Topic: LoRaWan: LoRaMac.c - ValidatePayloadLength( ) fails to catch too large payload if fOptsLen != 0
NOTE: My understanding of LoRaWan protocol could use some work, this is how I currently understand what is happening.
The issue: I am seeing a user payload whose size is greater than allowed by the currently defined data rate, DR_, that is still being delivered to the network server.
This will occur if the LoRaMac runtime is processing a response to a network server request, in this case a SRV_MAC_LINK_ADR_REQ was returned during the Rx window of a previous uplink message.
The runtime is preparing a response by adding the mac command response data to the message that is to be delivered to the network server during the next uplink.
In this case during the next uplink the “user packet”, which again violates the DR_ maximum, is delivered to the network server along with what is apparently the MAC response.
Previous and follow on uplink messages of the same packet size are flagged as invalid and not delivered, only the one containing the MAC response is sent with the user packet intact.
Is this correct LoRaWan behavior, deliver the user packet even though it violates DR_ maximum?
The scenario (RegionUS915)
- Default Data Rate = 3
- end node user app overrides Data Rate, DR = 0, (implies max user packet of 11 bytes)
- end node user app is in a loop sending a packet that is size 24, (yes, too large for DR_0)
– network join attempts alternate between DR_0 and DR_3, In this scenario the join succeeds with DR_3.
- first user uplink attempt
– the first packet length error is not caught by the LoRaWan library level’s max length test because DR_3 is used as the compare DR ( this does not look correct either)
– LoRWan library layer resets the Data Rate to the correct DR_0 before passing the packet buffer off to lower layers (this is after the length check)
– LoRaMac layer catches the user packet excess length error and aborts the send, nothing is sent to the network server.
- Next user uplink attempt
– this attempt fails the packet length check in LoRaWan lib layer, as now the data rate used in the compare is DR_0
– user packet length is set to 0
– zero length user packet is sent to the LoRMac layer and on to the network server
– network server decodes the fact the packet is zero length
– at this point the network server is returning (downlink) a SRV_MAC_LINK_ADR_REQ to the end node during the Rx time.
– the response is partially packaged for delivery during the next uplink transmission.
- Next user send attempt
– now the response to the SRV_MAC_LINK_ADR_REQ is returned to the network server,
– this time the LoRaWan lib packet length test passes because fOptsLen is not zero, (though I’m not sure why it should be passing??)
– now the response to the SRV_MAC_LINK_ADR_REQ is completed, mac data is added to the packet to be sent
– the send is successful, mac data plus user packet data
– the network server successfully extracts out the user packet.
This does not seem correct, that the user packet data is sent even though it exceeds the max length for the given DR_.
It seems the size check indeed may not be correct
( is this part correct?? “payloadSize > maxN”, should not that be
“payloadSize < maxN” ?
user payload size lenN: 24, fOptsLen: 4, maxN: 11,
payloadSize = userPayload + fOptsLen;
( payloadSize > maxN ) && (fOptsLen != 0) && (fOptsLen <= maxN)) || ( payloadSize <= maxN )) && ( payloadSize <= LORAMAC_PHY_MAXPAYLOAD )
Should this size check pass in this instance?
Apologies for the messiness of these two topics. Just trying to provide as much info as possible.