Hello,
In case of mesh architecture, the Relay and Border gateways are also working as normal gateways? Or relay gateways are there to just extend the LoRa signal to the Border one?
This might be stupid question, but I am about to plan a extension to my LoRaWan network into the area where I have no network connectivity at all. So mesh could be a perfect solution.
What do you mean by “working as a normal gateway”? If you mean can they still receive messages from nearby nodes then yes. Regardless of whether it is a relay or border gateway they can still receive packets. There is also an option to disable receiving packets directly from nodes if it is a border gateway, which is helpful for testing in smaller spaces.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
Sorry that this topic was closed automatically (it was incorrectly set to close after 3 days, which should have been 3 months).
In general a Relay gateway would not be internet connected, thus it would only operate as a Relay gateway. The Border gateway however is internet connected and is able to both process Mesh encapsulated uplinks and uplinks directly received from end-devices (which can be disabled, which can come handy when testing).
Thanks @brocaar for reviving the topic.
In fact @Liam_Philipp answered my question too. I wanted to make sure that Relay gateways also can receive the messages from end-devices.
So typical simplified scenario will be: end-device sends uplink to Relay gateway, relay gateway forwards these messages to Border Gateway, Border Gateway send the data to Chirpstack server.
Meanwhile Both, Relay and Border Gateway appear “Online” in Chirpstack gateway list.
Am I correct?
Thanks a lot for clarification
I havent got the mesh working yet but I believe once its up you see you border gateway online, and then if you update chirpstack there is a section called Gateway mesh that I believe gets populated with your relay gateways
Interesting. Let me update Chirpstack. Thanks
Another follow up question: I see that there are two versions of ChirpStack Gateway OS: one for RPI another for RAK. I have both gateways, so I am thinking to test it on field.
Thanks
Unfortunately, you will loose this ability, but you can always revert the gateway back to WisGateOS.
Also, is it possible to have hybrid setup? If I have one GW on Chirpstack OS and another GW on WisGate original OS
Please note that the WisGateOS does not (yet) support the Mesh feature. But in general, there is no requirement that all gateways are ChirpStack Gateway OS. You can mix and match 
Noted. I will be testing it soon.
One more question, so by default the GW will be in Relay mode. In below snap, it says that Border Gateway should be using MQTT forwarder and it should be configured in ‘Mesh’ tab.
I assume, I just have to activate MQTT forwarder (with the rest of mqtt configs) and disable UDP Forwarder? I can’t find ‘Mesh’ tab in particular…
If you click on MQTT forwarder there should be two tabs at the top of the page for the regular vs mesh configuration.
Thanks @Liam_Philipp
ok, so I installed the mesh image on my 2 gateways. These are RPI CM4/RAK 2287 and RPI CM4/RAK5146.
I am using MQTT for Chirpstack communication.
I also have Version v4.9.0 installed on the server side.
All is working fine, both gateways are working normally. However, the moment I try to activate mesh, the gateways loose the Gateway ID and go offline. No uplinks received from nodes.
I tried setting both options: Border and relay. Tried to play with different parameters. I don’t see anything in the Relay Gateways section as well.
Btw, should I put the Signing key on the server side as well somewhere? I have changed it from zeros to the custom one (same on both GWs)
Is there any other tweaks I should do to start tasting the mesh feature?
Thanks
Did you configure the Mesh tab in the MQTT forwarder for your border gateways?
Hi @Liam_Philipp , sorry for late reply. Yes Mesh is also activated in MQTT part.
Let me do a full summary + logs and will post it by the end of week. thanks for the help
Hello,
Here is my setup.
Server:
chirpstack 4.9.0
chirpstack-gateway-bridge 4.0.11
Gateway
HW: Raspberry CM4 + RAK5146
OS: ChirpStack Gateway OS 4.5.2 Base / LuCI openwrt
Note it worked OK before I installed the mesh Chirpstack GatewayOS v4.5.2. Previous OS was also Chirpstack Gateway OS (but without mesh), working over MQTT.
After upgrading to Chirpstack GatewayOS v4.5.2: Upon booting up, gateway is online for few seconds and then it is loosing connection. From UI I see that Gateway ID is correctly set and after few seconds it says “could not read gateway_id”. This is happening, even before enabling the mesh features.
Here is the view from the GW UI:
System log from Gateway:
I have enabled anonymous access for mosquitto for the test, but still I see MQTT related errors.
Fri Oct 4 14:34:02 2024 user.info chirpstack-mqtt-forwarder[2345]: Subscribing to command topic, topic: eu868/gateway/0016c001ff1e958f/command/+
Fri Oct 4 14:34:02 2024 user.info chirpstack-mqtt-forwarder[2345]: Sending conn state, topic: eu868/gateway/0016c001ff1e958f/state/conn
Fri Oct 4 14:34:02 2024 user.err chirpstack-mqtt-forwarder[2354]: MQTT error, error: Mqtt state: Io error: Custom { kind: ConnectionAborted, error: "connection closed by peer" }
Fri Oct 4 14:34:03 2024 user.info chirpstack-mqtt-forwarder[2354]: Subscribing to command topic, topic: eu868/gateway/0016c001ff1e958f/command/+
Fri Oct 4 14:34:03 2024 user.info chirpstack-mqtt-forwarder[2354]: Sending conn state, topic: eu868/gateway/0016c001ff1e958f/state/conn
Fri Oct 4 14:34:03 2024 user.err chirpstack-mqtt-forwarder[2345]: MQTT error, error: Mqtt state: Io error: Custom { kind: ConnectionAborted, error: "connection closed by peer" }
Fri Oct 4 14:34:04 2024 user.info chirpstack-mqtt-forwarder[2345]: Subscribing to command topic, topic: eu868/gateway/0016c001ff1e958f/command/+
Fri Oct 4 14:34:04 2024 user.info chirpstack-mqtt-forwarder[2345]: Sending conn state, topic: eu868/gateway/0016c001ff1e958f/state/conn
Fri Oct 4 14:34:04 2024 user.err chirpstack-mqtt-forwarder[2354]: MQTT error, error: Mqtt state: Io error: Custom { kind: ConnectionAborted, error: "connection closed by peer" }
Fri Oct 4 14:34:05 2024 user.info chirpstack-mqtt-forwarder[2354]: Subscribing to command topic, topic: eu868/gateway/0016c001ff1e958f/command/+
Fri Oct 4 14:34:05 2024 user.info chirpstack-mqtt-forwarder[2354]: Sending conn state, topic: eu868/gateway/0016c001ff1e958f/state/conn
Fri Oct 4 14:34:05 2024 user.err chirpstack-mqtt-forwarder[2345]: MQTT error, error: Mqtt state: Io error: Custom { kind: ConnectionAborted, error: "connection closed by peer" }
Fri Oct 4 14:34:06 2024 user.info chirpstack-mqtt-forwarder[2345]: Subscribing to command topic, topic: eu868/gateway/0016c001ff1e958f/command/+
Fri Oct 4 14:34:06 2024 user.info chirpstack-mqtt-forwarder[2345]: Sending conn state, topic: eu868/gateway/0016c001ff1e958f/state/conn
Fri Oct 4 14:34:06 2024 user.err chirpstack-mqtt-forwarder[2354]: MQTT error, error: Mqtt state: Io error: Custom { kind: ConnectionAborted, error: "connection closed by peer" }
From Server side mosquitto logs I do not see any rejected requests at all, only successful gateways.
1728038113: New client connected from 178.134.176.10:50200 as 0016c001ff1e958f (p5, c0, k30, u'GW').
1728038114: New connection from 178.134.176.10:50206 on port 1883.
1728038114: Client 0016c001ff1e958f already connected, closing old connection.
1728038114: New client connected from 178.134.176.10:50206 as 0016c001ff1e958f (p5, c0, k30, u'GW').
1728038115: New connection from 178.134.176.10:57064 on port 1883.
1728038115: Client 0016c001ff1e958f already connected, closing old connection.
1728038115: New client connected from 178.134.176.10:57064 as 0016c001ff1e958f (p5, c0, k30, u'GW').
1728038116: New connection from 178.134.176.10:57070 on port 1883.
1728038116: Client 0016c001ff1e958f already connected, closing old connection.
1728038116: New client connected from 178.134.176.10:57070 as 0016c001ff1e958f (p5, c0, k30, u'GW').
1728038183: New connection from 178.134.176.10:52666 on port 1883.
1728038183: Client 0016c001ff1e958f already connected, closing old connection.
1728038183: New client connected from 178.134.176.10:52666 as 0016c001ff1e958f (p5, c0, k30, u'GW').
@Liam_Philipp can you suggest the next thing to check?
These errors are very strange. I don’t think I can help you much on this front.
On the MQTT side, the broker is closing the connection repeatedly as it thinks the Pi is reconnecting with each new message (perhaps because of the port changes, idk why this would be happening).
As for losing the gateway_eui, this is even weirder. Since the shield connection to the Pi is over serial the MQTT issues are separate and would not affect this. My assumption is that since your HAT is not supported in the shield list, this may just be an issue of new functionality not being supported by the older HAT.
Perhaps @brocaar might be able to shed some light on that specific RAK hat.
Thanks a lot @Liam_Philipp for your inputs
Btw, although my RAK hats (I have RAK2287 and RAK5146) are not listed in the shield list, I can see both of them in the GW confg drop down menu (snapshot below). RAK2287 is bit old version, but the RAK5146 is the latest one.
I am crossing my fingers that your doubt about functionality support is not correct 
Actually I paused the rollout of the new project, as I was planing to deploy Wifi extender like this one, because mesh setup (or at least hybrid mesh) looks more temptive
Hopefully I can get it running.
Small additional info:
Although Gateway ID is not showing up, I can see the concentrator itself is up and even reacting for uplinks based on status led (of course these uplinks are not going anywhere further)
