OTAA failed / Debugging device activation OTAA issues

Hi guys, I´ve RESOLVED my problem.
Debuging the node side and the server side, JOIN REQ/RESP loop, I realize the NS and the JS, were working fine.
Captura
But the downlink wasn´t received by the node. So, all the process started again and again. Sometimes, at begining (first packet) I got a succesful JOIN in the node at specific band, but then the next packets did not received the ACK downlinks, and the JOIN process started again.
That conducted us to focus in the subbands the node and the gateway were working(we have two: a Kerlink IfemtoCell and a Raspberry RAK-831). Finally we noted, we had a bad configuration in the loraserver configuration file. It was working in 868, and we were working in the AU915. (Begginer error)
Changing this configuration, the node join quickly and “Join Req” packet are not sent anymore.

1 Like

Good Day,
I’ve installed lora server + lora app server on AWS ec2 ubuntu18.04 machine.
And I have installed lora gateway os base on RAK831 gateway connected to raspberry pi.
the problem is that the lora server and lora app server receive the join request and reply with success, but the node shows failed to join network, as you can see in the screenshot.
I checked the LoRaWAN MAC version, and it’s correct 1.0.2
Thanks in advance.

I don’t think the screenshot shows the log of the device itself?

Hey SrTomate,
In order to operate in the AU915, did you set loraserver configuration with: enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7] or enabled_uplink_channels=[8, 9, 10, 11, 12, 13, 14, 15] ?
I set the LoRaWAN MAC version to 1.0.2 for device profile.
At node, I use an esp8266 and LMIC library, and define LMIC_selectSubBand(1) but it doesn´t work.
The Join Request/Accept loop remains in the loraserver and node can’t Join.
If I use the TTN network it works very well…

Anyone can help me ?

1 Like

Hi,

Try with :
enable_uplink_chanel=[]

And:
LMIC_selectSubBand(0)

That works for me

I tried enable_uplink_chanel=[] and LMIC_selectSubBand(0) but it still remains the same JoinRequest/JoinAccept messages and the node without Join success.

Well, I ill try to present some debug here from Node, Gateway and LoraServer with Gateway Bridge. I have a raspberry PI gateway with “FTDI SPI-over-USB bridge using libmpsse/libftdi/libusb” , and this gateway is configured with AU915 global_conf.json from TTN (https://github.com/TheThingsNetwork/gateway-conf). The gateway is working with TTN + OTAA without any problem. But with loraserver it never worked…

I used two approaches that works with my raspberry PI gateway FTDI in order to test it with loraserver (in both cases, it appears that the gateway receives the JoinAccept message…):

1) Gateway with lora_gateway and packet_forwarder from Jac Kersing (https://github.com/kersing/). The node never receives the JoinAccept and the manily parts of debug are presented below for NODE, GATEWAY and LORASERVER, with some private information replaced with generic text:

NODE ESP8266 + LMIC + nicerf-SX1276 (serial output)

14732855: TXMODE, freq=917800000, len=23, SF=12, BW=125, CR=4/5, IH=0
start single rx: now-rxtime: 4
15135900: RXMODE_SINGLE, freq=926300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 15148832 rxtime: 15135732 entry-rxtime: 13100 now-entry: 6 rxtime-txend: 310196
start single rx: now-rxtime: 4
15197885: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 15207459 rxtime: 15197720 entry-rxtime: 9739 now-entry: 5 rxtime-txend: 372184
15208025: engineUpdate, opmode=0xc
15255402: engineUpdate, opmode=0xc

GATEWAY (https://github.com/kersing) (sudo tcpdump -AUq port 1700)

21:09:46.850812 IP gateway_ip.54224 > loraserver_ip.1700: UDP, length 237
E..     ..@.@.E.

..

........C.............{"time":"2019-08-29T00:09:46Z","rxpk":    [{"tmst":92726020,"chan":5,"rfch":1,"freq":917.800000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":-16.0,"rssi":-97,"size":23,"data":"hidden"}]}

21:09:46.851753 IP loraserver_ip.1700 > gateway_ip.54224: UDP, length 4
E.. .t@.?..C

..

.........c..................

21:09:47.065270 IP loraserver_ip.1700 > gateway_ip.55156: UDP, length 193
E....y@.?...

..

.....t.....:z.{"txpk":{"imme":false,"rfch":0,"powe":27,"ant":0,"brd":0,"tmst":97726020,"freq":926.3,"modu":"LORA","datr":"SF12BW500","codr":"4/5","ipol":true,"size":17,"data":"hidden"}}

21:09:47.068347 IP gateway_ip.55156 > loraserver_ip.1700: UDP, length 12
E..(..@.@.E.

..

...t....B;.:z.........

LORASERVER ( journalctl -u loraserver -f -n 50 )

ago 28 21:09:46 linux loraserver[22908]: time="2019-08-28T21:09:46-03:00" level=info msg="gateway/mqtt: uplink frame received"
ago 28 21:09:47 linux loraserver[22908]: time="2019-08-28T21:09:47-03:00" level=info msg="packet(s) collected" dev_eui=eui_number gw_count=1 gw_ids=gateway_id mtype=JoinRequest
ago 28 21:09:47 linux loraserver[22908]: time="2019-08-28T21:09:47-03:00" level=info msg="device-queue flushed" dev_eui=eui_number
ago 28 21:09:47 linux loraserver[22908]: time="2019-08-28T21:09:47-03:00" level=info msg="device-session saved" dev_addr=xxxx dev_eui=eui_number
ago 28 21:09:47 linux loraserver[22908]: time="2019-08-28T21:09:47-03:00" level=info msg="device-activation created" dev_eui=eui_number id=xxxx
ago 28 21:09:47 linux loraserver[22908]: time="2019-08-28T21:09:47-03:00" level=info msg="device updated" dev_eui=eui_number
ago 28 21:09:47 linux loraserver[22908]: time="2019-08-28T21:09:47-03:00" level=info msg="gateway/mqtt: publishing gateway command" command=down gateway_id=gateway_id qos=0 topic=gateway/gateway_id/command/down
ago 28 21:09:47 linux loraserver[22908]: time="2019-08-28T21:09:47-03:00" level=info msg="downlink-frames saved" dev_eui=eui_number token=xxxx
ago 28 21:09:47 linux loraserver[22908]: time="2019-08-28T21:09:47-03:00" level=info msg="backend/gateway: downlink tx acknowledgement received" gateway_id=gateway_id

2) Gateway with lora_gateway and packet_forwarder from Mirakonta (https://github.com/mirakonta). The node also never receives the JoinAccept and the manily parts of debug are presented below for NODE, GATEWAY and LORASERVER, with some private information replaced with generic text:

NODE ESP8266 + LMIC + nicerf-SX1276 (serial output)

76868370: TXMODE, freq=917600000, len=23, SF=12, BW=125, CR=4/5, IH=0
start single rx: now-rxtime: 4
77271414: RXMODE_SINGLE, freq=925700000, SF=12, BW=500, CR=4/5, IH=0
start single rx: now-rxtime: 4
77333402: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
rxtimeout: entry: 77342974 rxtime: 77333235 entry-rxtime: 9739 now-entry: 5 rxtime-txend: 372184
77343526: engineUpdate, opmode=0xc
77361726: engineUpdate, opmode=0xc

GATEWAY (https://github.com/mirakonta) (sudo tcpdump -AUq port 1700)

21:26:21.039219 IP gateway_ip.54537 > loraserver_ip.1700: UDP, length 245
`.J....@(......1.....
w.(................     ....Z..\..........{"rxpk":[{"tmst":203307428,"time":"2019-08-29T00:26:21.038919Z","chan":4,"rfch":1,"freq":917.600000,"stat":1,"modu":"LORA","datr":"SF12BW125","codr":"4/5","lsnr":-14.2,"rssi":-97,"size":23,"data":"hiden"}]}
21:26:21.040339 IP loraserver_ip.1700 > gateway_ip.54537: UDP, length 4
`......?(...............(......1.....
w....   .....\..
21:26:21.251902 IP loraserver_ip.1700 > gateway_ip.34433: UDP, length 194
`..C...?(...............(......1.....
w.............{"txpk":{"imme":false,"rfch":0,"powe":27,"ant":0,"brd":0,"tmst":208307428,"freq":925.7,"modu":"LORA","datr":"SF12BW500","codr":"4/5","ipol":true,"size":17,"data":"hidden"}}
21:26:22.517945 IP6 gateway_ip.34433 > loraserver_ip.1700: UDP, length 12
`       .....@(......1.....
w.(...................................
21:26:22.518746 IP loraserver_ip.1700 > gateway_ip.34433: UDP, length 4
`..C...?(...............(......1.....
w.............

LORASERVER ( journalctl -u loraserver -f -n 50 )

ago 28 21:26:21 linux loraserver[22908]: time="2019-08-28T21:26:21-03:00" level=info msg="gateway/mqtt: uplink frame received"
ago 28 21:26:21 linux loraserver[22908]: time="2019-08-28T21:26:21-03:00" level=info msg="packet(s) collected" dev_eui=eui_number gw_count=1 gw_ids=gateway_id mtype=JoinRequest
ago 28 21:26:21 linux loraserver[22908]: time="2019-08-28T21:26:21-03:00" level=info msg="device-queue flushed" dev_eui=eui_number
ago 28 21:26:21 linux loraserver[22908]: time="2019-08-28T21:26:21-03:00" level=info msg="device-session saved" dev_addr=xxxxx dev_eui=eui_number
ago 28 21:26:21 linux loraserver[22908]: time="2019-08-28T21:26:21-03:00" level=info msg="device-activation created" dev_eui=eui_number id=6008
ago 28 21:26:21 linux loraserver[22908]: time="2019-08-28T21:26:21-03:00" level=info msg="device updated" dev_eui=eui_number
ago 28 21:26:21 linux loraserver[22908]: time="2019-08-28T21:26:21-03:00" level=info msg="gateway/mqtt: publishing gateway command" command=down gateway_id=gateway_id qos=0 topic=gateway/gateway_id/command/down
ago 28 21:26:21 linux loraserver[22908]: time="2019-08-28T21:26:21-03:00" level=info msg="downlink-frames saved" dev_eui=eui_number token=11692

Maybe I should install TTN stack in order to test, but I’d rather loraserver to work…

Anybody can help me ?

I am experiencing the same problems. None of my nodes can connect through OTAA to loraserver.
Connecting them via OTAA to TTN is no problem.

I debugged a bit deeper with a Arduino LMIC node with STM32 CPU. It seems, that the node does not even receive a response from the gateway.
Could this be a wrong timing of the messages or the node listening on a different channel?

It could be both. You can check your loraserver configuration file. I have my channels defined
as enabled_uplink_channels=[8,9,10,11,12,14,15] for US915 region (I have a RAK 8 channels gateway).

Also you need to tell LMIC to use the upper sub band by calling LMIC_selectSubBand(1);

Timing is a big issue with Arduino, due to the lack of high precision clocks. So I had to relax the error tolerance for both my ESP32 and SAMD21 Cortex M0+ development boards by calling LMIC_setClockError(5 * MAX_CLOCK_ERROR / 100); after resetting the radio.

There are likely other root causes, but these are the changes I made get OTAA to work with both Loraserver and TTN with my end devices.

One more thing you could also try is to set this to false in your channel configuration "lorawan_public": false, For TTN it is set to true.

Note that primarily concerns the preamble used and detected by the node and gateway radios. For the node this is configured in code. For the gateway it is originally in the gateway configuration, in some cases LoRaServer may be able to command the gateway to change, but in many it cannot.

Packets with a mismatched preamble do “leak” through at a not trivial rate, but they are much less likely to be received than packets with a matching one, I’d say by at least a factor of four times less likely.

I dont know if this will help anyone else but if implementing mosquitto ACLs make sure to allow your gateway to access the topic

   topic write gateway/<gatewayid>/command/+
   topic read gateway/<gatewayid>/command/+

I spent ages trying to get my device to join the network but JACC never hit the gateway as soon as I added this into my Mosquitto ACL file all worked first time.

Good luck

Thanks for your suggestions. Unfortunately I am using EU868 region, so some suggestions cannot be set.

But I investigated I bit more in my problem. I had this problem with my first gateway (RaspberryPi based with IMST iC880A-SPI). I changed now to a Ursalink gateway (which uses internally also mp-packet-forwarder) and it is working with that.
I tried to analyze the lora air traffic with a RTL SDR radio and I saw, that the downlink messages are much too long for Join Accept messages. At the moment I think there is something defective in the gateway software or in the communication to the gateway.

That seems a little unlikely. What did you see, and what did you expect?

Anyway, rather than try to interpret things with an SDR, you’d be better off looking at the gateway traffic page or subscribing to the gateway’s MQTT transmit topic in parallel so you can snoop on what it is being told to do. See if that matchers your expectations - if not, re-verify your expectations before deciding that what you are seeing is wrong.

I could solve my issue through updating my gateway software. I am using the mp_pkt_fwd (https://github.com/kersing/packet_forwarder/tree/master/mp_pkt_fwd).
There seems to be an overflow in the software which seems to be solved some days ago.

1 Like

I’ve also updated my gateway software (mp_pkt_fwd) and the OTAA activation is working ok now. The problem really seems to be that overflow in the mp_pkt_fwd software.

Greeting guys, I’m facing exactly the same problem, using RAK 7246G gateway with the last firmware version available in their website:https://downloads.rakwireless.com/LoRa/NeoPi-Gateway-RAK7246/Firmware/

Could you explain how could I update just the packet forwarder with mp_pkt_fwd?

Just to introduce the other informations:

  • I’m in Brazil, so I’m using AU915_928 frequency standards;
  • I’m using a RAK 7246G (with GPS) with their last firmware version (semtech packet forwarder);
  • I have a Linux server with chirsptack-network-server and chirpstack-application-server installed and running fine;
  • I’ve tried different end nodes, such as MCCI-Catena (arduino nano), Heltec LoRA WAN, different radios (Dragino shield, and SX1276 modules) and ended up facing exactly the same problem:
    I see both JoinRequest and JoinAccept in the chirpstack GUI, I don’t see any errors in the logs (journalctl), I can see the uplinks and the downlinks but the end nodes doesn’t receive the JoinAccept answer, and I end up having this JoinRequest-Accept loop.

Solved by replacing the packet forwarder to mp_pkt_fwd!
I reported this bug back to RAK developers in their github rak_common_for_gateway

Hi,

I meet exactly the same problem and solutions mentioned does not worked for me.

I use pi hat from pisupply in 868.
I use loraserver on a debian machine with docker images provided here https://github.com/brocaar/chirpstack-docker

On my rpi gateway, I use mp_pkt_fwd and it is configured to connect to the loraserver in the local_config.json

I can see JoinRequest and JoinAccept.
I can see too this log on network server :
time="2020-12-21T17:20:41Z" level=info msg="gateway/mqtt: publishing gateway command" command=down downlink_id=48f5badb-7a2d-4b5f-b5e5-b515040eb6b5 gateway_id=ac10b54a129207a0 qos=0 topic=gateway/ac10b54a129207a0/command/down

But my device (rak7200) still says join failed.

All is fine if I configure mp_pkt_fwd with ttn.

Every one in this topic solved their issue ?

Thanks

Hello friends.

I have a similar problem with Microchip’s RN2903A, it is configured OTAA mode, AU915, SF10 and it is connected through a Gateway Dragino LG02 to a private Chirpstack server (Gateway-bribge, network and application).

It remains in a loop in JoinRequest / JoinAccept, but in the devices tab> activation, it is evident that the device is activated but always the AppSKey is “000000000000000000000000000”.

I use the online tool https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/, to validate the integrity of the lora package and it appears correct.

I look forward to your help.

Thank you.

1 Like

Hi @carloscha82, I am seeing the same error in Argentina. Same settings as you but with a Dragino LPS8 gateway. Do you know what might be happening @brocaar? I can send you more information if you need. Thanks!