Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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 this issue Jan 11, 2021 · 8 comments

Comments

@fatihkutuk
Copy link

i couldnt solve can u look at this problem ?

@Armgan
Copy link

Armgan commented Jul 8, 2021

i am facing same issue

1 similar comment
@xuhongv
Copy link

xuhongv commented Jan 7, 2022

i am facing same issue

@anhlephuoc
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

znueni commented Dec 22, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants