The 6005050201A004003526F2A1 was catught by pkt-fwd log so I couldn’t get the whole MIC.
The whole MIC of 6005020201A00400DD59B184 is MIC: dd59b1846b8d4cbeec1bc23faec8a09f.
I calculated the MIC with RFC 4993 as Lora protocol says. The whole MIC of RFC 4993 is 128-bits as URL https://tools.ietf.org/html/rfc4493. The Lora only use the first 32-bits.
I didn’t understand the un-transmitted portion. When I calculated the MIC DD59B184 I only used the frame 6005050201A00400 without any other data.
I tested both PHYPayload with lora-packet-decode cmd as below. Both are valid.
[root@monitoring ~]# lora-packet-decode --nwkkey 2B7E151628AED2A6ABF7158809CF4F3C --appkey 2B7E151628AED2A6ABF7158809CF4F3C --hex 6005050201A004003526F2A1 decoding from Hex: 6005050201A004003526F2A1 Decoded packet -------------- Message Type = Data
Doing what you did “without any other data” is not in accordance with the LoRaWAN specification.
Please read the LoRaWAN specification of the MIC, paying particular attention to the definition of the B0 block, which must include all 32 bits of the frame count, even though only 16 bits are transmitted.
Also simply think about it logically - you can’t have the same input, follow the same procedure, and get two different answers. For different answers to result from the same procedure, the input must differ.
But as the B0 block says I think if the simplest msg is the same the B0 block should be the same too. So I was confused why the same msg have diffrent valid MIC.
No, because for the third time and as shown in your quote above, the MIC includes the full 32 bit frame count (4 bytes), while only 16 bits (2 bytes) are transmitted as part of the message.
So I was confused why the same msg have diffrent valid MIC
The same circumstances cannot yield a different result not only as that is the basis of mathematics, but practically because otherwise the whole idea of using the MIC to (provisionally) validate a message would not work. Different circumstance can occasionally collide to produce the same result, but the same circumstances can never produce a different result, or the whole thing would be unworkably broken.
Your mistaken belief that it does occurs because you are either ignoring a difference in inputs, or because the belief that one of the MICs is valid is itself mistaken.
When you figure out all of the inputs into the calculation for validating the MIC, you’ll figure out what the difference driving the difference in MICs is, or you’ll find that one of them is wrong and invalid.