I ask this question in this forum, because maybe one of the TTN users experienced a similair problem.
We have devices (APB not OTAA) for TTN but also for another commercial provider.
One type of devices has very strange behaviour…with TTN the payload and meta data is okay, but with the other provider (not TTN :the dutch users know the name of the company) we see the meta data correct but the payload data is a mess.
But when I use another type of lora device (based on 32u4 and RFM95W and LMIC latest) it works perfect with TTN and the other provider for the metadata and the payload aswell .
Are there slight differences in the lorawan version between TTN , the other provider and possible my firmware what result in the misbehaving of the device ? Or is TTN more tollerant ?
greetings
Koen
Moderator note: to alert other users, I’ve edited the title of this topic, even though the cause was not yet clear in the first posts.
Sounds to me that at KPN you’ve not used the proper ABP keys. When the secrets in the device are different from the ones the provider knows, then it cannot successfully decrypt the message.
Just like with TTN, I’d assume that if you see data but it is not decrypted correctly, then the DevAddr and NwkSKey are okay (as those are used to validate the MIC), but the AppSKey might be wrong. (Or maybe reversed.)
Arjan,
Thanks for your reply. I tested the same keys from the commercial provider in one of my own build 328p nodes and it worked perfect. (as it also did with TTN keys).
Now the problematic node is a LSN-50 (based on an stm32l…) and it works perfect with TTN and not with the commercial provider. … I did the test more than twice and did an extra check for typing errors.
I also saw the message from the problem node to the commercial provider and I received it with my TTN gateways…with the keys I could decode it and concluded the sended message was okay
So I don’t think it’s keys , otherwise the test with the 328P would have gone wrong and they didn’t. Also the problem node I can configure perfect with TTN keys …no problem …good data…so I don’t think these are the keys.
Did see something strange…the working device works with Fport1 and the not working device with Fport2, while the Appskeys I bought from the commercial provider had a remark with (Fport1).
l hope this is the cause of the problem. (Never had this problem with TTN)
Wow. TTN indeed does not care which port the application uses; anything from 1 to 223 is just accepted. KPN might be different, though I’d find that quite weird. (And also find it weird that it would then show an unreadable payload, which to me sounds like it cannot decrypt it.)
The problem is solved… TTN doesn’t care which FPORT (1…255) (FPORT0 is used for Lora system commands and it’s reserved for it). But be aware other Lora providers in the Netherlands where you can buy the bussiness lora keys individual are only allowing FPORT1. If you don’t use it, the data is a mess and the meta data is readable.
Lucky the manuafacturer (Dragino) changed the firmware yesterday and now it’s possible to read the data at TTN and the commercial provider.
I feel KPN is doing something wrong here. The LoRaWAN specifications state:
FPort values 1…223 (0x01…0xDF) are application-specific and any received frames with such an FPort SHALL be made available to the application layer by the LoRaWAN implementation.
What was the full remark you got with the AppSKeys, or did it only say “(Fport1)”?
I’d file a bug with KPN. The ports are quite useful to limit the application payloads by using different ports for different situations, without the need to encode the message type into the application payload. And off-the-shelf devices might not allow for changing the port.
That would also explain why the payload could not be decrypted, but no warning was shown.
There is no way to tell if decryption was successful. The MIC validates the message, but that uses the NwkSKey. Next, when using the wrong AppSKey for the decryption one simply gets different results, but no error.
But I don’t think I’d like multiple keys for a single device.
Message are sent to and from devices using a LoRa port. Each port can have a different AppSKey and connected Application server. Ports can have values 1-223. Other values are reserved for network and testing purposes.
So, they also allow for different application servers.
(Though I don’t see a use case that really needs that, it might be nice to, e.g., have nodes calling in to some reporting/maintenance server. But that would just create more overhead due to requiring multiple transmissions, each with LoRaWAN headers.)
Moderator note: to alert other users, I’ve edited the title of this topic, even though the cause was not yet clear in the first posts.