Cannot connect IcsMQTTClient to PicoMQTT server

[AndrzejBluszcz 0]

I would appreciate an advice on how to connect IcsMQTTClient to PicoMQTT server on ESP8266. The server does not use SSL and serves other clients normally. IcsMQTTClient is trying to connect but with no success. The server reports that an "unknown" client connected and immediately disconnected. The client keeps connecting but nothing changes. 

I am using the Server / Client Demo from v.9.3 with the following properties

  object MQTTClient: TIcsMQTTClient
    ClientID = 'OverbyteClient'
    KeepAlive = 10
    MaxRetries = 8
    RetryTime = 60
    Clean = True
    Broker = False
    AutoSubscribe = False
    Host = '192.168.1.30'
    Port = 1883
    LocalBounce = False
    SslVerifyCerts = False
    SslReportChain = False
    SslRevocation = False
    SslCliSecurity = sslCliSecNone
    OnMon = MQTTClientMon
    OnOnline = MQTTClientOnline
    OnOffline = MQTTClientOffline
    OnEnableChange = MQTTClientEnableChange
    OnFailure = MQTTClientFailure
    OnMsg = MQTTClientMsg
    Left = 150
    Top = 397
  end
 

Should I set some specific options in the client to enable the connection?

[Angus Robertson 625]

Sorry, no simple answer, the MQTT component was contributed, and only tested against itself.  I don't have any other local MQTT servers to test against, although it was tested against some public servers.  I'm aware there are various versions of MQTT and some servers are non-standard, questionable whether ICS should break the protocol to work with devices that don't follow it, please search back in this forum, I think it's been discussed before.

 

Otherwise, you'll need to use Wireshark or something to see how the other clients are communicating with the server, and change the component to match that.

 

Angus

 

[AndrzejBluszcz 0]

Thank you for the message.

I have tried to capture the transmissions and it seems that IcsMQTTClient uses MQIsdp protocol (MQTT v.3.1) and the connection request has header flags 0x12 while another client, that connects successfully uses MQTT v.3.1.1 and the header flags 0x10.

The PicoMQTT server uses MQTT v.3.1.1.  

Is there a way to change the behaviour of the IcsMQTTClient? I tried to replace 'MQIsdp' with 'MQTT', but that made things worse. The message is not recognised as MQTT command. 

Andrzej

[Mark- 31]

Just now, AndrzejBluszcz said:

Thank you for the message.

I have tried to capture the transmissions and it seems that IcsMQTTClient uses MQIsdp protocol (MQTT v.3.1) and the connection request has header flags 0x12 while another client, that connects successfully uses MQTT v.3.1.1 and the header flags 0x10.

The PicoMQTT server uses MQTT v.3.1.1.  

Is there a way to change the behaviour of the IcsMQTTClient? I tried to replace 'MQIsdp' with 'MQTT', but that made things worse. The message is not recognised as MQTT command. 

Andrzej

The packet fixed header byte for "Connect", regardless of 3.1 or 3.11, is 0x10. The lower 4 bits of the packet fixed header are reserved.

The packet fixed header byte for 3.1:

[AndrzejBluszcz 0]

I am trying to find what sends the connect command but no success so far. Do you know where should I look for it?

Andrzej

[Mark- 31]

Sorry no. I do not use it. I would search for the 0x12 ($12), or the text of the protocol name.

[AndrzejBluszcz 0]

I think it is TIcsMQTTParser.SendConnect procedure. And it makes a header with qtAT_LEAST_ONCE, which is incorrect. I am trying to change it to qtAT_MOST_ONCE and see what happens. 

Andrzej

[AndrzejBluszcz 0]

No. It didn't help. The header is correct now, though. 

[Mark- 31]

What is the response? Or no response?

[AndrzejBluszcz 0]

It is exactly as before with one exception. The header flags are 0x10 now. 

[Mark- 31]

Just now, AndrzejBluszcz said:

It is exactly as before with one exception. The header flags are 0x10 now. 

What does that mean? A trace using Wireshark has no response from the broker?

Edited March 9 by Mark-

[AndrzejBluszcz 0]

There is no response from the broker. However the broker fires OnDisconnect event. That is the broker fires OnConnect and OnDisconnect in quick succession. 

[Mark- 31]

Just now, AndrzejBluszcz said:

There is no response from the broker. However the broker fires OnDisconnect event. That is the broker fires OnConnect and OnDisconnect in quick succession. 

Yeah IIRC, a broker can select to, not answer a connect message or return an error message.

Does the broker documentation state the version(s) or MQTT it supports?

[AndrzejBluszcz 0]

PicoMQTT supports MQTT version 3.1.1.

IcsMQTTClient supports MQIsdp version 3.1 (MQTT v.3.1).

So the versions on both sides are different and this the only thing that I see at the moment.

[Mark- 31]

There are a few commercial MQTT clients. Or you could write your own code. The MQTT protocol is not very complicated, by design.

 

[AndrzejBluszcz 0]

OK. Will see.

Thank you for you time and help, Mark.

 

Andrzej

[Mark- 31]

Just now, AndrzejBluszcz said:

OK. Will see.

Thank you for you time and help, Mark.

 

Andrzej

You are welcome.

[Angus Robertson 625]

I would assume the difference between 3.1 and 3.1.1 is relatively small, so it should be easy to change the ICS component.  But we'd need to know what that difference is, and a server to test against.

 

Angus

 

[omnibrain 18]

I think first and foremost it should work against Eclipse Mosquitto, as it's more or less the reference implementation. https://test.mosquitto.org/

[Angus Robertson 625]

I get Connection NOT AUTHORISED connecting to test.mosquitto.org on ports that say unauthenticated, 

 

I'll spend a few minutes looking to see why, but my knowledge of MQTT is zero, and I don't propose to learn the protocol, maintenance of the ICS MQTT component really needs to be done my users that understand and use MQTT. 

 

Angus

 

[Angus Robertson 625]

I've installed the Mosquitto Broker server locally, and it works OK against the ICS MQTT client.  

 

Our sample currently always adds a default username/password, and this was upsetting test.mosquitto.org on the unauthenticated port, so the sample now allows them to be set specifically, and leaving them blank connects OK to test.mosquitto.org, which is also now on a ComboBox dropdown to make testing easier.

 

But this does not explain why PicoMQTT fails (unless it's also authentication).  Mosquitto supports 3.1, 3.1.1 and 5, I'll see if I can disable 3.1.  There is a comment in the conf file about clients connecting with 3.1.1 and a zero length client Id so the server allocates one, perhaps this explains the difference. 

 

Angus

 

[AndrzejBluszcz 0]

Thank you for your interest in my case. I am also not an expert in MQTT but at home I run a few little servers and clients on ESP microcontrollers. When I am connecting PicoMQTT client to PicoMQTT server there is no problem. I can also connect MQTT client on my iPhone and a commercial iotMQTTClient. In all cases I have empty usernames and passwords and no SSL. PicoMQTT supports v.3.1.1. 

 

Andrzej

[Angus Robertson 625]

I'm updating the ICS MQTT client for v3.1.1 at the moment, should be this week.  Not planning v5 at the moment, that is totally different.  Most servers still support 3.1.1.

 

Angus

 

[AndrzejBluszcz 0]

Thank you. I am looking forward to it.

 

Andrzej

[Angus Robertson 625]

I've updated the ICS MQTT client and server components to support protocol 3.1.1, previously we only supported 3.1. Not finished testing, not checked all packets yet. The client will connect to a v5 server by ignoring dozens of new options, but needs a lot more work, much more complicated than v3.1.1. 

 

Also added a lot more logging so we see the packets being sent and received, and added more options to the sample.

 

In SVN now, the overnight zip will be updated this evening.

 

Angus