Webpage won't connect to MQTT

[Rich M]

I've been setting up Weewx with Belchertown, and everything seems to be working great...except that I cannot connect to the MQTT within the skin.

My Mosquito server is running in a docker on my Unraid server, and I have an Ubuntu VM that is gathering UDP packets from my Tempest Weatherflow station.  Weewx is writing the data to the Mosquito server without problem.  I can connect to the server on my local network with MQTT Explorer, and I can see the weather data & loop. 

For the web page, I'm running a Cloudflare tunnel into my network, and I have a CaddyV2 reverse proxy between the tunnel and the web server.  I'm able to access the website from the Internet without problem:  https://www.2whippets.org/weather/belchertown/

I have a DNS entry for mqtt.whippets.org set up in cloudflare for the websockets, and I'm able to use MQTT Explorer to connect to the tunnel from the internet.  wg://mqtt.2whippets.org on port 443 (with TLS encryption).  It goes through the cloudflare tunnel to the caddy proxy that has a config as such:

{
  log
  tls internal
  reverse_proxy 192.168.254.3:9001
}

And it works through MQTT Explorer. 

However, in my Weewx.conf file, my connection looks like this:

#--- MQTT Websockets (for Real Time Streaming) Options ---
            mqtt_websockets_enabled = 1
            mqtt_websockets_host = "ws://mqtt.2whippets.org"
            mqtt_websockets_port = 443
            mqtt_websockets_ssl = 0
            mqtt_websockets_topic = "weather/#"
            # disconnect_live_website_visitor = 1800000

It doesn't seem to make any difference if I turn on Websockets_ssl.  It still fails. 

I'm using the cloudflare tunnel so that all of the certificates are taken care of by cloudflare...and I don't have to open any ports on my firewall. 

Any ideas of where to troubleshoot?

Thanks

rm

[gary....@gmail.com]

It's likely that the websockets port is not 443 as that is https and you do have your reverse proxy set for 9001

[Rich M]

I found two things:  1...there really was no reason to use the proxy server for the mqtt calls.  So I took it out of line, and just ran the request through the cloudflare tunnel.  Worked like a charm.  

2.  Using a userid and password for authentication for mqtt works...but the credentials show up as clear text in the javascript.  So no real security there.  Easier to just use an anonymous mqtt server.  It's just weather data.  

[michael.k...@gmx.at]

It's kind of obvious that the credentials have to show up in the front end, if you want to provide the mqtt functionality publicly. Letting subscribe any anonymous client to the topic is with "hey, only weather data" no problem, I agree. But if you can't restrict publishing on that topic, anyone could publish anything, that might get displayed on you website: "Welcome users, currently we have 'f**k y*u' degrees in Belchertown", is probably not a desired message to be displayed.

You can create a user for your broker, which has only subscribe access to limited topics.

The topic list is limited to the ones that carry live data to be shown on your site.

Nothing else can be done, but subscribe to the topic.

==> it's no issue to provide these credentials readable for everyone.

Allowing any anonymous user to subscribe (and only subscribe) is also okay. It all depends, in which way you can set it up. With my provider, I can't configure anonymous access, so the credentials for a "subscribe only" client is visible in the front end.

[jterr...@gmail.com]

" Using a userid and password for authentication for mqtt works...but the credentials show up as clear text in the javascript.  So no real security there.  Easier to just use an anonymous mqtt server.  It's just weather data."

It depends on the way authentication and access control list (acl)  are defined, if any.  Anonymous access imply  that anyone could use your MQTT for their own purpose, i.e; even publishing and retrieving their own topics .

My mosquito MQTT broker is configured with authentication and acl, with an account user=public, password=public . As you said, this account is not hidden since it shows up as clear text in the javascript, but it is limited to listen to a specific topic; with no rights to publish anything or to listen to any other topics.

[vince]

Add a packet filter rule only permitting mqtt/1883 in from the public ip of your weewx system, if you have a stable ip from your internet provider...