bluerhinos / phpMQTT

a simple php class to connect/publish/subscribe to a MQTT broker
Other
765 stars 461 forks source link

Notice: Uninitialized string offset: 0 in C:\xampp\htdocs\phpMQTT\phpMQTT.php on line 242 Notice: Uninitialized string offset: 0 in C:\xampp\htdocs\phpMQTT\phpMQTT.php on line 249 Notice: Uninitialized string offset: 3 in C:\xampp\htdocs\phpMQTT\phpMQTT.php on line 250 #117

Open fatihkutuk opened 3 years ago

fatihkutuk commented 3 years ago

i couldnt solve can u look at this problem ?

Armgan commented 2 years ago

i am facing same issue

xuhongv commented 2 years ago

i am facing same issue

anhlephuoc commented 2 years ago

MQTT3.1.1: The Server, upon the reception of a CONN packet, may or may not reply with a CONNACK (which this code is waiting for) but may just close the network connection if it does not like the look of the packet. The returned result in $string on line 240 could be empty! phpMQTT code does not seem to handle network connection failure properly anywhere in the code, so misbehaviour may occur else as well. phpMQTT does not seem to distinguish between a network connection and a session connection on most places (and this issue117 is one such places). For this part, the length of $string can be checked and if equals zero then it's a network connection failure and the following if/else statement should be skipped. That if/else block is only useful when the Server rejects the connection with a reason, but the Server is not required to respond at all.

334943013 commented 1 year ago

MQTT3.1.1: The Server, upon the reception of a CONN packet, may or may not reply with a CONNACK (which this code is waiting for) but may just close the network connection if it does not like the look of the packet. The returned result in $string on line 240 could be empty! phpMQTT code does not seem to handle network connection failure properly anywhere in the code, so misbehaviour may occur else as well. phpMQTT does not seem to distinguish between a network connection and a session connection on most places (and this issue117 is one such places). For this part, the length of $string can be checked and if equals zero then it's a network connection failure and the following if/else statement should be skipped. That if/else block is only useful when the Server rejects the connection with a reason, but the Server is not required to respond at all.

I‘m not being rude,do you fixed this problem?

anhlephuoc commented 1 year ago

One of the forks may have that fixed already but I haven't check. An temporary immediate fix is to check for the $string to be of the required length (4) first. eg, Change line 241 to: if (strlen($string) ==4 && ord($string[0]) >> 4 === 2 && $string[3] === chr(0)) { ...

anhlephuoc commented 1 year ago

And you should also do similar check a few lines later for the when the error message is printed as well. If code arrives here, it means that you have a MQTT session connection failure or rejection or even a physical/network connection failure. There is no way to tell in this software. There is no simple fix for that. I started a fix of clone of this code a enhanced it for my needs (QoS 2, MQTT 5, etc..) but only after a couple of days the was beyond recognition from the origin code so merging back is no longer possible. The restructuring was too major! The BlueRhinos code has only one giant object with one state and a single chain of execution. The fix required multiple independent object (state machines) to represent the network connection, the MQTT session, and each message/packet in transit (for QoS>0). Andrew Milsted (BlueRhinos) in 2020 indicated his intention to rework on this code, and did a merge other people patches recently. Those patches were simple immediate fixes. No real enhancement have been attempted. I am still living in hope!

itdontgo commented 1 year ago

The socket is opened successfully earlier in the code otherwise it would have already returned false. It is returning because the fread has timed out and so has returned an empty string. We just returned false on an empty string and tried to reconnect. You could try another fread or increase the time out on the socket. That's the same thing. Or, try the socket then read again but that's never reliable.

I also don't know why you wouldn't set the socket to blocking until it's read back the acknowledge from the broker. It's not doing anything else with the stream.

znueni commented 1 year ago

I got the (maybe) the same errors Uninitialized string offset: 0 Uninitialized string offset: 0 Uninitialized string offset: 3

After a while, I recognized, that I am connecting to a SECURE MQ connection, but with a broker, that has a valid SSL certificate, so I was not supplying anything as 'cafile' paramter.

Try to change line 150 from

        $this->socket = stream_socket_client('tcp://' . $this->address . ':' . $this->port, $errno, $errstr, 60, STREAM_CLIENT_CONNECT);

to

        $this->socket = stream_socket_client('tls://' . $this->address . ':' . $this->port, $errno, $errstr, 60, STREAM_CLIENT_CONNECT);

i.e. enforcing TLS connection instead of TCP connection.