Get device-sessions for dev_addr error: object does not exist


#1

Hi all,

I am total new to loraserver.

And yes, I already have searched this forum and google for hours, but none of the suggested solutions worked for me…

The LoRa-Server keeps getting me the following error, when executing “journalctl -f -n 100 -u loraserver”:
—start—
Mai 07 18:52:05 LoRa-Server loraserver[5766]: time=“2019-05-07T18:52:05+02:00” level=info msg=“gateway/mqtt: uplink frame received”
Mai 07 18:52:05 LoRa-Server loraserver[5766]: time=“2019-05-07T18:52:05+02:00” level=warning msg=“get device-sessions for dev_addr error: object does not exist” dev_addr=00151a2a dev_eui=0059ac0000151a2a
Mai 07 18:52:05 LoRa-Server loraserver[5766]: time=“2019-05-07T18:52:05+02:00” level=error msg=“processing uplink frame error” data_base64=“QCoaFQCAAAABHsyT7spz/FujTeKFKgM66ZdsWv0=” error=“get device-session error: device-session does not exist or invalid fcnt or mic”
—end—

This is the ourput from the packet-forwarder:
—start—
Packet RSSI: -50, RSSI: -88, SNR: 11, Length: 29
rxpk update: {“rxpk”:[{“tmst”:158033890,“chan”:0,“rfch”:0,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF12BW125”,“codr”:“4/5”,“lsnr”:11,“rssi”:-50,“size”:29,“data”:“QCoaFQCAAAABHsyT7spz/FujTeKFKgM66ZdsWv0=”}]}
—end—

This is seen via mosquitto:
—start—
gateway/b827ebffffac0041/rx {“rxInfo”:{“mac”:“b827ebffffac0041”,“timestamp”:158033890,“frequency”:868100000,“channel”:0,“rfChain”:0,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-50,“loRaSNR”:11,“size”:29,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:12,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“QCoaFQCAAAABHsyT7spz/FujTeKFKgM66ZdsWv0=”}
—end—

My Setup:

I followed all and every trouble-shooting I can find at loraserver.io. All seems to be all right, except above error message. Inside the Web-UI I can see the “UnconfirmedDataUp” - Frames (under Gateway).

I already double-, tripple- and quadrupel-checked DevEUI, LSB/MSB, upper-case/lower-case.
The device does exist with the correct DevEUI in my applocation and the App-Key for OTAA is correct.
I also disabled the fcnt for that device.

So I am totally clueless at the moment and any help is very much welcome…

Greets
Thomas


#2

Is your device actually running in OTAA mode?

Did it have a join session with this instance of LoRa Server?

It sounds like it’s probably using either a compiled-in session (ie ABP) or using keys from some join session that the current instance of LoRa Server is not aware of.


#3

Hi cstratton,

according to the vendor, the device should be in both OTAA and ABP.
At least I got needed Keys for both from the vendor. Sadly the device
cannot be configured by me. I will phone them today to confirm this.

How do I check for a join-session ?
As I said before, I am totally new to LoRa-WAN and LoRa-Server…

What confuses me is the fact, that I receive packets as “UnconfirmedDataUp”.
As far as I know it should be “DataUp” instead…

I assume the packet-flow (device -> radioTX -> radioRX -> packet-forwarder -> lora-gw-server -> lora-server -> lora-app-server) itself is working, since I can see the received frames in the web-ui.

Here is the JSON of one received frame:

[
{
“uplinkMetaData”: {
“rxInfo”: [
{
“gatewayId”: “b827ebffffac0041”,
“time”: null,
“timeSinceGpsEpoch”: null,
“timestamp”: 2696192608,
“rssi”: -49,
“loraSnr”: 12,
“channel”: 0,
“rfChain”: 0,
“board”: 0,
“antenna”: 0,
“location”: {
“latitude”: 51.17983,
“longitude”: 7.03231,
“altitude”: 182,
“source”: “UNKNOWN”,
“accuracy”: 0
},
“fineTimestampType”: “NONE”
}
],
“txInfo”: {
“frequency”: 868100000,
“modulation”: “LORA”,
“loRaModulationInfo”: {
“bandwidth”: 125,
“spreadingFactor”: 12,
“codeRate”: “4/5”,
“polarizationInversion”: false
}
}
},
“phyPayload”: {
“mhdr”: {
“mType”: “UnconfirmedDataUp”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“fhdr”: {
“devAddr”: “00151a2a”,
“fCtrl”: {
“adr”: true,
“adrAckReq”: false,
“ack”: false,
“fPending”: false,
“classB”: false
},
“fCnt”: 42,
“fOpts”: null
},
“fPort”: 1,
“frmPayload”: [
{
“bytes”: “j5xu+zsIUydnBikZ78YsCQ==”
}
]
},
“mic”: “de8de21d”
}
}
]

Thomas

BTW: Is there any code-tag in this forum ?


#4

I had a long phone-call with the guy selling me the devices.

Despite the fact he send me the OTAA-Keys for the device, it was configured for ABP by default.
Using ABP I can now see frames coming in. For the second device, it seems that OTAA does not work correctly using only 1 channel at 868.100 MHz. I configured that device to use ABP too. After that I can also see frames for that device.

Unfortunately both devices list the frames in “Live Lorawan frames” as “UnconfirmedDataUp” but in “Device Data” they are listed as “uplink”. So I guess all is ok now.

That leaves the task to forward the received data to an own PHP-Script decoding and processing it.

Thanks for pointing me in the right direction :slight_smile:

Greets
Thomas


#5

[quote=“tniercke, post:4, topic:4492”]
Unfortunately both devices list the frames in “Live Lorawan frames” as “UnconfirmedDataUp”[/quote]

That would be the most typical situation. Confirmed data is much more taxing on the network, as a gateway can’t be receiving from other nodes while it is transmitting an ack in reply.

[quote]
That leaves the task to forward the received data to an own PHP-Script decoding and processing it.[/quote]

A simple way could be to subscribe to the application/ mqtt topic, you will also need to decode the base64 encoding of the data, but you should be able to readily find library solutions for both tasks.