Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Trouble connecting from webbcontent to private broker
#1
Very happy with the afterburner but got stuck on getting remote controlling to work.
My setup is rasberry running mosquitto broker, connected to wifi-1 and afterburner connected on wifi-2, and the webbcontent on https://mrjones.id.au/afterburner/mqtt.html for access. I use a dyn-dns service for getting current ip to wifi-1 even if changing, and I use port forward on wifi-1 to the rasberry. One forwarding for tcp port and one for websocket.

I have managed to configure the afterburner to connect to the broker on the tcp port and I can subscribe and receive status topics from the afterburner using mosquitto_sub to the broker so that seem to be working fine working.

But I can not connect webbcontent to the broker on the websocket port.

Now doing a test setup on wifi-1 location without the afterburner and was thinking I should see successful connection status in the webbcontent and in mosquito broker log (all logs enabled) even though afterburner not connected(it and wifi2 is currently off-line when I'm testing), and even though no afterburner topics are pusblished. Correct?

I could verify that the brokers listener on the websocket port is working, by using python paho and creating a websocket connection to the dyn dns address with the port(3030) I forward to the websocket listener port (8000). And I can publish topics and subscribe to see them when subscribing on the tcp port (1883). 

Both my test-subscriber, test-pubslisher, broker and the webb content are on same wifi wifi-1, but broker and test subscriber are on one machine while test publsiher and the webbcontent are on another machine.
I have mqtt user and pasword configured in broker. And I have put same in webbcontent dialog as in my test connection.

Webb content keeps trying to connect but fail.
In the webbcontent i see print Socket error AMQJS0007E Socket, and then it changes to Connection Timout
I can see the JS webbcontent fails on mqttws31.js:979 "this.socket = new WebSocket(wsurl, ["mqtt"]);", but I only see failed connection. Noting in the mosquitto broker log about the webbcontent trying to connect.
If I use chrome I get wss and if firefox ws, but looks same error.

Any ideas? Where am I thinking wrongly.

Best regards David in Sweden
Reply
#2
Have you checked if your ISP is using CGNAT?

If so you will not be able to host any type of server from your LAN.

I did post about this in the FB group, and essentially if your WAN IP falls in the CGNAT range you will need to adopt a VPN approach.
Tailscale is a very easy to set-up method of VPN.
Reply
#3
CGNAT on Facebook group
Reply
#4
Just a note on the protocols for websocket side.

ws:// means plain web socket.
wss:// means secure web socket (via TLS).

It is up to the broker whether it can handle a wss connection, and you would need to add a CA Cert for your broker via the mosquitto config, and likely provide the public key with connection attempts.

With the web content, it depends HOW you loaded the html.

if you use http://afterburner.mrjones.id.au/mqtt.html it should only need the plain jane websocket (ala port 8000).
If you use https://mrjiones.id.au/afterburner/mqtt.html is must be the TLS websocket (if defined and available)

Best check the browser title bar in Chrome that it was not elevated to https://....

The Afterburner does not care if it was a TLS or plain websocket, that is entirely handled by the broker.

The fundamental issue with web pages is you CANNOT open an insecure connection from a page that was loaded via https.

Hope this all makes sense?
Reply
#5
Thanks for quick replay! Now after fiddling bit more it does connect!
Changed port numbers back and forth and made sure to use http:// as you suggested could be important and as I have not configure the broker for TLS. 
I guess wss might have been the culprit. When I use https the print in top of the webb content still says failed to connect to mqtt ws://...
Don't think its CGNAT as my router has public IP 83.x.x.x.
Reply
#6
Yes OK, you have a proper public IP so all concerns about CGNAT can be dismissed.

I do feel sorry for those that cannot run a server when in such a situation.

Possibly Chrome was elevating to secure, but naively using https://afterburner.mrjones.id.au/mqtt.html would likely 404.
Reply
#7
BTW, a most useful tool to check interaction with the broker is MQTT-Explorer.

You can create TCP or websocket connections from that package so readily check from you LAN, or even internet if port forwarding is set up from your router to the broker.
Reply
#8
Yes annoying with cgnat hope my isp always keep not using that. 

Yes I think chrome does that.

Good tip with mqtt Explorer I will check it out.
Reply
« Next Oldest | Next Newest »


Forum Jump:


Users browsing this thread: 4 Guest(s)