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.

device events:

gateway/LoRaWAN frames:

JoinRequest frame:

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,


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?

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?

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.


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

Mar 07 16:19:29 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 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 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 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 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 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 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 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 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 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 chirpstack[8435]: 2023-03-07T16:19:29.938614Z  INFO chirpstack::integration::postgresql: Inserting event dev_eui=eeeeeeeeeeeeeeee event="join"
Mar 07 16:19:35 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 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 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 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 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 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 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 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 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 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”).

1 Like

hello in my case, I am using a heltec device in a group of atmospheric sensors, a dragino LG308 as a gategay and I have this same problem, I already reviewed many possible solutions but the problem still persists that I never receive the join accept, I only receive the join request

Hi, I have the same problem. I was using V3 and everything was working fine. Now I created a new V4 machine to test it, but I’m struggling. I checked that the app key parameter is correct because if I change it, I get an error in the logs. In the LoRaWAN frames, I only see Join requests. In the logs, instead of the gateway, I see the Join requests and then some UnconfirmedDataUp messages. Can you help me? Additionally, I also found out that the HTTP integrations have changed, and the current application we are using doesn’t support the message format. Does it make sense for me to continue using V3? Thank you very much for your help.

Are you sure the device isn’t accepting a Join response from your old server (i.e. race)?

Yes , I also got some new sensors straight out of the box.

I’m suffering from this issue too: Join requests are never accepted

mmmm for the moment we should go back with the v3

We have had this issue a few times during testing on chirpstack v3. This typically involves adding, removing, activating, re-activating devices, changing OTAA keys etc. etc.

  • Normally, deleting the device and adding the device again solves the issue
  • On one occasion, we had to restart the chirpstack-application-server service as no devices was accepted at all. Th logs did not indicate that anything was wrong, and restarting the chirpstack-network-server did not help. We did not keep any logs or anything, so I have no “hard evidence”, but something went wrong in the application server for sure…

The strange thing is that the OTAA and activation sees to be working. The session keys and device address are correctly added/updated, but no join accept is sent.

Tip 1: If the OTAA key is wrong, the Device Data (tab on the device pages) will show error messages: “join-server returned error: response error, code: MICFailed, description: invalid mic”

Tip 2:: If the OTAA key is initially wrong, Device Data will report error… BUT if the OTAA key is changed (to correct key) in Chirpstack, the errors stops, activation is done (session keys are updated), but Chirpstack will not send a join accept until the device is reset!

To reproduce this error:

  1. Set up and connect a (OTAA) device. Make sure everything is working correctly.
  2. Change the OTAA key in Chirpstack to a wrong key
  3. Verify that Device Data reports “… invalid mic”.
  4. Correct the OTAA key in Chirpstack
  5. Verify that the device stops reporting errors in Device Data, and that Lorawan Frames only reports Join Requests (and no Join Accepts)

Same situation here; it already worked with v3.0; eui & appkey double checked. join requests are not successful with message: Handle join-request error error=Object does not exist (id: 0018b20000023060)

Device is enabled with Otaa capability on

anybody here who can give me a hint how to diagnose further?

2023-11-11T22:53:29.993685Z  INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_config_id="eu868" topic="eu868/gateway/3530362036004900/event/up" qos=0 json=false
2023-11-11T22:53:29.994042Z TRACE chirpstack::uplink: Adding uplink event to deduplication set key="up:collect:08a084919e03120a1a0808c8d007100c2801:003246524144b218006030020000b21800e6d2a25b3339"
2023-11-11T22:53:29.995565Z TRACE chirpstack::uplink: Requesting deduplication lock lock_key="up:collect:08a084919e03120a1a0808c8d007100c2801:003246524144b218006030020000b21800e6d2a25b3339:lock"
2023-11-11T22:53:29.996477Z TRACE chirpstack::uplink: Waiting for more uplink events to receive key="up:collect:08a084919e03120a1a0808c8d007100c2801:003246524144b218006030020000b21800e6d2a25b3339"
2023-11-11T22:53:30.025665Z TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
2023-11-11T22:53:30.025693Z TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
2023-11-11T22:53:30.028908Z TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
2023-11-11T22:53:30.028930Z TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
2023-11-11T22:53:30.033997Z TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
2023-11-11T22:53:30.034016Z TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
2023-11-11T22:53:30.037514Z TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
2023-11-11T22:53:30.037530Z TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
2023-11-11T22:53:30.197837Z TRACE chirpstack::uplink: Collecting received uplink events key="up:collect:08a084919e03120a1a0808c8d007100c2801:003246524144b218006030020000b21800e6d2a25b3339"
2023-11-11T22:53:30.199282Z  INFO up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}: chirpstack::uplink: Uplink received m_type="JoinRequest"
2023-11-11T22:53:30.199315Z DEBUG up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}: chirpstack::uplink: Updating gateway meta-data for uplink frame-set
2023-11-11T22:53:30.202645Z DEBUG up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}: chirpstack::uplink: Logging uplink frame to Redis Stream
2023-11-11T22:53:30.204077Z TRACE up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}:join_request: chirpstack::uplink::join: Getting JoinRequestPayload
2023-11-11T22:53:30.204118Z TRACE up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}:join_request: chirpstack::uplink::join: Getting device
2023-11-11T22:53:30.206335Z ERROR up{deduplication_id=9f7c744c-9bc3-40e6-9147-30590b12977b}: chirpstack::uplink::join: Handle join-request error error=Object does not exist (id: 0018b20000023060)
2023-11-11T22:53:31.030277Z TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
2023-11-11T22:53:31.030297Z TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items