Join notification sent after first uplink message

Setup:
Debian GNU/Linux 9 (stretch) 64-bit
Running latest loraserver, lora-app-server, mosquitto server
Running latest dependencies (redist, postgresql 9.6) etc
Using MQTT.fx 1.7.0 (client) to view messages

Hardware:
Laird RM191 dev kit
Laird Sentrius Gateway RG191

FYI: Class C device set in the RM191 module and class C checked on the device profile page

Problem:

I can easily get the device to join (OTAA) but the mqtt join topic does not appear to be published until I first transmit something from my device. Is this by design or a bug? Or am I doing something wrong?

Example: application/[number]/device/[device-eui]/join
only appears in my mosquitto logs after I send something from my device. Then the …/join and …/rx appear at the same time.

One isssue this creates is the application can’t send anything to the device until the device sends data. When I try, loraserver complains about no back history and keeps trying to resend it - until I send data from my device:

Aug 13 10:45:01 debian loraserver[671]: time=“2018-08-13T10:45:01-05:00” level=error msg=“schedule next device-queue item error” dev_eui=c0ee4000010118dc error=“uplink gateway-history is empty”

which makes sense if mqtt didn’t actually receive the join topic yet. Once that is set, I can send from the mqtt client back to the device without issues, as expected from class C.

Notice that it says gateway-history, so I checked further:

Aug 13 12:33:17 debian loraserver[671]: time=“2018-08-13T12:33:17-05:00” level=info msg=“backend/gateway: rx packet received”
Aug 13 12:33:17 debian loraserver[671]: time=“2018-08-13T12:33:17-05:00” level=info msg=“packet(s) collected” dev_eui=c0ee4000010118dc gw_count=1 gw_macs=c0ee40ffff29382f mtype=JoinRequest
Aug 13 12:33:17 debian loraserver[671]: time=“2018-08-13T12:33:17-05:00” level=info msg=“device-queue flushed” dev_eui=c0ee4000010118dc
Aug 13 12:33:17 debian loraserver[671]: time=“2018-08-13T12:33:17-05:00” level=info msg=“device-session saved” dev_addr=2c8f1ef6 dev_eui=c0ee4000010118dc
Aug 13 12:33:17 debian loraserver[671]: time=“2018-08-13T12:33:17-05:00” level=info msg=“device-activation created” dev_eui=c0ee4000010118dc id=46
Aug 13 12:33:17 debian loraserver[671]: time=“2018-08-13T12:33:17-05:00” level=info msg=“backend/gateway: publishing tx packet” qos=0 topic=gateway/c0ee40ffff29382f/tx

This is the join sequence. Notice the last line (topic=gateway/[dev-eui]/tx). This actually was posted right after the …/join and …/rx messages! (Which was right after my device sent data after the join).

So the logs say the gateway topic is published but it does not show up until too late.

To be honest, I have one more issue that I’m not sure about. It may or may not have a bearing to this one so I figure I’ll mention it just in case:

Looking at my mqtt client logs, I only get the first …/rx from the device. Any subsequent data sent by the device will not appear. Actually, the way it stands is I get the …/join and one …/rx at the same time and that’s it. My device claims it sends but nothing happens. Once this happens I can send as many messages to my device by publishing the …/tx messages. That works. Until I know more about this I can only assume I’m doing something wrong or this one is a device problem.

If anything, I wouldn’t mind any pointers in the right directions. I am googled out and getting dismayed.

Thanks.

This is intended. Please see the changelog: https://github.com/brocaar/lora-app-server/blob/master/docs/content/overview/changelog.md#encrypted-key-signaling

Thanks. I missed that.

Hah. And all the time I was really trying to solve that other annoying issue I mentioned: Only one transmit gets through - and that turns out to be due to ADR.

I have to disable ADR on the Laird RM191 for now.

I set up a gateway profile to match my gateway but I must be getting something wrong. I assume “enabled channels” would be (for my gateway) 0, 1, 2, 3, 4, 5, 6, 7, 64 but that is not what my device gets set to after the ADR comes through. My ADR result is 0x010000…0ffff but I want 0x010000…00ff as a channel mask.

I must manually set the channel mask in the module until I can clear up this issue. It would be nice if the logs printed the mask - I could see if it matched what I was expecting.

If you have any ideas it would be appreciated. Hey, even if this post gets split off this thread and reposted with a better topic - I’d be ok with that. You pick it though - seems your topic descriptions are better than mine :stuck_out_tongue:

Separate issue, so please create a separate topic for this :slight_smile: (if it doesn’t already exists)