Oversized RX Payload are not disregarded

[tibbis]

Describe the bug

I noticed while running TP_A_EU868_ED_MAC_BV_020, the device doesn't disregard oversized downlinks which makes the test fail when an oversized confirmed downlink is received and the device sets the OP_POLL bit which it shouldn't.

I suggest adding the following code in the beginning of decodeFrame() function:

    if ( dlen + OFF_DAT_FCT > (LMICbandplan_maxFrameLen(LMIC.datarate)) ){
        goto norx; // oversized RX payload, discard message
    }

With this added the test passes. Not sure if "OFF_DAT_FCT" is a good constant instead of having "+ 5"?

Environment

LMIC 4.1.1 LCTT 3.4.0_R2

To Reproduce

Send an oversized confirmed downlink to the device. Listen to the response.

Expected behavior

It should not react/respond to the message at all and continue working as normally.

[terrillmoore]

I'm not sure I agree with this compliance test. If the message is signed (with a valid MIC), then the network has made a decision to send the message, and it is strange for the device to discard it. There may be a valid reason for the network to do this. The sender must have the encryption keys, so there is no security issue. The LMIC has no limit on the buffer space in this case; we discard if the buffer would be overflowed (if compiled for a small message size). There is no regulatory compliance issue as the LMIC is not sending anything illegal. Is there a justification for this in the test spec? Or is it just over-regulation?

[tibbis]

I agree however the requirements says that it shouldn’t acknowledge or act anything after the message, which it currently does with the OP_POLL flag:

[tibbis]

I think I made a mistake on my proposal code, it should be only:

    if ( dlen > (LMICbandplan_maxFrameLen(LMIC.datarate)) ){
        goto norx; // oversized RX payload, discard message
    }

[cstratton]

I agree however the requirements says that it shouldn’t acknowledge or act anything after the message

No, it doesn't. It says that the end device "may or may not" act as if the downlink was received.

What it must not do is break and cease functioning (ie, must not exhibit a logic path that gets stuck or suffer a buffer overflow or whatever)

Enforcing downlink size limits at the end device is practically problematic, because there are LoRaWAN regions where there may or may not be a packet duration limit, and the network may know if that applies or not to a degree that the end device cannot yet reliably know.

[tibbis]

Yes I think you’re right. I could ask them to check if it is a bug in the LCTT program.