Not analog data, data is uploaded by real devices.
Are you using ABP? you also reset the frame-counters at the device. Because of this, LoRa Server rejects these frames as it could as well be a replay-attack. To work around this, you could check the Disable frame-counter validation box (on ABP activation).
Set 1.0.2 LoRaWAN MAC version
Yes, I’ve banned it, but there’s still the problem; another problem is that I’m configured to OTAA and I can’t receive data at all, no matter what.
I’ve basically looked at all the topics related to this issue in the forum, but they haven’t been solved yet. I hope you can help me. Thank you.
Please check LoRaWAN Mac Version (v1.0.2) in device-profile
“For LoRaWAN 1.1 devices, the network session key is replaced by network session encryption key, serving network session integrity key and forwarding network session integrity key” so these values are the same. of topic how you log the left values (loraserver, gatewaybridge, redis, etc)
i receive this error my sensor trys to join.
I had this issue with another sensor and changing the application key to from LSB to MSB was able to fix it for me
but the things mentioned here do not seem to work for the other sensor
The sensor that i cannot get to join
Has lorawan mac version 1.02
And is OTAA
I have tried disable frame counter
I have also tried MSB and LSB for the application key
Is there anything else i am missing that can fix this issue
This device was working with the previous version of the loraserver.io
I have had similar issues as the above, LMIC-Arduino library used with LoRaWAN MAC Version 1.0.2 selected in device-profile with LoRaWAN Regional Parameters set to A. I have got OTAA disabled and trying purely with ABP.
I have disabled frame-counter validation in the device.
I have confirmed my Network session key and Application session key are correct and endianness is correct. I have also checked the raw payload using the lora-packet node.js library, which is able to create the same MIC as in the packet and is able to correctly decode the bytes using the exact settings as defined in the loraserver device settings page.
I am getting the following error in the loraserver logs:
Dec 28 07:14:00 instance-1 loraserver: time=“2018-12-28T07:14:00Z” level=error msg=“processing uplink frame error” data_base64=QEOxhgCATAABMWfam6pCefXtP5sq error=“get device-session error: device-session does not exist or invalid fcnt or mic”
Decoding this base64 to bytes I get “4043b18600804c00013167da9baa4279f5ed3f9b2a”
Which when plugged into the nodejs lora-packet library with the same settings that loraserver has defined, gives me this:
loraserver gateway logs has given me everything that corroborates with what lora-packet has said.
Can confirm MIC is correct between both and I can confirm the decoded bytes in lora-packet are what was sent across.
But it could also be the frame-counter. A re-transmitted uplink will also generate this error. A frame-counter value should only occur once or else it will be seen as a replay-attack.
Thanks for the reply. Following up in case anyone comes across this in the future.
Led me to investigate a bit further and I’ve figured out what I was doing wrong that wasn’t quite obvious (but probably might be obvious to a few off you!)
When I was deleting the device, I wasn’t creating a whole new device with completely randomised device addr, network session key, app session key - just so I didn’t have to repogram my device with new information, I had assumed it would remove all records of the frame count when the device was deleted (which, now that I think about it is completely intended and a good feature).
Ended up creating a new device with all new randomised keys and device address and everything is working swimmingly.
Forgot to update my issue what cause my issue was one of the senors firmware was not up to date so it wasn’t resetting the fcnt it self.
So what i had to do was get it to join the old lora network server i was using send a mac command to the sensor which reset the fcnt and the pressed the button to join and then it join the loraserver.io lora server then no problem.
I have a similar issue, at least I see the same things as I notice: the gateway does pick up my frames and they are processed by LoraServer but somehow the app-server does not see these coming through.
For a specific project I want to update every 10", sometimes the updates are more than 1" dead.
When I track what passes over the gateway I see a steady queu of frames every 10", none are missing.
I would assume that the first filter is the gateway: if checks do not fit in he will not pass the frame to the loraserver. So every frame that arrives at the loraserver, should arrive in the app-server section.
Is this related to the docker environment?
I have the same problems.
When i put in the keys for TTN it works, but when i put in the keys for loraserver.io it doesn’t work.
The sensor wit OTAA authentication sends an JoinRequest and get an JoinAccept. But i only see this in the gateway screen.
The sensor with ABP authentication only sends unauthenticated messages to the gateway end i got the error device-session does not exist or invalid fcnt or mic. (On TTN i got the message ‘Hello World!’)
What is the difference between TTN and loraserver.io…?
I tried to change the keys from LSB to MSB and mixed them also, but nothin works.
One sensor is just an arduino with an dragino lora shield and the second sensor is an TTGO board (with pax-counter software).
After Disable frame-counter validation need re-activate device.