OTAA with Kerlink Station failed

Gateways
1

Hey guys,

i am using the loraserver for the first time. I installed everything and that works fine so far.
I am using a Kerlink Station as a gateway with installed “samtech_packet_forwarder” and the “LoRa Gateway Bridge” works also so far.
But now I added a Node and tried to activate it via OTAA. In the Web Application Server i can see a “JoinRequest” as an upload and a “JoinAccept” as a download. But the “JoinRequest” and “JoinAccept” procedure repeats to infinite. So I can’t integrate the node into my loraserver. What am I doing wrong?
I added the Node with all its Keys.

Here the log on the Kerlink

Feb 26 14:03:46 (none) local1.notice spf: ##### 2018-02-26 13:03:46 GMT #####
Feb 26 14:03:46 (none) local1.notice spf: ### [UPSTREAM] ###
Feb 26 14:03:46 (none) local1.notice spf: # RF packets received by concentrator: 0
Feb 26 14:03:46 (none) local1.notice spf: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Feb 26 14:03:46 (none) local1.notice spf: # RF packets forwarded: 0 (0 bytes)
Feb 26 14:03:46 (none) local1.notice spf: # PUSH_DATA datagrams sent: 1 (113 bytes)
Feb 26 14:03:46 (none) local1.notice spf: # PUSH_DATA acknowledged: 100.00%
Feb 26 14:03:46 (none) local1.notice spf: ### [DOWNSTREAM] ###
Feb 26 14:03:46 (none) local1.notice spf: # PULL_DATA sent: 3 (100.00% acknowledged)
Feb 26 14:03:46 (none) local1.notice spf: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Feb 26 14:03:46 (none) local1.notice spf: # RF packets sent to concentrator: 0 (0 bytes)
Feb 26 14:03:46 (none) local1.notice spf: # TX errors: 0
Feb 26 14:03:46 (none) local1.notice spf: # TX rejected (collision packet): 0.00% (req:71, rej:0)
Feb 26 14:03:46 (none) local1.notice spf: # TX rejected (collision beacon): 0.00% (req:71, rej:0)
Feb 26 14:03:46 (none) local1.notice spf: # TX rejected (too late): 0.00% (req:71, rej:0)
Feb 26 14:03:46 (none) local1.notice spf: # TX rejected (too early): 0.00% (req:71, rej:0)
Feb 26 14:03:46 (none) local1.notice spf: # BEACON queued: 0
Feb 26 14:03:46 (none) local1.notice spf: # BEACON sent so far: 0
Feb 26 14:03:46 (none) local1.notice spf: # BEACON rejected: 0
Feb 26 14:03:46 (none) local1.notice spf: ### [JIT] ###
Feb 26 14:03:46 (none) local1.notice spf: lora_pkt_fwd/src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
Feb 26 14:03:46 (none) local1.notice spf: ### [GPS] ###
Feb 26 14:03:46 (none) local1.notice spf: # GPS sync is disabled
Feb 26 14:03:46 (none) local1.notice spf: ##### END #####
Feb 26 14:03:46 (none) local1.notice spf:
Feb 26 14:03:46 (none) local1.notice spf: JSON up: {“stat”:{“time”:“2018-02-26 13:03:46 GMT”,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:100.0,“dwnb”:0,“txnb”:0}}
Feb 26 14:03:46 (none) local1.notice spf: INFO: [up] PUSH_ACK received in 7 ms
Feb 26 14:03:48 (none) local1.notice spf: INFO: [down] PULL_ACK received in 5 ms
Feb 26 14:03:57 (none) local1.notice spf:
Feb 26 14:03:57 (none) local1.notice spf: INFO: Received pkt from mote: 60000100 (fcnt=46037)
Feb 26 14:03:57 (none) local1.notice spf:
Feb 26 14:03:57 (none) local1.notice spf: JSON up: {“rxpk”:[{“tmst”:2281043652,“chan”:5,“rfch”:1,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9.2,“rssi”:-33,“size”:23,“data”:“AAABAGAy1bNw00MAYDLVs3DseJIRdzs=”}]}
Feb 26 14:03:57 (none) local1.notice spf: INFO: [up] PUSH_ACK received in 20 ms
Feb 26 14:03:57 (none) local1.notice spf: INFO: [down] PULL_RESP received - token[21:165] :slight_smile:
Feb 26 14:03:57 (none) local1.notice spf:
Feb 26 14:03:57 (none) local1.notice spf: JSON down: {“txpk”:{“imme”:false,“tmst”:2286043652,“freq”:868.1,“rfch”:0,“powe”:14,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:17,“data”:“IP0XHk3tBlmNRz+XCicfzMU=”,“brd”:0,“ant”:0}}
Feb 26 14:03:58 (none) local1.notice spf: INFO: [down] PULL_ACK received in 6 ms
Feb 26 14:04:08 (none) local1.notice spf: INFO: [down] PULL_ACK received in 5 ms
Feb 26 14:04:14 (none) local1.notice spf:
Feb 26 14:04:14 (none) local1.notice spf: INFO: Received pkt from mote: 60000100 (fcnt=46037)
Feb 26 14:04:14 (none) local1.notice spf:
Feb 26 14:04:14 (none) local1.notice spf: JSON up: {“rxpk”:[{“tmst”:2297806892,“chan”:6,“rfch”:1,“freq”:868.300000,“stat”:1,“modu”:“LORA”,“datr”:“SF8BW125”,“codr”:“4/5”,“lsnr”:11.8,“rssi”:-37,“size”:23,“data”:“AAABAGAy1bNw00MAYDLVs3CNJR1gFiE=”}]}
Feb 26 14:04:14 (none) local1.notice spf: INFO: [up] PUSH_ACK received in 5 ms
Feb 26 14:04:14 (none) local1.notice spf: INFO: [down] PULL_RESP received - token[128:214] :slight_smile:
Feb 26 14:04:14 (none) local1.notice spf:
Feb 26 14:04:14 (none) local1.notice spf: JSON down: {“txpk”:{“imme”:false,“tmst”:2302806892,“freq”:868.3,“rfch”:0,“powe”:14,“modu”:“LORA”,“datr”:“SF8BW125”,“codr”:“4/5”,“ipol”:true,“size”:17,“data”:“IBdZ10APOr+ucUGge2IjK7Y=”,“brd”:0,“ant”:0}}
Feb 26 14:04:15 (none) local1.notice spf:
Feb 26 14:04:15 (none) local1.notice spf: INFO: Disabling GPS mode for concentrator’s counter…
Feb 26 14:04:15 (none) local1.notice spf: INFO: host/sx1301 time offset=(1519647956s:226094µs) - drift=-372µs
Feb 26 14:04:15 (none) local1.notice spf: INFO: Enabling GPS mode for concentrator’s counter.
Feb 26 14:04:15 (none) local1.notice spf:
Feb 26 14:04:16 (none) local1.notice spf:
Feb 26 14:04:16 (none) local1.notice spf: ##### 2018-02-26 13:04:16 GMT #####
Feb 26 14:04:16 (none) local1.notice spf: ### [UPSTREAM] ###
Feb 26 14:04:16 (none) local1.notice spf: # RF packets received by concentrator: 8
Feb 26 14:04:16 (none) local1.notice spf: # CRC_OK: 25.00%, CRC_FAIL: 75.00%, NO_CRC: 0.00%
Feb 26 14:04:16 (none) local1.notice spf: # RF packets forwarded: 2 (46 bytes)
Feb 26 14:04:16 (none) local1.notice spf: # PUSH_DATA datagrams sent: 3 (526 bytes)
Feb 26 14:04:16 (none) local1.notice spf: # PUSH_DATA acknowledged: 100.00%
Feb 26 14:04:16 (none) local1.notice spf: ### [DOWNSTREAM] ###
Feb 26 14:04:16 (none) local1.notice spf: # PULL_DATA sent: 3 (100.00% acknowledged)
Feb 26 14:04:16 (none) local1.notice spf: # PULL_RESP(onse) datagrams received: 2 (388 bytes)
Feb 26 14:04:16 (none) local1.notice spf: # RF packets sent to concentrator: 1 (34 bytes)
Feb 26 14:04:16 (none) local1.notice spf: # TX errors: 0
Feb 26 14:04:16 (none) local1.notice spf: # TX rejected (collision packet): 0.00% (req:73, rej:0)
Feb 26 14:04:16 (none) local1.notice spf: # TX rejected (collision beacon): 0.00% (req:73, rej:0)
Feb 26 14:04:16 (none) local1.notice spf: # TX rejected (too late): 0.00% (req:73, rej:0)
Feb 26 14:04:16 (none) local1.notice spf: # TX rejected (too early): 0.00% (req:73, rej:0)
Feb 26 14:04:16 (none) local1.notice spf: # BEACON queued: 0
Feb 26 14:04:16 (none) local1.notice spf: # BEACON sent so far: 0
Feb 26 14:04:16 (none) local1.notice spf: # BEACON rejected: 0
Feb 26 14:04:16 (none) local1.notice spf: ### [JIT] ###
Feb 26 14:04:16 (none) local1.notice spf: lora_pkt_fwd/src/jitqueue.c:452:jit_print_queue(): INFO: [jit] queue contains 1 packets:
Feb 26 14:04:16 (none) local1.notice spf: lora_pkt_fwd/src/jitqueue.c:453:jit_print_queue(): INFO: [jit] queue contains 0 beacons:
Feb 26 14:04:16 (none) local1.notice spf: lora_pkt_fwd/src/jitqueue.c:459:jit_print_queue(): - node[0]: count_us=2302806892 - type=0
Feb 26 14:04:16 (none) local1.notice spf: ### [GPS] ###
Feb 26 14:04:16 (none) local1.notice spf: # GPS sync is disabled
Feb 26 14:04:16 (none) local1.notice spf: ##### END #####
Feb 26 14:04:16 (none) local1.notice spf:
Feb 26 14:04:16 (none) local1.notice spf: JSON up: {“stat”:{“time”:“2018-02-26 13:04:16 GMT”,“rxnb”:8,“rxok”:2,“rxfw”:2,“ackr”:100.0,“dwnb”:2,“txnb”:1}}
Feb 26 14:04:16 (none) local1.notice spf: INFO: [up] PUSH_ACK received in 39 ms
Feb 26 14:04:18 (none) local1.notice spf: INFO: [down] PULL_ACK received in 5 ms

2

Did you try ABP? Does your configuration work with ABP?

Where are the components (LoRa-Gateway-Bridge / LoRaServer / LoRaAppServer) installed? On the Kerlink or on a different machine? If on a different machine, how do you connect to it, by Ethernet or 3G?

3

Thank you for your response.

Yes I tried ABP and it didn’t work. I don’t think that this is an issue with the endianness because I can see the JoinRequests on the App-Server for the device_eui.
Does the device do a JoinRequest on ABP or how do the device know that it is registered?
The node is a ultrasonic sensor from nemeus.fr.

LoRa-Gateway-Bridge is installed on the Kerlink Gateway.
LoRaServer / LoRaAppServer / MQTT / Postgres are installed on a virtual machine in a data center and it’s connected by ethernet. Ping is less than 2ms. As I can see it in the logs the gateway communicates with the loraserver.

4

When you both see the RX (received by the gateway) and TX (request to transmit by the gateway), then all keys should be alright. Have you had success with other LoRaWAN networks and this device? Just to make sure that it is not the device causing this issue.

5

On ABP, there is no join request as the necessary keys are already known by both the end-node and the server. Did you follow what is on https://docs.loraserver.io/lora-app-server/use/devices/ ?

6

The support says they tested their devices with the networks Objenious, Orange, SwissCom, KPN, TTN. I have no chance to See the tx from the Gateway this Device is a Black Box for me.

They care About the 75% crc fails in the log above. What Do you think?
The Gateway and the Device Are in the Same Room for testing.

They also told me that there is no apb anymore due to security reasons.

7

When I add a gateway, I can select a channel-configuration but after that when I look into the gateway configurations I can’t see a selected channel-configuration (it’s empty). And it shows no result if I click on it.
Is this right?

8

That could be a problem, specially if you are using SF12 (data rate 0) on the node. Try with DR5 and put the node more far away.

Sorry, who is “they”? Is it Kerlink? As far as I know, ABP is still part of the LoRaWAN specifications, so I really don’t understand what they mean by that… (but this is off-topic and not related to the problem you shared with us).

9

With they I mean the manufacturer of the ultrasonic sensor. So my node don’t support ABP anymore.

The support of my ultrasonic sensor told me the same to join the network at a higher distance to the gateway.

The second point could be that the JoinAccept message don’t list a CFList? How can I change it at loraserver?
I added extra channels at network-server and typed “0,1,2” for enabled channels. But there is no CFList.

10

I am no expert on LoRaWAN, but I think if joining by OTAA is not succesful, then the node doesn’t get information on available channels. But @brocaar will have a better answer to that.

So I would suggest first try to put the node farther away form the gateway, perhaps that will give a solution to all problems.

11

In the LoRaWAN Spec 1.0.2 you can see that there is an optional CFList in the JoinAccept message. But you’re right if the node don’t recive this message it can’t notice of a CFList. But my problem is that in the log I can’t see a CFList in the JoinAccept message.

But for now I will try it now a greater distance first :wink:

12

Don’t use the enabled_uplink_channels for this

  # Use this when ony a sub-set of the by default enabled channels are being
  # used. For example when only using the first 8 channels of the US band.

See the extra_channels section in the loraserver.toml config:

  # Extra channels to use for ISM bands that implement the CFList
  #
  # Use this for LoRaWAN regions where it is possible to extend the by default
  # available channels with additional channels (e.g. the EU band).
  # Note: the min_dr and max_dr are currently informative, but will be enforced
  # in one of the next versions of LoRa Server!
13

Doesn’t work either.

Now I try to look into the JoinAccept Message
in SPF I got in
Base64 “IAbbPFqT775K7PYdfCox25plYITRzdVuqlyU/jTTv0py”
in Hex 20 06 db 3c 5a 93 ef be 4a ec f6 1d 7c 2a 31 db 9a 65 60 84 d1 cd d5 6e aa 5c 94 fe 34 d3 bf 4a 72

Means
MHDR 20
JoinAccept 06 db 3c 5a 93 ef be 4a ec f6 1d 7c 2a 31 db 9a 65 60 84 d1 cd d5 6e aa 5c 94 fe 34
MIC d3 bf 4a 72 (same as LoRaServer Frame Logs)

Decrypted JoinAccept means:
00 00 08 03 02 01 7e 69 cf 06 00 01 18 4f 84 e8 eb 7f e2 f6 f5 38 5b 4f 63 57 0e 2e b0 f1 49 f8

Means
AppNonce 00 00 08
NetID 03 02 01
DevAddr 7e 69 cf 06
DLSettings 00
RxDelay 01
CFList 18 4f 84 e8 eb 7f e2 f6 f5 38 5b 4f 63 57 0e 2e
MIC b0 f1 49 f8

But this MIC is not the same with the MIC above. What am I doint wrong?

14

I believe the MIC of the join-accept is encrypted.

15

I got it my source for the AES calculation was corrupted.
Now it ok both the same.

So the JoinAccept message is okay. Any other ideas?
My node should work on Objenious, Orange, SwissCom, KPN, TTN. That’s what the support says.

What could be the problem with my loraserver?

16

Could you try with a different type device? When the device is a blackbox and everything from the network-side looks ok (at least to me), I think it would be better to validate with a different type LoRaWAN device.

17

I will get a second node soon.

Can I see dropped tx packets at the kerlink gateway to see if the joinaccept is dropped?

I used the standard configuration for EU 868mhz for the samtech packet forwarder. Is there maybe an issue?

18

Depending on the packet-forwarder version on your Kerlink gateway, you will see ACKs or nACKs on the .../ack MQTT topic: https://docs.loraserver.io/lora-gateway-bridge/use/data/.

19

I receive acks with no error datafield, therefore I think everything’s okay, right?

20

Yes, that is correct.