dcala23:

have the same error when b

Hello, no i never fix the probleme

Sometimes things get a bit out of sync - but this usually recovers automagically.

i think i’ve been doing exactly what you’re after - via NodeRed as integrated in the Gateway OS.
When the node sends the uplink, i put together the downlink and push it into the downlink queue.
When i was developing this, the downlink queue was “constantly empty” …
Checking today, i currently see a packet waiting - not what i intended.
Maybe something changed recently … i’ll have to investigate …

Could you help me?

Thanks in advance

First of all a big thank you to everyone who has contributed to the ChirpStack community forum over the years. Your questions, answers and discussions have helped many users getting started with ChirpStack and troubleshooting issues.

From a maintainers point of view, keeping the old forum organized has been challenging as many questions didn’t fit neatly into a single category. Recently we tested a new support platform based on Apache Answer, and the feedback has been very positive.

Apache Answer (https://answer.apache.org/) is built entirely around tags instead of categories, which makes organizing and finding information much easier. Unfortunately, migrating all existing data from Discourse isn’t practical so this will be a fresh start.

Here is what’s changing:

• Documentation links now point to https://support.chirpstack.io.
• Creating new topics on this forum has been disabled.
• You can still reply to existing topics until December, after which the forum will become read-only for reference.
• Please note that you need to create a new account on the new platform.

We are looking forward to seeing you at https://support.chirpstack.io!

I need support on a critical issue blocking FUOTA implementation on a Raspberry Pi Pico (LoRaWAN FUOTA bootloader).

Current Status

• FUOTA bootloader is running on Pico.
• Network join, multicast setup, clock sync, and command–response with ChirpStack all work correctly.

Issue

The process stops at the Fragmentation Session Setup step.

• ChirpStack sends FRAG_SESSION_SETUP_REQ (Port 201).
• The device rejects it as invalid — no FRAG_SESSION_SETUP_ANS is sent.
• ChirpStack times out after 3–5 seconds.
• As a result, FUOTA cannot proceed to the firmware transfer stage.

Technical Details

• The code currently checks for a minimum 9-byte payload.
• However, per LoRaWAN TS006, a 7-byte payload is valid (the descriptor at bytes 7–8 is optional).
• This mismatch causes the device to reject valid ChirpStack commands.

What I’ve Tried

• Verified connectivity
• Multicast and clock sync working
• Checked ChirpStack logs → shows timeout
• Device serial output → shows payload rejection
• Compared implementation vs. LoRaWAN spec → found 7-byte vs. 9-byte mismatch

Impact

This issue is a complete blocker — FUOTA progress is halted at the Fragmentation Session Setup stage.

Request for Support

• Could someone please review or confirm whether the 9-byte minimum check was added for a specific reason?
• Any guidance or example implementation references to handle this correctly would be greatly appreciated.

Thanks in advance for your help!
Vishwa

The gateway connects correctly — it appears as online in the ChirpStack dashboard. However, my three LoRaWAN devices are not joining the network. They are registered in ChirpStack with their respective DevEUI, and both AppKey and JoinEUI were automatically generated when I created the application.

On the device side, I’m using OTAA join mode. The devices continuously try to join, but they never manage to connect (no join-accept is received).

I’d really appreciate any help or advice on what might be going wrong — maybe something related to frequency configuratio, region settings, or AppKey/JoinEUI mismatches?

For information, I was able to run the Gateway Bridge on the server and locally on the gateways without any additional issues, but it didn’t resolve the Join Request–Join Accept loop. I believe the number of transmitted packets from the configured gateways is higher than before, yet the issue still persists.

I have successfully configured my LoRaWAN gateway to communicate with a remote PC via the HiveMQ MQTT broker. The gateway is now forwarding uplink data to HiveMQ, and I can receive those packets on my remote PC using a Python MQTT subscriber script.

Now, I would like to move a step further:
I want the gateway to send the LoRaWAN packets directly to a public IP address hosted on my PC (instead of using HiveMQ).

Could you please guide me on:

1. How to configure the LoRaWAN gateway or ChirpStack stack to forward data directly to a public IP endpoint?
2. What port forwarding or firewall configurations would be needed to make this work?
3. Any recommended best practices for securely exposing this setup (e.g., using TLS or a VPN)?

Thank you again for your continued support and valuable insights.

Removal

Concentratord backend

This release removes the ChirpStack Concentratord backend. For a long time, the ChirpStack MQTT Forwarder has been a better alternative to the ChirpStack Gateway Bridge for on-gateway installation. For more information, please see ChirpStack MQTT Forwarder.

Improvements

• Make UDP connection timeout configurable. (#238)
• Add TLS support by Reverse-Proxy for Basics Station. (#241)
• Make Semtech UDP cache expiration and cleanup interval configurable. (#244)

Bugfixes

• Add missing multiplier to convert to nanoseconds. (#234)
• Fix typo in Prometheus metric name. (#247)

Improvements

• Align asap_count in JIT queue with Semtech SX1302 implementation.
• Update internal dependencies and workspace configuration.

LNS ChirpstackVersion: v4.14.0
Installation was performed from the repository using the standard methods described in the manual.
The server is configured and running, running without errors… BUT

The multitenants architecture was chosen for the network. Accordingly, there is one infrastructure tenant, the owner of all gateways, and there are several independent services under separate tenants.
It was not possible to make the gateways available to other tenants as well.
There are no controls for GW Sharing anywhere in the web interface.
The corresponding network policies are not enabled via the API, moreover, there is no network_policy table in the database.
Can you tell me what the problem is, where to look and what to read?
Thank you.

On my gateway I have global_conf.json file. I have configuration - server: 127.0.0.1, udp server_port/up and server_port_down - 1700. Therefore I changed some configuration in my chirpstack-gateway-bridge.toml file (requires root access) with the following:

original setting:
udp_bind = “0.0.0.0:1700”

I changed it to:
udp_port = “127.0.0.1:1700” since my LNS and AP are on the local host (127.0.0.1). Perhaps the reason could be that with 0.0.0.0, it looks for random IP and sometimes looks for IPV6 according to the logs. Therefore I presume that giving specific IP eliminates the confusion.

You mentioned that you are running Chirpstack on a separate server. You may try putting 127.0.0.1 or specific server IP (make sure it is static IP) and see if it works. I am not too familiar with the docker part through, 1700:1700 you know the best. Perhaps your ports might be different, please take care of it.

Please try it and see if it works. You may reverse it if it does not work for you. Good Luck.

Edit:

I was able to further narrow down the problem.
If there is already something in the queue, then any new data sent after the uplink is also sent directly to the device as a downlink.
If there is nothing in the queue at the time of the uplink, it seems that the RX1 window for sending is not opened at all; instead, the whole thing is postponed to the next cycle.
Is it possible to schedule the check to determine whether there is something in the queue at the time of the RX1 window and not at the time of the uplink?
We have an application that sends a downlink to cs exactly when uplink is received.

Maybe you can also check in the time between uplink and rx1 whether a downlink comes in, because as I said, if there is already something in the queue, it works too.

we have migrated our sensors from V3 to V4. After a couple of days some sensors just stopped working as they should, they are just trying to rejoin but nothing happens.
I tried to Flush OTAA but that did nothing. I tried multiple times.

Weirdly it is not happening for all sensors, only for some, unfortunately majority. For example, we have 2 same type of sensors, same gateway, same profile, same application, one is working fine, the other is in join loop. I can’t seem to see or find any errors or I might be looking in wrong logs. In Events I just see “join” and in “LoRaWAN frames” just “JoinRequest”.

Since sensors are in remote locations we can’t easily get to them to try to manually reset them.

Where should I dig deeper or what else to check?

I am using Kerlink’s GW (KerOS6) with an edge computing configuration, integrating ChirpStack and Postgres together.
Due to the limited disk space on the GW, I want to impose a limit on the payload data stored in the database.
What is the recommended implementation approach?
Does ChirpStack provide configuration options for this?
If direct database data deletion becomes necessary, which specific data should be removed?

Thanks.

I would like to contribute to Chirpstack, but I’m having trouble building Chirpstack. After successfully build and running the binary, I don’t get the web UI.

I’ve successfully installed Docker and Nix-OS.
I can access the Nix-shell, then I can successfully run

make devshell

make build-ui

Then I build Chirpstack:

cd chirpstack
make debug-amd64 DATABASE=sqlite
cd ..

The build goes well.

And finally, I’m going to run chirpdstack.

cd target/x86_64-unknown-linux-musl/debug
mkdir -p configs
./chirpstack -c configs

And when I try to access chirpstack via my browser or via curl, I get:

2025-10-02T08:56:58.815208Z INFO gRPC{uri=/}: chirpstack::api: Finished processing request status="404" latency=821.139µs

Inspecting the code, this seems to correspond to the fact that no files are found in Asset.

if let Some(asset) = Asset::get(path) {
    let mime = mime_guess::from_path(path).first_or_octet_stream(); 
    let mut headers = HeaderMap::new(); 
    headers.insert( 
        header::CONTENT_TYPE, 
        HeaderValue::from_str(mime.as_ref()).unwrap(), 
    ); 

    (StatusCode::OK, headers, asset.data.into()) 
} else { 
    (StatusCode::NOT_FOUND, HeaderMap::new(), vec![]) 
}

and adding this code block before this seems to be confirmed

println!("Serving static file: {}", path); 

let files: Vec<_> = Asset::iter().collect(); 
println!("Number of files embedded: {}", files.len()); 
for file in files {
    println!("Embedded file: {}", file.as_ref());
}

with this result

Serving static file: index.html
Number of files embedded: 0

The files should be present in RustEmbed Assets

#[derive(Rust Embed)]
#[folder = "../ui/build"]
struct Asset;

Does not appear to be present

Am I doing something wrong?

Could you help me?

Thanks in advance

We tried checking all the available logs but didn’t find anything useful—there’s essentially the same information as in the web interface. I’d be glad to share logs if anyone has ideas on how we could debug this further and identify the root cause.

Since we have quite a large number of devices, my current suspicion is that there aren’t enough resources to process every packet in time. To mitigate this, I’ve added another instance of the Application Server with the Network Server (so now 2 replicas of ChirpStack). I’m also considering offloading some of the traffic from the single Gateway Bridge instance that we have on our server.

As far as I understand, I can’t simply add another Gateway Bridge instance because it would subscribe to the same MQTT topics. So my question is: would it be possible to keep the current Gateway Bridge on the server for part of the gateways, and configure other gateways to use their own Gateway Bridge?

We’d eventually like to switch all gateways to local Gateway Bridge, but since we currently have around 95 gateways, that would take quite a bit of time and effort.

Iam trying to understand the rest api.

I use node-red and i can connect to the rest api and request
http://xxxx.xxxxxx.yy:8090/api/gateways?orderBy=NAME
and i get a response but the answer is only

{"totalCount":8, "result":[]}

which matches the number of gateways but i was expecting a list of gateways, not just the total sum.

When i do the same with tenants i also only get i sum of tenants and no list…

What am i missing here?

Even though the default docker config has mqtt integration enabled, you still need to configure the command_topic and event_topic (and possible a few more)

https://www.chirpstack.io/docs/chirpstack/configuration.html

Once you do that, then mqtt explorer shows the messages . Chirpstack integration tab on the Web browser still shows same thing (option to get certificate)

At the moment, I just see a “Get certificate” button, I cannot bypass the TLS/cert requirement?

I have this github compose checked out (made 4 changes in docker-compose.yaml to use us915_1 instead of eu868)

My lorawan setup is working (chirpstack able to see my lorawan devices, able to receive uplinks and send down links too) , just missing this MQTT integration to communicate with my Node-Red instance (lora_pkt_forwarder is forwarding to 1700 to the chirpstack-gateway-bridge.

I tried adding tls_enabled in these places below (I tried one at a time, as well as both), didn’t seem to make a difference.

 [integration]
   enabled=["mqtt"]
+  tls_enabled=false

   [integration.mqtt]
     server="tcp://$MQTT_BROKER_HOST:1883/"
     json=true
+    tls_enabled=false

I’m trying to connect an ESP32 + SX1262 node to my ChirpStack 1.1 server in IN865 region using RadioLib (LoRaWAN 1.1 OTAA), but OTAA fails with error -1116 (RADIOLIB_ERR_NO_JOIN_ACCEPT).

Setup

• ESP32 DevKit, SX1262
• RadioLib version: 7.2.1
• LoRaWAN 1.1, Class A
• ChirpStack 1.1, IN865
• Node keys:
  • DevEUI: 0x899F6EEE7E9D77F2
  • AppKey: 3E 41 74 2C D8 65 70 BC 65 95 1A 80 5A AB 19 7E
  • NwkKey: 28 EC CB 64 AB D0 4D 80 7F 21 86 F9 3B FF B7 B7
  • JoinEUI: 0 (not used)
• Node sketch: minimal RadioLib OTAA example

Serial Output
[5] Initialising node (OTAA 1.1.0)…
→ Node init OK
[6] Sending JoinRequest…
→ OTAA state: -1116
→ Join failed

What I tried

• Verified raw LoRa transmission works.
• Confirmed gateway receives uplink.
• Radio configured for IN865.
• Keys match the device registered in ChirpStack (DevEUI, AppKey, NwkKey).

How do I correctly configure RadioLib/ESP32 for OTAA 1.1 to join a ChirpStack server without using JoinEUI? Am I missing something in the sketch or ChirpStack setup?

Thanks in advance!

#define RADIOLIB_DEBUG
#include "config.h"

bool joined = false;

void setup() {
  Serial.begin(115200);
  SPI.begin(6, 2, 7, 10);  // (SCK, MISO, MOSI, SS)
  while (!Serial);
  delay(2000);

  Serial.println(F("\n=== LoRaWAN Debug Start ==="));

  // 1. Init radio
  Serial.println(F("[1] Initialising radio..."));
  int16_t state = radio.begin(
  865.0625,   // IN865 join channel 1
  125.0,             // bandwidth in kHz
  7,                 // spreading factor (SF7 is standard for join)
  7,                 // coding rate (4/7 is common)
  RADIOLIB_SX126X_SYNC_WORD_PRIVATE,
  10, 8, 0, false
);
  
  if (state == RADIOLIB_ERR_NONE) {
    Serial.println(F("   -> Radio init OK"));
  } else {
    Serial.print(F("   -> Radio init FAILED: ")); 
    Serial.println(state);
    while (true);
  }

  // Test raw transmit
  Serial.println(F("[2] Test raw transmit..."));
  state = radio.transmit("Hello");
  if (state == RADIOLIB_ERR_NONE) {                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               
    Serial.println(F("   -> Transmission successful!"));
  } else {
    Serial.print(F("   -> Transmit failed, code: ")); Serial.println(state);
  }

  // 2. Print region/subBand
  Serial.print(F("[3] Region: ")); Serial.println("IN865");
  Serial.print(F("    SubBand: ")); Serial.println(subBand);

  // 3. Print credentials
  Serial.println(F("[4] Device credentials:"));
  Serial.print(F("    DevEUI: 0x")); Serial.println((uint64_t)devEUI, HEX);
  Serial.print(F("    JoinEUI: 0x")); Serial.println((uint64_t)joinEUI, HEX);

  Serial.print(F("    AppKey: "));
  for (uint8_t i = 0; i < 16; i++) { Serial.print(appKey[i], HEX); Serial.print(" "); }
  Serial.println();

  Serial.print(F("    NwkKey: "));
  for (uint8_t i = 0; i < 16; i++) { Serial.print(nwkKey[i], HEX); Serial.print(" "); }
  Serial.println();
  

  // 4. Init node (OTAA 1.1)
  Serial.println(F("[5] Initialising node (OTAA 1.1.0)..."));
  state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);
  if (state == RADIOLIB_ERR_NONE) {
    Serial.println(F("   -> Node init OK"));
  } else {
    Serial.print(F("   -> Node init FAILED: ")); Serial.println(state);
    while (true);
  }
  delay(1000);
  // 5. Try to join
  Serial.println(F("[6] Sending JoinRequest..."));
  state = node.activateOTAA();
  Serial.print(F("   -> OTAA state: ")); Serial.println(state);
  if (state == RADIOLIB_LORAWAN_NEW_SESSION) {
    Serial.println(F("   -> Join success!"));
    joined = true;
  } else {
    Serial.println(F("   -> Join failed (RADIOLIB_ERR_NO_JOIN_ACCEPT = -1116)"));
    joined = false;
  }
  checkLoRaMode();
  Serial.println(F("=== Setup Complete ===\n"));
  
}
void checkLoRaMode() {
    // Check if the node object exists
    if (&node != nullptr) {
        Serial.println(F("[Check] LoRaWANNode object exists. Node is configured for LoRaWAN."));

        if (joined) {
            Serial.println(F("[Check] Node has joined the network. LoRaWAN session active."));
        } else {
            Serial.println(F("[Check] Node is in LoRaWAN mode but not joined yet."));
        }

        // Optional: send a dummy payload to verify LoRaWAN behavior
        uint8_t testPayload[1] = {0x00};
        int16_t state = node.sendReceive(testPayload, sizeof(testPayload));
        if (state >= RADIOLIB_ERR_NONE) {
            Serial.println(F("[Check] LoRaWAN sendReceive() successful. Node is in LoRaWAN mode."));
        } else {
            Serial.println(F("[Check] LoRaWAN sendReceive() returned error. Node may not be joined yet."));
        }

    } else {
        Serial.println(F("[Check] No LoRaWANNode object found. Node may be in raw LoRa mode."));
    }
}


void loop() {
  if (joined) {
    Serial.println(F("[Loop] Sending uplink..."));

    uint8_t value1 = radio.random(100);
    uint16_t value2 = radio.random(2000);

    uint8_t uplinkPayload[3];
    uplinkPayload[0] = value1;
    uplinkPayload[1] = highByte(value2);
    uplinkPayload[2] = lowByte(value2);

    int16_t state = node.sendReceive(uplinkPayload, sizeof(uplinkPayload));
    if (state < RADIOLIB_ERR_NONE) {
      Serial.print(F("   -> Error in sendReceive: "));
      Serial.println(state);
    } else if (state > 0) {
      Serial.println(F("   -> Downlink received!"));
    } else {
      Serial.println(F("   -> No downlink received"));
    }

    Serial.print(F("Next uplink in "));
    Serial.print(uplinkIntervalSeconds);
    Serial.println(F(" seconds\n"));
  } else {
    Serial.println(F("[Loop] Node not joined, skipping uplink."));
  }

  delay(uplinkIntervalSeconds * 1000UL);
}

I have a Dragino LPS8v2 and I’m hosting the Lora Network Server and the Application Server in it. When I launch the LNS in the Dragino web interface it asks me what sub band Im planning to use, then in the chirpstack I can only create device profiles with that sub band.

Now when im only using that gateway to listen to lora devices its not an issue, because it can only listen to 8 channels, so I match them, its all good, but now I have a second gateway, and Im forwarding the packets to the LNS hosted on the first one.

So here is wher it gets tricky for me, lets say I set GW_1 to listen to sub band 2, channels 8 to 15, and GW_2 to listen to sub band 3, channels 16 to 23, and I configure half my end devices to transmit on sub band 2 and the other half on sub band 3, because you know I have too many end devices for just one sub band

My question is those devices talking to GW_2, even if GW_2 is able to hear then and forward the packets to GW_1, will their data be able to enter the LNS? or only devices transmitting on the sub band my LNS is set to will be able to get their data into the LNS?

Is this limitation comming from the fact that Im running the LNS in the gateway itself? or are LNS hosted in the cloud limited too in this way?

Please help

2025-09-24T08:03:18.853074Z  INFO up{deduplication_id=54ae45f9-86b2-4f05-aac4-8aa005d0fb05}: chirpstack::uplink: Uplink received m_type=JoinRequest
2025-09-24T08:03:18.856953Z  INFO up{deduplication_id=54ae45f9-86b2-4f05-aac4-8aa005d0fb05}:join_request{dev_eui="8c83"}: chirpstack::storage::device_keys: Device-nonce validated, join-nonce incremented and stored dev_eui=8c83 dev_nonce=177
2025-09-24T08:03:18.857404Z  INFO up{deduplication_id=54ae45f9-86b2-4f05-aac4-8aa005d0fb05}:join_request{dev_eui="8c83"}: chirpstack::storage::device_queue: Device queue flushed dev_eui=8c83 count=0
2025-09-24T08:03:18.858655Z  INFO up{deduplication_id=54ae45f9-86b2-4f05-aac4-8aa005d0fb05}:join_request{dev_eui="8c83"}: chirpstack::storage::device: Device partially updated dev_eui=8c83
2025-09-24T08:03:18.858859Z  INFO up{deduplication_id=54ae45f9-86b2-4f05-aac4-8aa005d0fb05}:join_request{dev_eui="8c83"}:join_accept{downlink_id=3913764129}: chirpstack::storage::downlink_frame: Downlink-frame saved downlink_id=3913764129
2025-09-24T08:03:18.858900Z  INFO up{deduplication_id=54ae45f9-86b2-4f05-aac4-8aa005d0fb05}:join_request{dev_eui="8c83"}:join_accept{downlink_id=3913764129}: chirpstack::gateway::backend::mqtt: Sending downlink frame region_id=eu868 gateway_id=7076 topic=eu868/gateway/7076/command/down json=false
2025-09-24T08:03:18.866649Z  INFO chirpstack::integration::http: Posting event event=join url=http://10.15.1.5:5002/api/v1/chirpstackpackets/up
2025-09-24T08:03:18.866901Z  INFO chirpstack::integration::mqtt: Publishing event topic=application/675f70bd-f90b-40c3-830a-ba5a25d6b862/device/8c83/event/join

Looks like Join Accept was generated and sent to the Gateway Bridge

Logs on Gateway Bridge:

time="2025-09-24T08:03:18.650860425Z" level=info msg="integration/mqtt: publishing event" event=up qos=0 topic=eu868/gateway/7076/event/up uplink_id=38606
time="2025-09-24T08:03:18.860210112Z" level=info msg="integration/mqtt: downlink frame received" downlink_id=3913764129 gateway_id=7076

Join Accept was received by Gateway Bridge, but as far as I understand there’s a message like this missing, that would indicate that message was sent to gateway:

level=info msg="integration/mqtt: publishing event" event=ack qos=0 topic=eu868/gateway/7076/event/ack

But does that really indicate, that it was sent to the gateway? Maybe it indicates, that it was confirmed by the gateway?

Logs on the gateway:

2025-09-24T08:03:18.602636+00:00 klk-wiis-xxx lorafwd[1079]: <6> Received uplink message: 
2025-09-24T08:03:18.602751+00:00 klk-wiis-xxx lorafwd[1079]: <6> | lora uplink (5E4038A4), payload 23 B, channel 868.5 MHz, crc ok, bw 125 kHz, sf 12, cr 4/5
2025-09-24T08:03:18.602826+00:00 klk-wiis-xxx lorafwd[1079]: <6> | Join Request, JoinEUI 8C83xxx, DevEUI 8C83xxx, DevNonce 177
2025-09-24T08:03:18.602877+00:00 klk-wiis-xxx lorafwd[1079]: <6> |  - radio (00000107)
2025-09-24T08:03:18.602985+00:00 klk-wiis-xxx lorafwd[1079]: <6> |   - demodulator counter 3363353213, TAI time 2025-09-24T08:03:55.567085Z, rssi -94.7 dB, snr 5.25< 7.25 <12.25 dB
2025-09-24T08:03:18.603314+00:00 klk-wiis-xxx lorafwd[1079]: <6> Uplink message (CE96) sent
2025-09-24T08:03:18.609337+00:00 klk-wiis-xxx lorad[1034]: <6> Sent 1 uplink message
2025-09-24T08:03:18.661726+00:00 klk-wiis-xxx lorafwd[1079]: <6> Uplink message (CE96) acknowledged in 58.3764 ms
2025-09-24T08:03:55.267300+00:00 klk-wiis-xxx lorafwd[1079]: <6> Heartbeat (0180) sent

As seen by the logs there’s also Join Accept missing. It should be like this:

2025-09-24T12:02:37.460152+00:00 klk-wiis-xxx lorafwd[1080]: <6> Received uplink message: 
2025-09-24T12:02:37.460263+00:00 klk-wiis-xxx lorafwd[1080]: <6> | lora uplink (7110004D), payload 23 B, channel 868.5 MHz, crc ok, bw 125 kHz, sf 12, cr 4/5
2025-09-24T12:02:37.460338+00:00 klk-wiis-xxx lorafwd[1080]: <6> | Join Request, JoinEUI 8C83xxx, DevEUI 8C83xxx, DevNonce 50
2025-09-24T12:02:37.460388+00:00 klk-wiis-xxx lorafwd[1080]: <6> |  - radio (00000107)
2025-09-24T12:02:37.460494+00:00 klk-wiis-xxx lorafwd[1080]: <6> |   - demodulator counter 1234431149, TAI time 2025-09-24T12:03:14.421844Z, rssi -102.7 dB, snr 4< 6.75 <9.25 dB
2025-09-24T12:02:37.460871+00:00 klk-wiis-xxx lorafwd[1080]: <6> Uplink message (6F52) sent
2025-09-24T12:02:37.463413+00:00 klk-wiis-xxx lorad[1033]: <6> Sent 1 uplink message
2025-09-24T12:02:37.508254+00:00 klk-wiis-xxx lorafwd[1080]: <6> Uplink message (6F52) acknowledged in 47.3544 ms
2025-09-24T12:02:37.716580+00:00 klk-wiis-xxx lorafwd[1080]: <6> Downlink message (B383) received
2025-09-24T12:02:37.716990+00:00 klk-wiis-xxx lorafwd[1080]: <6> Received downlink message: 
2025-09-24T12:02:37.717326+00:00 klk-wiis-xxx lorafwd[1080]: <6> | lora downlink (0000B383), payload 33 B, required 1, preamble 8 B, header enabled, crc enabled, polarity inverted
2025-09-24T12:02:37.717616+00:00 klk-wiis-xxx lorafwd[1080]: <6> | Join Accept
2025-09-24T12:02:37.717945+00:00 klk-wiis-xxx lorafwd[1080]: <6> |  - radio (00000000), channel 868.5 MHz, bw 125 kHz, sf 12, cr 4/5, power 16 dB
2025-09-24T12:02:37.718285+00:00 klk-wiis-xxx lorafwd[1080]: <6> |   - transmission (00000000), priority 1, on counter 1239431149
2025-09-24T12:02:37.719525+00:00 klk-wiis-xxx lorad[1033]: <6> Received downlink message
2025-09-24T12:02:42.398606+00:00 klk-wiis-xxx lorad[1033]: <6> Sent downlink message at 15 dB
2025-09-24T12:02:42.403152+00:00 klk-wiis-xxx lorafwd[1080]: <6> Received uplink message: transmission event (0000B383 / 00000000), status "Transmitted", power 15 dB
2025-09-24T12:02:42.403619+00:00 klk-wiis-xxx lorafwd[1080]: <6> Downlink message (B383) acknowledged
2025-09-24T12:02:48.862475+00:00 klk-wiis-xxx lorad[1033]: <6> Sent 1 uplink message

We are puzzled where Join Accept packets are being lost. There is no logs that would pin point origin of the issue (we might be looking at the wrong places).

I think it is important to note, that we are using Dockerized version of Chirpstack. Gateway Bridge is being run on the server, not separately on the gateways. Gateway - Wirnet iStation.

Any tips in solving this would be greatly appreciated

i have a WLRGFM-100 - EU868 Gatway it frameware bast MQTT server, i need to chage the frameware to support the Packet Forwarder any one can help me?

Thanks in advance

We tried looking up all the possible logs, no luck - there’s pretty much the same information in the logs as in the web. But I would be glad to provide logs if anyone has any ideas how we could debug this and find the issue…

Liam_Philipp:

post has nothing to do with the MQTT integration. Sandeep was trying to secure his Chirpstack server so he can expose it to the internet and reach it over WAN. You are just trying to forward MQTT events to another broker.

Sorry @sandeep_sivadas and @Liam_Philipp for interrupting

Thankyou @Liam_Philipp

Parvathy_Nair:

wm1302 lorawan gateway module

Ya that’s the Pi hat but what software reads it? Is the UDP packet forwarder capable of that? I thought you needed an additional software for the concentrator?

Parvathy_Nair:

I would like to try this

This post has nothing to do with the MQTT integration. Sandeep was trying to secure his Chirpstack server so he can expose it to the internet and reach it over WAN. You are just trying to forward MQTT events to another broker.

Respectfully, I suggest you research more into the documentation and previous forum posts. All the information you need is already there, and these questions show a gap in your understanding of these systems.

This only gives an certificate if you have already followed the TLS guide for securing MQTT. Read this: Stop using MQTT integration by default on each application

But for your use case I don’t even think you need TLS if your Pi and PC are both on a local network.

You can always subscribe to your MQTT broker and retrieve the packets, the only reason to do the “integration button” (which is not an integration just a TLS option) above is it gives you one way to secure access to your MQTT broker, which by default has no restriction on who can subscribe to what

Also an MQTT broker does not subscribe, that is what a client does. So either you use the integration in your chirpstack.toml to send the messages to another broker, or you make whatever application you would have on your external PC subscribe to Chirpstacks MQTT broker.

Sure, but technically it should be “Chirpstack” not “Integration” in the box sending to the external MQTT broker.

The guide literally shows you how to generate the certificates. Personally though I use openssl for certificate generation. But in my own Chirpstack deployment I am not using these self signed certificates at all. Instead I use a reverse proxy Traefik as I suggested to sandeep.

Any solution, references to resolve the issue ?

Raspberrypi Gateway(running UDP packet forwarder,chirpstack gateway bridge,mosquitto mqtt broker and chirpstack)
by getting mqtt broker certificate from integration slection inside application tab as given in the figure

2)does the below setup works?which all configuration files must i edit?

gateway <------ UDP packet forwarder------->chirpstack gateway bridge<—MQTT message------>MQTT broker<-----subscribing to MQTT topics—chirpstack network server+apps server------->Integration with MQTT------->publishing topics application/APPLICATION_ID/device/DEV_EUI/

external MQTT broker(in PC) with TLS subscribing to the topics application/APPLICATION_ID/device/DEV_EUI/

3)if external mqtt broker works where should I generate MQTT server-certificate according to
MQTT TLS Integration ?

No we didnt installed concentratord.
We run Semtech UDP packetforwarder in raspberrypi and installed chirpstack gateway bridge,Mqtt Broker mosquitto and chirpstack in Raspberrypi and rasberrypi is connected to the pc via Etherenet.chirpstack dashboard is accessed from PC.
you guided us in trying out smooth communication by MQTT broker in PC instead in raspberrypi before.(Running MQTT in local PC and Gateway status is Offline)

sandeep_sivadas:

So should i make it accessible to internet for accessing chirpstack web ui from remote PC?

I don’t know, this seems like a question you should be answering. Just make sure before you do you secure the ports you will expose publicly, and assuming you just have some typical home network and nothing fancy, the easiest way to expose those would be a port forward from your routers public IP to the webUI port and optionally another for MQTT if you want to connect other gateways through WAN.

Parvathy_Nair:

is it possible?we would like to explore that

Ya it’s possible, as stated here:

Here

and here

Theres also documentation MQTT - ChirpStack open-source LoRaWAN® Network Server documentation, MQTT - ChirpStack open-source LoRaWAN® Network Server documentation,
Event types - ChirpStack open-source LoRaWAN® Network Server documentation

Interesting, does that mean you installed concentratord manually? How did you get the gateway functionality on the Pi?

is it possible?we would like to explore that

yes.

No we are not using Chirpstack Gateway OS instead we installed chirpstack via Ubuntu install method (Debian / Ubuntu - ChirpStack open-source LoRaWAN® Network Server documentation)

if this method can be adopted ,the separate application must subscribe to which topics? or can we know how the chirpstack network server subscribe to which topics?

i am using UDP packet forwarder as well as chirpstack gateway bridge so as to translate Lora packets in to MQTT protocol

As for now, i am using raspberry pi as my lorawan gateway using Wm1302 and i am running chirpstack network server in raspberry pi OS . So my personal server is raspberry pi.So should i make it accessible to internet for accessing chirpstack web ui from remote PC?