Mqtt.js: mqtt over websockets using google chrome

Created on 19 May 2016  路  17Comments  路  Source: mqttjs/MQTT.js

Hello,

I am using this MQTT client in a web application to communicate with a python broker.

In the connect message, the browser (Chrome) outputs in the console the following error:

WebSocket connection to 'ws://127.0.0.1:8888/' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received

In my broker, the following error is presented:

[2016-05-19 11:46:57,027] :: INFO :: hbmqtt.broker :: Connection from 127.0.0.1:53516 on listener 'ws-mqtt' [2016-05-19 11:46:57,027] :: INFO :: websockets.protocol :: Failing the WebSocket connection: 1006 WARNING :: hbmqtt.broker :: MQTT-3.1.0-1: Can't read first packet an CONNECT: No more data

However, using Firefox, as well as Safari, the MQTT client works fine.

Broker Output for Firefox:

[2016-05-19 11:47:32,843] :: INFO :: hbmqtt.broker :: Connection from 127.0.0.1:53524 on listener 'ws-mqtt'

I have a test project for this issue.

Most helpful comment

Hi, according to discussion in hbmqtt#38 the problem seems to come from the client MQTT.js which sends mqttv3.1 as websocket suprotocol whereas it should send mqtt according to MQTT 3.1.1 specifications. Chromes detects a difference between the requested subprotocol and the subprotocol returned by hbmqtt (mqtt) and so closes the connection.

All 17 comments

This seems to be working fine with other brokers? might be your broker implementation?

I tried using other brokers as well, and it did not work. And considering that it works fine in other browsers, I think that chrome needs another type of configuration for the websockets. I also used this broker with other python client and it works properly.

As far I understood, google chrome forces the use of MQTT-3.1.0, and I think that it is the problem, at least for recent brokers.

I will need to have a look at your code, because it is working here.

I've been using Chrome with websockets just fine with Mosquitto and a custom JS broker built on top of MQTT.js.

What version are you currently on? I know that at least 1.7.4 is working for me at the moment.

I am using version 1.8.0 of mqtt, but with browserify conversion. Can I have your Mosquitto configuration file for testing?

I uploaded to my repository the python broker. It needs Python3, as well as hbmqtt pip package.

Sorry, I confused myself. I only got TCP working with mosquitto.

@RangerMauve thanks anyway =)

@mcollina I have commited to my test project the broker. It only needs to be executed with python3 and has the hbmqtt pip dependency.

Thanks for your time

@vasco-santos I am confident this is a bug on hbmqtt, as your project works as-is with other brokers.

@mcollina I am not understanding how the bug may be on hbmqtt.

I used tge hbmqtt broker with other clients and it worked with no problems in all of them. In addition, it works fine with mozila and safari in the MQTT.js implementation. Therefore, I can only consider a bug related to the browser, and consequently with MQTT.js, which interacts with the browser.

I cannot use this implementation with mosquitto as well.

Your project works perfectly with 'ws://test.mosquitto.org:8080' and several Mosca versions. Just change the connection string to 'ws://test.mosquitto.org:8080'.

I'm happy to help debugging this, maybe there is something that we are doing that hbmqtt does not like (or vice versa), but it is hbmqtt-specific.

Yes, it works correctly using mosquitto test broker for mqtt over websockets (Port 8080).

I monitored the network packets using chrome, as well as firefox but I am not noticing any difference in the packages before starting the websockets session.

Considering filter: ip.addr == 192.168.33.20
Chrome: line number 864
Firefox: line number 596

Wireshark.zip

@vasco-santos that's why I think it's hbmqtt problem, not MQTT.js.

hey @njouanin can you help us here?

Let me investigate...

Hi, according to discussion in hbmqtt#38 the problem seems to come from the client MQTT.js which sends mqttv3.1 as websocket suprotocol whereas it should send mqtt according to MQTT 3.1.1 specifications. Chromes detects a difference between the requested subprotocol and the subprotocol returned by hbmqtt (mqtt) and so closes the connection.

Wow, that was a hard find.

Anyway, anybody that wants to send a PR?

The idea is to send 'mqtt' as default subprotocol and 'mqttv3.1'if in the mqtt.connect options for MQTT 3.1 are passed:

{
  protocolId: 'MQIsdp',
  protocolVersion: 3
}

https://github.com/mqttjs/MQTT.js/blob/master/lib/connect/ws.js#L16

Was this page helpful?
0 / 5 - 0 ratings