Again that suggests a port problem
sudo ufw allow 1883/tcp
Hmm but it has to be port problem with the VM doesnt it?
Possibly, I’m not familiar with Proxmox so I can’t say how the networking works, but the ss -tuln response only showed that the broker was listening, not that the port is actually open
Regardless this doesn’t hurt to try: sudo ufw allow 1883/tcp (assuming it does have ufw enabled)
Yeah im running from one problem into the next one 
the ufw command doesnt work
Ok i installed ufw and opened port 1883,
Ive run the nmap command on the cedalo vms and their ports were open.
On the MQTT_Test machine it was also closed. Im gonna open that one too and then im going to check if mosquitto_sub works
And to confirm, you can ping the specific MQTT port from another server ping <CS-IP>:1883? Or was it only that it can ping the VM in general?
Okay it seems it opened the port only for localhost, anyway i can open the port for a specific address?
Again, idk how Proxmox works. But talking to GPT try:
- Datacenter → VM → Network.
And look for anything that might be telling.
Are your containers in Bridge mode?
So ive read online that a closed port in nmap doesnt mean that its shut down, it just means that no application is currently listening on it. It only makes sense for me, because no ports are restricted in my Environment. It has to be some silly little entry in some file which prevents the connection
But you can’t ping the < CS- IP>:1883 from another server right? Seeing as you can connect to the broker using localhost:1883, clearly the MQTT broker is listening on the right port.
And your mosquitto.conf is the only related configuration file for mosquitto and the default is just:
listener 1883
allow_anonymous true
Which allows connections on any port.
IMHO you need to figure out what mode your containers are in. If the container uses bridge networking, port exposure (-p) is necessary to make the service available outside the container. If host networking is used, the container shares the VM’s network stack directly. In which case you might want to try sudo iptables -L -n -v.
In any default Chirpstack install, the MQTT broker just works and there is no security. So if there are issues with the default it is almost certainly an environment issue. And when you try mosquitto_subbing from a different server you don’t get a permission denied error or any thing, just a connection failed or something similar? That would indicate it’s not reaching the broker at all, and given the nmap saying it is listening on all available interfaces, it means the interface/networking is not set up correctly.
OMG I am so stupid. Of course it had to be mosquitto conf.
There was no
listener 1883
allow_anonymous true
entry, but I was so sure that it was in.
Subscribing now works i get all gateway and app data
Lol, love to hear it. Strange that the nmap showed it listening on all interfaces tho. i.e 0.0.0.0. Maybe I am missing some knowledge there.
Still though, the integration should have worked regardless.
Thats linux for you
Are you receiving the info on the Celadon nodes?
I tested it on MQTT_Test. Now trying on Cedalo vm.
Is there a way to adress multiple servers in chripstack.toml?
My guess would be:
[integration.mqtt]
server= server1
server= server 2
json=true
Not that I know of. I think it only supports a single server you can give it a try tho, you also could consider MQTT bridging though if you needed more.
Perhaps also:
servers=[
"tcp://127.0.0.1:1883",
"tcp://127.0.0.1:1884",
]
Ok i will try this later. So i tried mosquitto sub with my first cedalo broker and it worked. It only shows the up events of my gateway, although i used # in my mosquitto sub command. Maybe chirpstack dowsnt send app date and i have to specify it somewhere
When you say that what are the topics you are seeing. Do they start with <region_prefix> or with application/
If the integration is configured properly, which should only be the single server= line, you should see all data up/down starting with application/
they start with region. No other setting in integration
The region ones are still encrypted and are supposed to be messages directly to/from the gateways. Is this the Chirpstack broker or the Celadon broker you are subbed to?
If its the CS broker, since you directed the integration to another broker, the application/ data will no longer be there.
Your gateway bridge should be pointed at the CS broker, and in the chirpstack.toml the integration should be pointed to the Celadon instance. Then only the encrypted region prefixes will be on the CS broker and only the decrypted application/ on the celadon. This will not affect Chirpstack but will allow the Celadon instances to have the decrypted data.
If you need the application/ on both for debugging purposes, you would need to configure an MQTT bridge, or figure out the integration to two servers.
Ok i think were getting in the right direction. We verfied that Chirpstack sends mqtt data and recieved it via mosquitto_sub on the Cedalo machine, but not on the actual Cedalo broker . I think the actual solution is to create a bridge between the chirpstack broker to the cedalo broker.