Chirpstack and Multitech Conduit IP67

ChirpStack Network Server
1

Hi all,

First of all, thank you for this amazing piece of software! At first glance it feels a bit tough to grasp, but once things start to click, it’s clearly very flexible and powerful. :blush:

We’re currently working on deploying ChirpStack with a fleet of Multitech gateways (this one IP67 Conduit), and we’d love some clarification regarding the architecture and components involved.

What we’re trying to achieve

  • Use ChirpStack as the only LoRaWAN Network Server , hosted in the cloud.
  • Keep the gateways as “dumb forwarders” (we don’t want them doing any device authentication).
  • Connect the gateways over 4G/5G to ChirpStack using Basic Station protocol (TLS WebSocket).
  • Use OTAA devices like the Adeunis “Field Test Device”.

What we did so far

  • Installed ChirpStack Gateway Bridge on the cloud server (not on the gateway).
  • Configured the gateway to use Basic Station with:
    • wss://<our_server_ip>:3001
    • appropriate TLS certificates (self-signed, tested via wscat)
    • disabled any local UDP backend or packet forwarder
  • The logs seem to indicate that the gateway connects successfully:
Jun 30 13:50:49 romain chirpstack-gateway-bridge[4889]: time="2025-06-30T13:50:49.111687203Z" level=info msg="backend/basicstation: gateway connected" gateway_id=00800000d0003117 remote_addr="10.101.0.201:52892"
Jun 30 13:50:49 romain chirpstack-gateway-bridge[4889]: time="2025-06-30T13:50:49.117831494Z" level=info msg="backend/basicstation: gateway version received" firmware= gateway_id=00800000d0003117 model=mlinux package= protocol=2 station="2.0.6(mlinux/sx1303)"
Jun 30 13:50:49 romain chirpstack-gateway-bridge[4889]: time="2025-06-30T13:50:49.119765477Z" level=info msg="backend/basicstation: router-config message sent to gateway" gateway_id=00800000d0003117
Jun 30 13:50:49 romain chirpstack-gateway-bridge[4889]: time="2025-06-30T13:50:49.124623695Z" level=info msg="backend/basicstation: gateway disconnected" gateway_id=00800000d0003117 remote_addr="10.101.0.201:52892"

We also see regular router-info requests.

What’s not working

  • In the ChirpStack UI, the gateway stays in the “never seen” state.
  • When we try to activate a device (by pressing the Adeunis test button), no uplink appears, either in logs or UI.
  • The device has been registered with a DevEUI (converted to MSB format), AppKey, and linked to a proper Device Profile (LoRaWAN 1.0.3, EU868).
  • Still, nothing shows up.

Our main questions

  • Are we supposed to run the Gateway Bridge on the gateway itself or is it correct to host it centrally (as we currently do)?
  • Is the Gateway Bridge still the recommended component for this scenario? Or should we be looking at concentratord?
  • Is there something we missed in the Basic Station configuration on the Multitech side (like Backend or channel plan)?
  • Could it be a frequency mismatch or incorrect router-config ?

Any guidance or clarification would be super appreciated. We’ve been experimenting and diving into the documentation, but we’re probably missing something essential.

Thanks again and congrats on this awesome project

2

I also am using Multitech conduit IP67, although I am using the gateway bridge on the gateway, although both setups should work.

You can do either, I prefer to use MQTT / TCP over the air (from gateway bridge) rather then basic-station web sockets.

These are two completely different components. Concentratord is used as a hardware daemon for the lora concentrator on a gateway to receive the lora signals, gateway bridge is used to standardize those messages from UDP / basicstation to MQTT which chirpstack understands. So to be clear the uplink flow goes: gateway concentrator (which is concentratord if using CS GW OS) → UDP/Basic station forwarder → gateway bridge/MQTT forwarder → MQTT broker → Chirpstack.

Could be but it’s likely more a chirpstack issue. You need a bit more info on why it’s not appearing in the UI. Are there any more info in the Chirpstack or MQTT logs? It should show you why the uplinks are being rejected. Is your gateway bridge configured with the appropriate MQTT topic prefix?

A frequency mismatch would cause issues but you should still see join requests from devices if the device ↔ gateway frequencies are aligned. So likely this is something else.

1 Like