Downlink MIC Mismatch on every uplink

[davidfobar]

I am using the SEEEDstudio E5-mini (STM32WLE5 with integrated SX126x) and a personal gateway running a Chirpstack v4 application server.

I can connect and send "Hello World!" messages to the application with no issues. I cannot get a working downlink yet.

I am still learning about the LoRaWAN protocol, so forgive me if this is incorrect, running Class A the endnode looks for a downlink only after it sends an uplink message. Unless the application server or gateway server have something to provide the endnodes there shouldn't be any downlink, and I would expect the endnode to timeout in the RX windows and continue to function.

To test that, I had the endnode connected and sending messages to the application server successfully, then I shut down the application server, I still received a MIC mismatch:

[LoRaWAN] Sending uplink packet ... Channel frequency UL = 905.100 MHz
uplinkMsg pre-MIC:
0000000 c0 00 04 01 0c 00 00 00 a2 a2 00 20 fc ff ff ff | ........... ....
0000010 40 a3 b2 01 00 00 07 01 0a cb ff 33 03 e3 0c d5 | @..........3....
0000020 97 50 50 ac be bb ed 94 b9 e9 64 21 20 23       | .PP.......d! #    
uplinkMsg:
0000000 49 00 00 00 00 00 a3 b2 01 00 07 01 00 00 00 1a | I...............
0000010 40 a3 b2 01 00 00 07 01 0a cb ff 33 03 e3 0c d5 | @..........3....
0000020 97 50 50 ac be bb ed 94 b9 e9 77 37 97 4e       | .PP.......w7.N    
Timeout in 678912 us
send message success!
[LoRaWAN] Waiting for downlink ... Channel frequency DL = 926.900 MHz
downlinkMsg:
0000000 49 00 00 00 00 01 a3 b2 01 00 07 01 00 00 00 1d | I...............
0000010 40 a3 b2 01 00 00 07 01 0a cb ff 33 03 e3 0c d5 | @..........3....
0000020 97 50 50 ac be bb ed 94 b9 e9 77 37 97 4e 33 0d | .PP.......w7.N3.
0000030 d6                                              | .                 
MIC mismatch, expected a36a4cbd, got d60d334e
failed, code -7

So I then unplugged the gateway thinking that maybe it was providing a downlink, but I still got the MIC mismatch:

[LoRaWAN] Sending uplink packet ... Channel frequency UL = 905.100 MHz
uplinkMsg pre-MIC:
0000000 c0 00 04 01 0c 00 00 00 a2 a2 00 20 fc ff ff ff | ........... ....
0000010 40 a3 b2 01 00 00 23 01 0a d5 cf 34 96 60 0b 69 | @.....#....4.`.i
0000020 08 a6 03 4b 23 a5 65 13 80 0c 64 21 20 23       | ...K#.e...d! #    
uplinkMsg:
0000000 49 00 00 00 00 00 a3 b2 01 00 23 01 00 00 00 1a | I.........#.....
0000010 40 a3 b2 01 00 00 23 01 0a d5 cf 34 96 60 0b 69 | @.....#....4.`.i
0000020 08 a6 03 4b 23 a5 65 13 80 0c 9d 5e 8a cb       | ...K#.e....^..    
Timeout in 678912 us
send message success!
[LoRaWAN] Waiting for downlink ... Channel frequency DL = 926.900 MHz
downlinkMsg:
0000000 49 00 00 00 00 01 a3 b2 01 00 23 01 00 00 00 1d | I.........#.....
0000010 40 a3 b2 01 00 00 23 01 0a d5 cf 34 96 60 0b 69 | @.....#....4.`.i
0000020 08 a6 03 4b 23 a5 65 13 80 0c 9d 5e 8a cb 33 0d | ...K#.e....^..3.
0000030 d6                                              | .                 
MIC mismatch, expected 190b9a3c, got d60d33cb
failed, code -7

Three questions: first, is this expected behavior? second, is it possible that the STM32wle5 is unexpectedly being interrupted and the "received downlink" is random information from memory? Finally, what is causing the "Timeout in 678912 us" debug message to print?

[StevenCellist]

@davidfobar I am not mister Gromes himself, but the current downlink implementation is indeed very poor at receiving downlinks. Other LoRa-ish waves (of which there are a lot in the US ISM band) are also listened to in the current state of the code, they cause the code to think there's a downlink, it starts receiving and ends up with some gibberish not intended for your device. Work is in progress on my side to improve this.
Don't worry about that timeout, the uplink should be sent within that time and you can see "success" so that's alright.

[jgromes]

@davidfobar it looks like the downlinkMsg buffer is identical to the previous uplinkMsg. The only difference is the length and couple of bytes in the first 16 bytes, which are not actually read from the device, but copied to aid MIC calculation. It could be possible that this is some memory management issue.

The "Timeout in" debug message is the transmission timeout.

@StevenCellist if this really was a non-LoRa transmission triggering the CAD, then it is quite strange the packet length passes the checks. It also seems to be a consistent issue, I would expect spruious packets to be random. Finally, it doesn't explain the identical content of the buffer.

[davidfobar]

while attempting to debug, I #define RADIOLIB_STATIC_ONLY, which resulted in a compile error unrelated to my project:
.pio/libdeps/lora_e5_mini/RadioLib/src/protocols/APRS/APRS.cpp: In member function 'int16_t APRSClient::sendPosition(char*, uint8_t, char*, char*, char*, char*)':
.pio/libdeps/lora_e5_mini/RadioLib/src/protocols/APRS/APRS.cpp:65:8: error: 'len' was not declared in this scope; did you mean 'lon'?
65 | info[len] = '\0';
| ^~~
| lon
*** [.pio/build/lora_e5_mini/lib6cb/RadioLib/protocols/APRS/APRS.cpp.o] Error 1

/////////////////////////////////////////////////////////////////////
int16_t APRSClient::sendPosition(char* destCallsign, uint8_t destSSID, char* lat, char* lon, char* msg, char* time) {
#if !defined(RADIOLIB_STATIC_ONLY)
size_t len = 1 + strlen(lat) + 1 + strlen(lon);
if(msg != NULL) {
len += 1 + strlen(msg);
}
if(time != NULL) {
len += strlen(time);
}
char* info = new char[len + 1];
#else
size_t len = RADIOLIB_STATIC_ARRAY_SIZE; // <-- I added this
char info[len];
#endif

[davidfobar]

Another data point, I stopped initializing the device using beginOTAA, and rather starting using the persistent storage. This creates two issues,
1 - chirpstacks doesn't handle the power cycle and keys automatically so the packets are seen by the gateway, but not registered in the application (not a radiolib issue)
2 - during the channel configuration of the downlink I get a RADIOLIB_ERR_INVALID_SPREADING_FACTOR error code.

I cleared the error code by adding the following to LoRaWANNode::Begin():
// setup uplink/downlink frequencies and datarates
state = this->setupChannels();
RADIOLIB_ASSERT(state);

But that causes a RADIOLIB_ERR_DOWNLINK_MALFORMED error to be thrown further into the downlink function call.

[jgromes]

@davidfobar I addressed the first issue with static memory management, the rest will need some more investigation from my side.

[StevenCellist]

@davidfobar if you are still on this issue, could you check out #867 and see if that PR solves your issue? Please let us know whether the problem persists.

[jgromes]

@davidfobar #867 was just merged - my understanding is that it also resolves this issue. Could you please confirm? Otherwise I will have to close this as stale as per the contributing doc. Thanks!

[jgromes]

Closed due to inactivity.