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).
@tfssweb 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.
@tfssweb
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)
Hi
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
Thanks
Johnjoe
Hi there,
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[668]: 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.
HI
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.
After studying this thread in detail i still cannot resolve this same error.
Situation as follows:
- Using Pycom Lopy4 devices with Pycom LoraWAN stack. Device profile set to lorawan 1.02
- All devices are using OTAA
- All devices configured as Class C
- Join process successful and activation keys automatically generated in Application Server
- Disable frame-counter validation is enabled
- My network-server log is full of these messages (error=âget device-session error: device-session does not exist or invalid fcnt or micâ).
As i have 30 devices deployed how can i work out which devices are sending these messages - can i trace back from the ctx_id? I canât figure out if error is being generated from a small subset of devices or all devices (they are all loaded with same firmware and using same device profile).
What more can i try to remove this error.
Thanks in advance for any assistance offered.
Regards
Alan
Bump - can anyone give me some ideas to help here please?
Thanks