MIC Error issue

[sca-l]

Hi,

I'm using the Tag v4.8.0 to execute the LCTT tests related to the Relay feature. The execution of test TP_RELAY_EU868_ED_MAC_104_BV_003 many times FAILs due to a MIC error on Relay device at "Step 06 - FilterListReq". Seems that during the execution of this step, the ED Relay could not generate the new WOR Keys as done by the Relay. This causes a locking condition in which the ED Relay sends its WOR, but the Relay generate a MIC Error, without no further communication through the Relay, with consequent FAIL result of the test.

I did the test both with LCTT v3.15.0 and LCTT v3.14.0. The test result is different:

• 80% PASS with v3.14.0
• 80% FAIL with v3.15.0 I looked also the LCTT logs, but seems there are not differences in the commands sent.

Do you have any idea on what could cause this issue?

Regards, Laura Scalzo

[sca-l]

Hi all,

I want to add some details on the root cause that causes the issue. During the test, the TCL send the command Relay MAC command : 0x43 - ADD_TRUSTED_ED to add the device and generate the key material on Relay device. I noticed that, there is an issue during the parsing of the packet when the issue occurs. In particular, the serial log shows:

[2025-05-14_11:26:38:883]870s357:payload size receive = 40, snr = 5 , rssi = -63
[2025-05-14_11:26:38:883]870s357:class A BAD DevAddr=0x55c05062 instead of 0xa9062 
[2025-05-14_11:26:38:883]870s358:Receive a packet But rejected and too late to restart

I verified the packet sent by the TCL and it has the right DevAddr, so I have no idea on how it could have a wrong DevAddr. No CRC error IRQ is generated by the radio.

Do you have any hint to explain that?

Thank you, regards, Laura Scalzo

[opeyrard]

Hi, Would it be possible for you to rerun the test in a conducted environment ? It might be that you are receiving some packets from other devices. Also, could you please provide the LCTT logs ? Many thanks,

[sca-l]

TP_RELAY_EU868_ED_MAC_104_BV_003.zip

[sca-l]

Hi,

I can confirm that the issue occurs in a controlled environment. I can add that the issue occurs always in steps 6 or 7 or 8 when a MAC Command with size 40 bytes is sent by the LCTT to the Relay.

I think that, the packet should be discarded by the radio as CRC error if the packet is corrupted, or if the packet is not destinated to the Relay, the DevAddr should be checked and discarded at a lower level, is it right?

Thank you, regards, Laura

[sca-l]

TEST_03_FAIL.zip

Hi,

this another example of FAIL. The FAIL is at step UpdateUplinkListReq.

The MAC command with size 40 byte is sent by the TCL to the Relay.

It is received by the Relay, but it is discarded because it is no more valid:

[2025-05-22_15:42:23:277]1942s259:payload size receive = 40, snr = -6 , rssi = -63 [2025-05-22_15:42:23:277]1942s260:Receive a bad packet on RX2 for stack_id = 0

Do you have an idea on why the packet should be discarded?

Thank you, regards, Laura

[lbm-team]

Hello,

Are you sure you're in a controlled environment with minimal communication activity? Your last message indicates that your device received a message at -63dBm with an SNR of -6, suggesting a rather "noisy" environment possibly interfered by other LoRa communications. To assist you further, could you please share both the LCTT report, device logs, and gateway logs for this test? This will help us track exactly what's happening on the device side.

Many thanks