MIC always wrong for packets from Oyster? about lora-packet HOT 3 CLOSED

I just figured out (thanks to TTN Slack) that the Oyster is quite possibly the device is sending LoRaWAN v1.1 packets... can that be seen with the above?

from lora-packet.

Quite late, but: no, one cannot tell the version from a LoRaWAN packet. A device can tell if it gets a 1.0.x or 1.1.x Join Accept (this allows it to fall back to 1.0.x if the server does not understand 1.1), but in regular uplinks and downlinks this cannot be seen.

However:

MIC = 6695F9CC (BAD != F9CC34D1)

Above, note that the F9CC part matches, and that is by design. That part is calculated just like a 1.0.x MIC, but in 1.1 only 16 bits are included in the full 32 bits MIC. To calculate the other 16 bits, one must also know at which data rate and channel the uplink was transmitted (and, in case of a downlink confirmation, also the downlink's frame counter), along with the secret SNwkSIntKey.

So maybe the answer is actually: yes, when using the 1.0 validation on a 1.1 packet, then when seeing that those 16 bits match, one can assume it's a valid 1.1 packet. And hence I'd say this issue can be closed.

(You can try yourself, but that does not add much.)

from lora-packet.

excellent, thank you for the analysis!

from lora-packet.