Message not exchanged between gateway and application after successful OTAA join

End Devices (Nodes)
1

Hi,

I’m attempting to set up a Raspberry Pi based end device with a Adafruit LoRa Bonnet on a private TTS 3.13.1 setup. I want to use it as a type C device but I am experiencing weird issues.
I use a modified version of the LoRaPy library: GitHub - btemperli/LoRaPy: LoRaWAN implementation in python and have successfully been able to send a join request for OTAA. But when I attempt to send data packets they don’t get past the gateway, the DevAddr of the packet matches the assigned one from the join request but it doesn’t show up in the Live Data of the device in the application.
image
image
image
Downlink packets are not sent to the gateway either.
Using the same setup but with ABP I have successfully sent uplink packages to the application but I understand the improvements of OTAA so I’d prefer to get that working. Does anyone have any ideas about where the trouble could be?

2

The todo list at the bottom of the repro probably says it all:

  • Check OTAA for TTN

This recently came up on the forum, it seems very similar but the OP reported good results:

3

I understand that this is untested, and I appreciate the link there might be something useful there.
I am still not entirely sure how packets are exchanged between the gateway and application.
After a device has joined through OTAA and a downlink is queued for that device how does the application know what gateway to use? With class A it should just reply on the same gateway, but what about class C?

My problem seems to be that packets are not exchanged between the application and the gateway after joining. But with the verbose view it seems that messages are to be forwarded, they just don’t show up.
image
image

4

The aren’t. It’s up to the Network Server to decide based on the implementations algorithm and there is no concept of ‘same gateway’ as the whole scheme is predicated on one or more gateways hearing an uplink, so the NS decides how to send, which may not appear to be the optimal one for signal if the ‘best’ gateway is out of duty cycle airtime.

5

That makes sense. Right now I only have a single gateway connected to my TTS. Is there anyway to see where a message is forwarded to?

6

Forwarded to? I don’t see that as a concept in LoRaWAN as all gateways lead to the same place - so in EU1, all gateways on TTN will send to the EU1 cluster - not really forwarded as there is only one place for it to go.

One or more gateways may hear an uplink, regardless of which network they are on. The NS of the registered device will process it, pass it to the AS and then your integration will do with it as you have configured. You can see which gateways heard the uplink in the JSON. The other NS won’t be able to match / decrypt & drop the uplink.

7

What could be causes of downlink messages not being sent out on the gateway then? The same gateway that has just been used to complete the OTAA. And shouldn’t the uplink messages be sent to the application as long as the Devaddr matches the one just generated?

Edit: After prodding around some more it seems that a session is not initiated on the application during the join procedure. The application processes the join request and accepts it but there is no session information on the overview. When comparing the OTAA procedure with another (working) end node the two appear identical.

8

Only if the MIC also checks out, the counters match expectations (should do for OTAA).

9

The Network Server processes the join request and accepts it - you are seeing the results in the application console as it’s the tidiest way of displaying the activity at an application or device level.

What you are describing is typical of a device not hearing the join accept. Can you get to the serial log on it or is it out in the field?

10

Are you sure it is your nodes message at 09:21:53?

Not someone else’s node connected via your gateway?

Hot reboot your node and see if you see the join request and accept, only then you will you see the data getting forwarded to your application.

Also remember to rest the Mac status on your application.

11

I have direct access to the device. When I run the LoRa program I get the following output when the device tries to do its OTAA procedure:

TxDone
listening
RxDone
[25, 0, 0, 0, 0, 0, 166, 179, 89, 0, 3, 5, 24, 79, 132, 232, 86, 132, 184, 94, 132, 136, 102, 132, 88, 110, 132, 0]
0
Got LoRaWAN join accept
is message valid?
True
devaddr:
[0, 89, 179, 166]
nwskey:
[123, 34, 96, 73, 18, 102, 26, 164, 92, 70, 170, 84, 204, 29, 195, 252]
appskey:
[38, 65, 48, 228, 198, 73, 84, 122, 58, 254, 190, 13, 1, 244, 66, 21]

So to me it looks like the end device receives the join accept message and that the session keys are correctly derived.

I have not seen any other traffic on my gateway at all, I am somewhat remote so I am very sure it’s my own message.

Restarting the program yields the same result, my node attempts to join, the application sends a join accept back to the node, the session keys are derived on the end device and it attempts to make an uplink. That uplink is caught in the gateway but it doesn’t show in the application view.
Is there a tool I can use to check if the session keys are correctly derived?

12

Did you reset the MAC state for the end device (node)?

What is the RSSI?

Saying you are remote don’t count, I helped a friend with a gateway the other day. The closest gateway on the TTN map is some +50km away, we saw straight away a node connecting at -90. So there are device in place we don’t know about.

13

Shame it’s not in hex, so can you transcode it and then look on the console to see what was assigned.

14

I believe each integer should be interpreted as a byte, equal to a hex-pair. So the in hex the session keys would be:
Devaddr: 0x0, 0xb9, 0x19, 0xe2
Appskey: 0x36, 0x83, 0xe4, 0x43, 0x52, 0x90, 0x5f, 0xeb, 0xe9, 0xf1, 0xe0, 0x74, 0x70, 0xe5, 0xde, 0x67
Nwskey: 0x75, 0x8b, 0x68, 0x8c, 0x2e, 0xa7, 0xe6, 0xdf, 0x6f, 0x2d, 0x71, 0xc6, 0x52, 0x27, 0xb1, 0x3d

~68

I understand its never 100 percent sure, but the amount of messages I have seen on the gateway from other users so far is 0. Those messages are consistent with what I was doing at the time.

I am not sure if I can use TTN-cli, I don’t think it is installed on the TTS instance I am running through Balena, not ideal I know, it was just the easiest way to get a TTS running.

15

That’s nice. Well done. Not something anyone here can do anything with.

And how does it compare with the console, which would rather be the point?

What makes you think it’s not installed? And you can reset the MAC state from the web console.

But to summarise:

  • You are using a Python library that explicitly says it has a todo item of checking OTAA works - even after being given one that says it was updated to work with TTS.
  • You are running a copy of TTS OS on a Pi - which is OK - excepting that there could be any number of extra dimensions to the setup with your network.
  • And you’re not familiar with it enough to know about the CLI on an OS instance.

And when it is suggested you check that the reported keys against the console, you don’t.

There is a limit to how much help the volunteers can provide.

At the very least, check the keys. But unless there is a compelling reason not to, put your gateway on to TTN and use the alternative Python library to eliminate as many other points of failure as possible.

16

This is on the TTN application - End Devices - General Settings - Network Layer - Reset Session and MAC state

17

Well that’s the problem, the session keys are not shown in the console:
image
So I cannot check against them there.
Furthermore the option to reset the MAC state does not appear in General settings → Network Layer:
image
image

I’ve attempted to get the Dragino library working, it took some pin reassignment and disabling the GPS parts of the program to get it to run without errors. But with that library I have not successfully sent any message, the program informs that I should have done a transmission but nothing is received at the gateway. So I’ve abandoned that effort for now.

I briefly tested the LoRaPy program with TTN and ran into identical issues. At this point I feel I am running out of things to try to get this setup working. I can attest that this library is not working with either OTAA or ABP in its current state. I appreciate the help, you’ve all provided, it has really helped me further understand TTS.

18

Hopefully you understand that using a very out of date TTS OS with an unproven device library isn’t likely to be straightforward and in no way shape or form represents TTN / TTS.

19

Looks like your registration details are incomplete - also suggest you try a later LoRaWAN Rev (1.02?) and also populate the remaining items…RX2, DR, FRQ etc. Drop Class C for now - get up and running as Class A 1st! Walk b4 running :wink: