Will this allow me to use Semtech Basic Station to connect to the server?
I need to test the latest SBS on a LoRa Gateway.
The latest release of the Chirpstack 3.x server results in my gateway displaying this error message when connecting using SBS. (Error message is from SBS itself)
“Sep 8 14:16:45 RG1xx29D9CE user.notice lora: 2022-09-08 14:16:45.188 [S2E:WARN] Received ‘dnmsg’ before ‘router_config’ - dropped”
Let me start by saying I’m not sure who I should be bringing this report to (RAKWireless vs. here). I decided to start here because Chirpstack v4 docs indicate that the v3 gateway bridge should work with Chirpstack v4 in protobuf mode—Am I correct in understanding that backwards compatibility with protobuf formats is expected?
Our problem: We have many RAK7289 gateways running the WisGateOS. I don’t believe–but don’t know for sure–that WisGate uses chirpstack-gateway-bridge internally; however, one way or another they support both Chirpstack’s JSON and protobuf protocols. I have had much success with this gateway and Chirpstack v3.
When upgrading to Chirpstack v4 things have mostly worked. I see uplinks for other nearby devices and JoinRequests from my sensors. I see Chirpstack command a downlink over MQTT, but that is where things end. When the command is received by the gateway, it reports:
Which isn’t that useful, but indicates the protobuf message was somehow not as expected. I did notice that the downlink protobuf definitions have had some changes in the code and there is now a “legacy” structure. I’m still trying to grok how that is involved, but I suspect it is part of the issue.
Does Chirpstack v4 somehow detect old versions of the protocol? Perhaps that check is not sufficient for RAK’s bridge? Should everything be backwards compatible and the bug on RAK’s side? Should this be reported on GitHub?
We are very excited about Chirpstack v4. The new UI is great and everything is very easy to deploy. Thank you for working on and gifting us this work!
Unfortunately, we already have the topics configured that way. Uplink (from sensors not part of this network) and gateway stats work fine. I’m not sure about ACKs because I can’t get anything to join without downlinks.
I am relatively confident that the gateway is receiving the downlink protobuf messages because the gateway log message
@brocaar Yikes. The protocol is in fact not backwards compatible. That is pretty unfortunate, because now to move to the new code base, every gateway in the network first needs to be updated.
Please note that to ease the migation to v4 that the latest ChirpStack Gateway Bridge v3 version is forward compatible with ChirpStack v4 (thus you can upgrade your gateways while continue using v3, and then migrate your NS to ChirpStack v4).
I know that it can be a hassle to upgrade all gateways, but there were a couple of things that I wanted to cleanup in the protocol. Doing this at a major release seemed like the best way to do this
@brocaar I fully understand and appreciate the cleanup. I hope my last note didn’t come off as a complaint! I was intending it to be a thinking-out-loud on if that will be a blocker to moving everyone over to the new code base. I’m not sure what your intentions are in terms of supporting v3 long-term.
In my case, the RAK firmware does not appear to use your gateway bridge, but rather they have some custom implementation of the protocol. (Maybe it is possible to build the gateway bridge for the device?) As far as I can tell, RAK’s lorasrv binary implements most of the functionality and is closed source. As a workaround, I brought up a Gateway Bridge instance on our server and used the semtech_udp protocol. This has unblocked us for the time being.
Perhaps this issue is not widespread and the RAK design is just annoying? It was easy to migrate our Tektelic Macro gateway by simply updating the Chirpstack Gateway Bridge that runs on it.
Side question: I believe Semtech UDP is not well suited to be routed over the Internet. If using the gateway bridge on the gateway is not an option, is Semtch UDP or Basic Station a better choice?
Hi @brocaar,
i want to pick up that question, what is the best way to migrate from a running production ChirpStack v3 to v4? Will the migration tool support container in the future or do you already have some scripts?
If i can help with beta testing this usecase, let me know.
Note that in some cases, you can load your own packages on the gateway (I’m not sure if this is possible with the RAK firmware), most embedded osses have a package-manager called opkg.
If not, then you could use both the UDP and Basics Station forwarders. There might be some issues with the UDP protocol (I’ve seen issues in combination with using Docker).
thank you for the reply. Yes i did - but im not sure how to use it with two different docker stacks - but if this is the way i will try to figure it out how to use it with two isolated docker stacks.
