Join-Request with no Join-Accept

Hello all,

I hope I put this in the right place.

I have Chirpstack up and running on a Raspberrypi and was able to connect my Multitech Conduit-AP gateway. Now I’m trying to connect end devices but they can’t seem to join. I followed this guide: Connecting a device - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server. I get a JoinRequest but there is no response. The guide referenced the Device data tab I assume this is the events tab under device where no data is displayed. The requests can be found under the LoRaWAN frames in the device section and the gateway section. I tried to let the device join using OTAA. I did this by setting the LoRaWAN version to 1.0.3 found on the website of the device producer. Set the device EUI and this matches the EUI used in the Join-Requests. I didn’t touch OTAA keys since if I understand correctly this is only applicable for version 1.0.0 and my devices use 1.0.3. The devices I used are the Dragino LoRaWAN Temperature Transmitter: LTC2-SI and the Dragino LoRaWAN RS485 converter: RS485-BL.

device info:RS485-BL -- LoRaWAN RS485/UART Converter -- WaterProof Battery Powered

I tried restarting the gateway, server and gateway bridge. Tried joining with two different devices. Screenshots provided with the information I have.

I am not sure what steps I can take to troubleshoot the problem and couldn’t find a solution in other topics on the forum. If anyone knows what steps I could take to troubleshoot the problem or link me to documentation that might help.

screenshots
device events:


gateway/LoRaWAN frames:

JoinRequest frame:

Edit:
I found out how to check the chirpstack logs and found this:
Nov 18 13:36:36 raspberrypi chirpstack[1129]: 2022-11-18T13:36:36.808096Z INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_name=“eu868” topic=“eu868/gateway/0080000000021ed9/event/up” qos=0 json=false
Nov 18 13:36:37 raspberrypi chirpstack[1129]: 2022-11-18T13:36:37.012332Z INFO up{deduplication_id=6a82426f-839b-4d99-89c4-32f49a1f06e1}: chirpstack::uplink: Uplink received m_type=“JoinRequest”
Nov 18 13:36:37 raspberrypi chirpstack[1129]: 2022-11-18T13:36:37.027710Z ERROR up{deduplication_id=6a82426f-839b-4d99-89c4-32f49a1f06e1}: chirpstack::uplink::join: Handle join-request error error=Object does not exist (id: a840417351851d4e)

Handle join-request error error=Object does not exist (id: a840417351851d4e) for both devices does anyone know what this might point to?

kind regards,

Max

My Dragino RS485-BL works ok with Dragino LPS8 gateway and ChirpStack v3 and v4.

You may need to doublecheck the frequency in gateway and node.

I solved the problem there was a problem with the app key after some contact with dragino I got the device to join. thank you for your help

1 Like

Hi mverrijzer,

I might have the same problem as you.
Can you be more especific about you contact with dragino please?
Also, how can I see chirpstack logs?

@NULL1
Dragino instructed me on how I could access the appkey data through AT commands. I double checked if the appkey they provided was correct. I used “joirnalctl -u chirpstack -f” to view what was going on.

Could you provide me with some more information about your problem? How did you connect your device using the appkey?

hi mverrijzer,

Thanks for your time.
I connected all my dragino end nodes through OTAA using APP key and Dev EUI. I’m having problems with just one, and it already worked.

You changed APP key that’s it? I already thought that, by changing APP key it should generate a new APP key session for this particular end node. It worked fine?
Thanks

Hi NULL1
I also reinstalled and set up the database dependancy for Chirpstack I think the problem was the app key but can’t be sure for me everything works fine now.

2 Likes

I’m getting the same issue with a new setup of ChirpStack 4. I’m getting the next log

Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.721898Z  INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_config_id="eu868" topic="eu868/gateway/yyyyyyyyyyyyyyy/event/up" qos=0 json=true
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.923542Z  INFO up{deduplication_id=c29bf37b-71e2-4f96-a70e-48c40f538080}: chirpstack::uplink: Uplink received m_type="JoinRequest"
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.931721Z  INFO up{deduplication_id=c29bf37b-71e2-4f96-a70e-48c40f538080}:join_request: chirpstack::storage::device_keys: Device-nonce validated and stored dev_eui=eeeeeeeeeeeeeeee dev_nonce=60965
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.933528Z  INFO up{deduplication_id=c29bf37b-71e2-4f96-a70e-48c40f538080}:join_request: chirpstack::storage::device_keys: Device-keys updated dev_eui=eeeeeeeeeeeeeeee
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.934274Z  INFO up{deduplication_id=c29bf37b-71e2-4f96-a70e-48c40f538080}:join_request: chirpstack::storage::device_session: Device-session saved dev_eui=eeeeeeeeeeeeeeee dev_addr=d43befdb
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.935029Z  INFO up{deduplication_id=c29bf37b-71e2-4f96-a70e-48c40f538080}:join_request: chirpstack::storage::device_queue: Device queue flushed dev_eui=eeeeeeeeeeeeeeee count=0
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.936815Z  INFO up{deduplication_id=c29bf37b-71e2-4f96-a70e-48c40f538080}:join_request: chirpstack::storage::device: Enabled class updated dev_eui=eeeeeeeeeeeeeeee enabled_class=A
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.936913Z  INFO up{deduplication_id=c29bf37b-71e2-4f96-a70e-48c40f538080}:join_request: chirpstack::gateway::backend::mqtt: Sending downlink frame gateway_id=yyyyyyyyyyyyyyy topic=eu868/gateway/yyyyyyyyyyyyyyy/command/down json=true
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.937489Z  INFO up{deduplication_id=c29bf37b-71e2-4f96-a70e-48c40f538080}:join_request: chirpstack::storage::downlink_frame: Downlink-frame saved downlink_id=705920002
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.938303Z  INFO chirpstack::integration::mqtt: Publishing event topic=application/01b544ee-504d-43a3-b8e9-4ac5dcfd1a0e/device/eeeeeeeeeeeeeeee/event/join
Mar 07 16:19:29 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:29.938614Z  INFO chirpstack::integration::postgresql: Inserting event dev_eui=eeeeeeeeeeeeeeee event="join"
Mar 07 16:19:35 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:35.464576Z  INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_config_id="eu868" topic="eu868/gateway/yyyyyyyyyyyyyyy/event/stats" qos=0 json=true
Mar 07 16:19:35 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:35.466280Z  INFO stats{gateway_id=yyyyyyyyyyyyyyy}: chirpstack::storage::gateway: Gateway state and location updated gateway_id=yyyyyyyyyyyyyyy
Mar 07 16:19:35 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:35.466883Z  INFO stats{gateway_id=yyyyyyyyyyyyyyy}: chirpstack::storage::metrics: Metrics saved name=gw:yyyyyyyyyyyyyyy aggregation=HOUR
Mar 07 16:19:35 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:35.467379Z  INFO stats{gateway_id=yyyyyyyyyyyyyyy}: chirpstack::storage::metrics: Metrics saved name=gw:yyyyyyyyyyyyyyy aggregation=DAY
Mar 07 16:19:35 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:35.467891Z  INFO stats{gateway_id=yyyyyyyyyyyyyyy}: chirpstack::storage::metrics: Metrics saved name=gw:yyyyyyyyyyyyyyy aggregation=MONTH
Mar 07 16:19:42 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:42.736182Z  INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_config_id="eu868" topic="eu868/gateway/xxxxxxxxxxxxxxxx/event/stats" qos=0 json=true
Mar 07 16:19:42 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:42.739364Z  INFO stats{gateway_id=xxxxxxxxxxxxxxxx}: chirpstack::storage::gateway: Gateway state updated gateway_id=xxxxxxxxxxxxxxxx
Mar 07 16:19:42 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:42.740334Z  INFO stats{gateway_id=xxxxxxxxxxxxxxxx}: chirpstack::storage::metrics: Metrics saved name=gw:xxxxxxxxxxxxxxxx aggregation=HOUR
Mar 07 16:19:42 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:42.741062Z  INFO stats{gateway_id=xxxxxxxxxxxxxxxx}: chirpstack::storage::metrics: Metrics saved name=gw:xxxxxxxxxxxxxxxx aggregation=DAY
Mar 07 16:19:42 cicytex.vpnes.es chirpstack[8435]: 2023-03-07T16:19:42.741361Z  INFO stats{gateway_id=xxxxxxxxxxxxxxxx}: chirpstack::storage::metrics: Metrics saved name=gw:xxxxxxxxxxxxxxxx aggregation=MONTH

No join-accept for any join-request. Ckecked AppEUI, … Any gateway and any node. Any suggestion?

In your post you mention you checked the AppEUI you need to fill in the correct AppKey to complete the handshake.

I don’t know what nodes you are using but with Dragino you can check the app key through a Serial terminal with an AP command. I have had instances where the one on the box was different to the one on the device.

Edit: the devices I’ve worked with come with a DevEUI, AppEUI and AppKey

It looks like the join-request was correct and that ChirpStack is sending the downlink to your gateway. What I miss in the logs is a .../gateway.../event/ack message indicating that the gateway has acknowledged the downlink transmission. Either the downlink does not arrive at the gateway or the packet-forwarder is not sending back an acknowledgement.

There is also this case…
If you set your Gateway (service profile) to “PRIVATE” but the device is set “PUBLIC”, you will get the Join requests in ChirpStack and the gateway will actually send the Acknowledge the Join-Request if the Keys match but your end device will still ignore it.

The reason is that within the protocol layer the “private” flagged data is filltered out. This issue did cost me several weeks of time until it finally found the reason that it was Gateway “private” vs Node “public”.

All I saw were incoming Join Requests that were answered by the Gateway and still the device could not join. I thought I ran into some kind of timing issue as the gateway and node distance was not very far and when I used TTN it did directly work (because that gateway used for TTN was actually configured to be “public”).