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

minimqtt lib problem with TLS broker #7606

Closed
kllsamui opened this issue Jan 20, 2023 · 42 comments · Fixed by #7623
Closed

minimqtt lib problem with TLS broker #7606

kllsamui opened this issue Jan 20, 2023 · 42 comments · Fixed by #7623
Labels
Milestone

Comments

@kllsamui
Copy link

CircuitPython version

CP800b6 daily 
Adafruit CircuitPython 8.0.0-beta.6-43-g1c1cf1cf5 on 2023-01-18; Raspberry Pi Pico W with rp2040
Board ID:raspberry_pi_pico_w

Code/REPL

negative number of bytes to read: -115

Behavior

use: CP800b6 latest ( from 14. and 18. ) ( with bundle /lib/ from 15. and 17. )
on a PICO_W ( nuked )
to connect to a local broker ( RPI mosquitto) OK
BUT
to a remote broker TLS ( HIVEMQ ) ERROR
always get error at subscribe or publish about
negative number of bytes to read: -115

i think that comes from a recent change of minimqtt lib

++ confirm, all same but replace /lib/minimqtt/
from adafruit-circuitpython-bundle-8.x-mpy-20221221.zip
still works

Description

No response

Additional information

adafruit-circuitpython-bundle-8.x-mpy-20221221.zip
/lib/minimqtt/
OK

@kllsamui kllsamui added the bug label Jan 20, 2023
@dhalbert dhalbert transferred this issue from adafruit/circuitpython Jan 20, 2023
@kllsamui
Copy link
Author

Thanks and sorry @dhalbert

recheck with the 20.1.2023 /lib/ and CP800b6 daily, same problem

@kllsamui
Copy link
Author

kllsamui commented Jan 26, 2023

a more detailed LOG / REPL:

___+++ setup MQTTclient
___++++ use TLS
___ Attempting to connect to xxx.hivemq.cloud
___ Connected to MQTT Broker!
___ Flags: 0 RC: 0
___ Publishing to PICOW-S31
Hello Broker: i am a PICO W
___ Published to PICOW-S31 with PID 0
___ Subscribing to PICOW-S31/Site2/set tuning
Error: MQTT subscribe tuning
negative number of bytes to read: -115

so the error is from the subscribe and then connection is BAD
.next.
disable that subscribe for test
and now get

negative number of bytes to read: -4294967284
......RESTART MQTT connection at sec: 9727.77

@kllsamui kllsamui changed the title minimqtt lib SSL problem minimqtt lib problem with TLS broker Jan 28, 2023
@kllsamui
Copy link
Author

just to check: CP800RC1
same, so still use CP800B6 original minimqtt
( from file adafruit-circuitpython-bundle-8.x-mpy-20221221.zip )
for connect to TLS broker

@kllsamui
Copy link
Author

if you want test can use
http://kll.engineering-news.org/kllfusion01/downloads/minimqtt_problem.zip

even use my hivemq account but DM_ME for user password

@vladak
Copy link

vladak commented Feb 15, 2023

I registered an account at HiveMQ and extracted relevant code from code.py however cannot replicate the problem with the latest minimqtt module, at least using CPython on MacOS - the subscribe goes through just fine.

@vladak
Copy link

vladak commented Feb 15, 2023

I wonder whether this problem happens (with the same code) also on other microcontrollers, particularly those with different underlying TLS implementation, like ESP32 based ones.

@vladak
Copy link

vladak commented Feb 15, 2023

For the record, here's the piece of code leading to the exception in _sock_exact_recv(): https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/blob/342b8c99b2c8f10b605cc8311bf5f394f4d18e92/adafruit_minimqtt/adafruit_minimqtt.py#L1067-L1074

The Python documentation for recv_into() says:

socket.recv_into(buffer[, nbytes[, flags]])
Receive up to nbytes bytes from the socket, storing the data into a buffer rather than creating a new bytestring. If nbytes is not specified (or 0), receive up to the size available in the given buffer. Returns the number of bytes received.

Now, bufsize is mandatory parameter of _sock_exact_recv() and I believe is always small positive number within the subscribe() code path so the only explanation I have right now is that recv_into() returned a number bigger than the nbytes, in this case bufsize. If that's indeed the case, the bug should return back to circuitpython core.

One way how to verify would be to copy adafruit_minimqtt.py to the microcontroller instead of the compiled version and augment the _sock_exact_recv() therein to print the recv_len and bufsize values. Traffic dump might be also interesting piece of information.

@kllsamui
Copy link
Author

kllsamui commented Feb 16, 2023

thanks for looking into this


any idea about the relevant recent changes made in minimqtt
between cp800b6 and ( some days later .. up to ) now?

i just checked again PICO_W with
Adafruit CircuitPython 8.0.0 on 2023-02-06; Raspberry Pi Pico W with rp2040
Board ID:raspberry_pi_pico_w

same problem,

while lib from 22.12.2022 ok

i could not follow that changes / looks for me like there was not any REPAIR needed / more a ?cleanup attempt?


actually i worry my call is wrong? like
i not use this parameter
:param bool is_ssl:

but as i say, my code works with the old lib

@vladak
Copy link

vladak commented Feb 16, 2023

I will begin from the end. The is_ssl parameter as it is implemented currently, is set to True by default and as long as the port is set to 8883 and the ssl_context parameter is valid, TLS will be used. There is no fallback to insecure (plaintext) connection if TLS setup fails (which is a good thing as it avoids downgrade attacks). The default behavior of is_ssl might or might not change with PR adafruit/Adafruit_CircuitPython_MiniMQTT#145. Anyhow, if TLS is desired, setting is_ssl to True explicitly is the right thing to do, even though it is not needed currently.

@kllsamui
Copy link
Author

@vladak
Copy link

vladak commented Feb 16, 2023

There are 2 possibilities I can see how the to_read variable in _sock_exact_recv() can become negative:

  • the bufsize parameter of the function was already negative
  • recv_len returned from recv_into() was strictly bigger than the bufsize

The former might be a problem in MQTT message parsing, the latter would be a bug in CircuitPython core. Now, there are only 2 calls to _sock_exact_recv() that supply non-literal number and these are both in MQTT PUBLISH message parsing.

If you are willing to help debug this, I will prepare a special version of adafruit_minimqtt.py with extra debug logging that can be placed on the Pico W and be used to shed more light on this issue. In the mean time, install adafruit_logging and enable logging with:

import adafruit_logging as logging

...

mqtt_client = MQTT.MQTT(...)
mqtt_client.enable_logger(logging, log_level=logging.DEBUG)

@vladak
Copy link

vladak commented Feb 16, 2023

Looking into the code of subscribe(), I can see potential for breakage: https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/blob/342b8c99b2c8f10b605cc8311bf5f394f4d18e92/adafruit_minimqtt/adafruit_minimqtt.py#L785-L802

The first issue is that the client expects SUBACK to be sent in direct response to SUBSCRIBE. If any other message type is received from (buggy/rogue) broker, the parsing will get out of sync, because part of the message will remain in the read buffer. In such (rare ?) case the other message should be processed fully or exception thrown.

The second issue is that the code expects fixed length of the SUBACK, specifically 4 bytes (L788 above), possibly assuming single topic to be subscribed. When a client subscribes to multiple topics at once (which the subscribe() function allows), the SUBACK will contain return codes for each topic.

Unsubcribe handling has the same problem, however this will matter only for MQTT protocol version 5 and above, I believe.

@kllsamui
Copy link
Author

kllsamui commented Feb 17, 2023

yes, i try
upgrade CP802
add lib and code LOGGING


code.py output:
___ Connecting to router kll-wlan_2.4G OR CHECK THE 'settings.toml' FILE
___ Connected to kll-wlan_2.4G
___ Listening on http://192.168.1.214:80 
___+++ setup MQTT
___+++ setup MQTTclient
___++++ use TLS
___ Attempting to connect to <xxx>.hivemq.cloud
1250.108: DEBUG - Attempting to connect to MQTT broker (attempt #0)
1250.112: DEBUG - Attempting to establish MQTT connection...
1250.117: INFO - Establishing a SECURE SSL connection to <xxx>.hivemq.cloud:8883
1252.697: DEBUG - Sending CONNECT to broker...
1252.702: DEBUG - Fixed Header: bytearray(b'\x10,\x00')
1252.707: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
1252.716: DEBUG - Receiving CONNACK packet from broker
___ Connected to MQTT Broker!
___ Flags: 0 RC: 0
1253.029: DEBUG - Resetting reconnect backoff
___ Publishing to PICO_W
Hello Broker: i am a PICO W
1253.037: DEBUG - Sending PUBLISH
Topic: PICO_W
Msg: b'Hello Broker: i am a PICO W'                            
QoS: 0
Retain? False
___ Published to PICO_W with PID 0 
___ Subscribing to PICO_W/set tuning
1253.051: DEBUG - SUBSCRIBING to topic PICO_W/set with QoS 0
Error: MQTT subscribe tuning
 negative number of bytes to read: -115
___ MQTT broker: <xxx>.hivemq.cloud
___ mqtt_topic: PICO_W
1253.163: DEBUG - waiting for messages for 0 seconds
Error: MQTT loop
 negative number of bytes to read: -4294967284
1253.672: DEBUG - waiting for messages for 0 seconds
Error: MQTT loop
 negative number of bytes to read: -4294967284
1254.182: DEBUG - waiting for messages for 0 seconds
1254.691: DEBUG - waiting for messages for 0 seconds
1255.199: DEBUG - waiting for messages for 0 seconds
Error: MQTT loop
 negative number of bytes to read: -4294967284
1255.707: DEBUG - waiting for messages for 0 seconds
Error: MQTT loop
 negative number of bytes to read: -4294967284
1256.216: DEBUG - waiting for messages for 0 seconds
Error: MQTT loop
 negative number of bytes to read: -4294967284
Traceback (most recent call last):
  File "code.py", line 240, in <module>

ok and when using the OLD lib (21.12.2022)

code.py output:
___ Connecting to router kll-wlan_2.4G OR CHECK THE 'settings.toml' FILE
___ Connected to kll-wlan_2.4G
___ Listening on http://192.168.1.214:80 
___+++ setup MQTT
___+++ setup MQTTclient
___++++ use TLS
___ Attempting to connect to <xxx>.hivemq.cloud
2471.574: DEBUG - Attempting to establish MQTT connection...
2471.580: INFO - Establishing a SECURE SSL connection to <xxx>.hivemq.cloud:8883
2475.193: DEBUG - Sending CONNECT to broker...
2475.198: DEBUG - Fixed Header: bytearray(b'\x10.\x00')
Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
2475.208: DEBUG - Receiving CONNACK packet from broker
___ Connected to MQTT Broker!
___ Flags: 0 RC: 0
___ Publishing to PICO_W
Hello Broker: i am a PICO W
2475.474: DEBUG - Sending PUBLISH
Topic: PICO_W
Msg: b'Hello Broker: i am a PICO W'                                
QoS: 0
Retain? False
___ Published to PICO_W with PID 0 
___ Subscribing to PICO_W/set tuning
2475.485: DEBUG - SUBSCRIBING to topic PICO_W/set with QoS 0
___ Subscribed to PICO_W/set with QOS level 0
___ MQTT broker: <xxx>.hivemq.cloud
___ mqtt_topic: PICO_W
2535.875: DEBUG - KeepAlive period elapsed - requesting a PINGRESP from the server...
2535.879: DEBUG - Sending PINGREQ
2536.353: DEBUG - Got PINGRESP

@kllsamui
Copy link
Author

kllsamui commented Feb 17, 2023

try an other thing
( not understand but got idea from YOU it might be timing related / msg crossing? )

sleep 2.0
___ Subscribing to PICOW-S31/Site1/set tuning
Error: MQTT subscribe tuning
 negative number of bytes to read: -115

so this:

        try:
            dp("___ Publishing to %s" % MQTT_mtopic) # ____ only master topic gets that
            dp(mqtt_hello)
            mqtt_client.publish(MQTT_mtopic,mqtt_hello )
            MQTTok = True # _______________________________ used later for publish
        except Exception as e:
            print("Error: MQTT publish hello\n", str(e))
            #MQTTok = False
            
        # current problem with next subscribe leads to mqtt error
        # let's try a wait here:
        dp("sleep 2.0")
        time.sleep(2.0)
        
        try:
            # setup subscribe
            mqtt_topic_tune = mqtt_topic + "/set"
            dp("___ Subscribing to %s tuning" % mqtt_topic_tune)
            mqtt_client.subscribe(mqtt_topic_tune)
        except Exception as e:
            print("Error: MQTT subscribe tuning\n", str(e))
            #MQTTok = False

        dp("___ MQTT broker: "+MQTT_broker)
        dp("___ mqtt_topic: "+mqtt_topic)

DID NOT HELP!


an other thought,
point is not only that on action ( subscribe ) sees a bad broker response,
it is that from then on all comm is down
? after a error like that buffers should be cleaned?

also that is not random,
the 2 negative numbers of bytes are always same
-a- -115
-b- -4294967284
like a integer or decryption error of a good number


also again i would like to ask,
what kind of changes have been made recently what could lead to this
( as working backwards to the last good lib )

@vladak
Copy link

vladak commented Feb 17, 2023

Could you grab https://raw.githubusercontent.com/vladak/Adafruit_CircuitPython_MiniMQTT/msg_debug/adafruit_minimqtt/adafruit_minimqtt.py , place it on the Pico W, run the program and provide the logs ?

Just replace the lib/adafruit_minimqtt/adafruit_minimqtt.mpy file with the one linked above and rerun the code.

@kllsamui
Copy link
Author

kllsamui commented Feb 17, 2023

test:

___ Connecting to router kll-wlan_2.4G OR CHECK THE 'settings.toml' FILE
___ Connected to kll-wlan_2.4G
___ Listening on http://192.168.1.214:80 
___+++ setup MQTT
___+++ setup MQTTclient
___++++ use TLS
___ Attempting to connect to <xxxx>.hivemq.cloud
365.941: DEBUG - Attempting to connect to MQTT broker (attempt #0)
365.946: DEBUG - Attempting to establish MQTT connection...
365.951: INFO - Establishing a SECURE SSL connection to <xxxx>.hivemq.cloud:8883
368.447: DEBUG - Sending CONNECT to broker...
368.453: DEBUG - Fixed Header: bytearray(b'\x10-\x00')
368.457: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
368.466: DEBUG - Receiving CONNACK packet from broker
368.472: DEBUG - PKT: _sock_exact_recv: bufsize = 1
368.767: DEBUG - PKT: _sock_exact_recv: recv_len = 1
368.772: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b' ')
368.777: DEBUG - MSG: _wait_for_msg: res[0] = 0x20
368.781: DEBUG - PKT: _sock_exact_recv: bufsize = 3
368.786: DEBUG - PKT: _sock_exact_recv: recv_len = 3
368.790: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x02\x00\x00')
___ Connected to MQTT Broker!
___ Flags: 0 RC: 0
368.796: DEBUG - Resetting reconnect backoff
___ Publishing to PICO_W
Hello Broker: i am a PICO W
368.804: DEBUG - Sending PUBLISH
Topic: PICO_W
Msg: b'Hello Broker: i am a PICO W'                            
QoS: 0
Retain? False
___ Published to PICO_W with PID 0 
___ Subscribing to PICO_W/set tuning
368.816: DEBUG - SUBSCRIBING to topic PICO_W/set with QoS 0
368.822: DEBUG - Receiving SUBACK packet from broker
368.826: DEBUG - PKT: _sock_exact_recv: bufsize = 1
368.931: DEBUG - PKT: _sock_exact_recv: recv_len = 116
368.936: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x00')
Error: MQTT subscribe tuning
 negative number of bytes to read: -115
___ MQTT broker: <xxxx>.hivemq.cloud
___ mqtt_topic: PICO_W
368.945: DEBUG - waiting for messages for 0 seconds
368.950: DEBUG - PKT: _sock_exact_recv: bufsize = 1
368.955: DEBUG - PKT: _sock_exact_recv: recv_len = 4294967285
368.958: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x00')
Error: MQTT loop
 negative number of bytes to read: -4294967284
369.466: DEBUG - waiting for messages for 0 seconds
369.471: DEBUG - PKT: _sock_exact_recv: bufsize = 1
369.477: DEBUG - PKT: _sock_exact_recv: recv_len = 1
369.482: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x90')
369.487: DEBUG - MSG: _wait_for_msg: res[0] = 0x90
369.492: DEBUG - PKT: _sock_exact_recv: bufsize = 1
369.496: DEBUG - PKT: _sock_exact_recv: recv_len = 1
369.500: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x03')
369.505: DEBUG - MSG: _wait_for_msg: res[0] = 0x3
369.510: DEBUG - PKT: _sock_exact_recv: bufsize = 1
369.514: DEBUG - PKT: _sock_exact_recv: recv_len = 1
369.519: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x00')
369.523: DEBUG - MSG: Got null/zero message
370.028: DEBUG - waiting for messages for 0 seconds
370.033: DEBUG - PKT: _sock_exact_recv: bufsize = 1
370.037: DEBUG - PKT: _sock_exact_recv: recv_len = 1
370.041: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x01')
370.045: DEBUG - MSG: _wait_for_msg: res[0] = 0x1
370.051: DEBUG - PKT: _sock_exact_recv: bufsize = 1
370.055: DEBUG - PKT: _sock_exact_recv: recv_len = 1
370.059: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x00')
370.064: DEBUG - MSG: Got null/zero message
370.569: DEBUG - waiting for messages for 0 seconds
370.573: DEBUG - PKT: _sock_exact_recv: bufsize = 1
370.578: DEBUG - PKT: _sock_exact_recv: recv_len = 4294967285
370.583: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x00')
Error: MQTT loop
 negative number of bytes to read: -4294967284
371.089: DEBUG - waiting for messages for 0 seconds
371.094: DEBUG - PKT: _sock_exact_recv: bufsize = 1
371.099: DEBUG - PKT: _sock_exact_recv: recv_len = 4294967285
371.104: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x00')
Error: MQTT loop
 negative number of bytes to read: -4294967284
371.611: DEBUG - waiting for messages for 0 seconds
371.616: DEBUG - PKT: _sock_exact_recv: bufsize = 1
371.621: DEBUG - PKT: _sock_exact_recv: recv_len = 4294967285
371.625: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x00')
Error: MQTT loop

@vladak
Copy link

vladak commented Feb 17, 2023

This part of the log is telling what happened, at least on the adafruit_minimqtt level:

368.816: DEBUG - SUBSCRIBING to topic PICO_W/set with QoS 0
368.822: DEBUG - Receiving SUBACK packet from broker
368.826: DEBUG - PKT: _sock_exact_recv: bufsize = 1
368.931: DEBUG - PKT: _sock_exact_recv: recv_len = 116
368.936: DEBUG - PKT: _sock_exact_recv: rc = bytearray(b'\x00')
Error: MQTT subscribe tuning
 negative number of bytes to read: -115

This means that recv_into() was called with bufsize of 1, yet it returned 116. To me, this is clearly a core CircuitPython bug. It is probably worth noting is that there was single zero byte in the buffer which is not expected value for the SUBACK message. Reminds me of adafruit/Adafruit_CircuitPython_MiniMQTT#128. It would be interesting to see the traffic dump.

The reason why it was not visible in the old adafruit_minimqtt is that there was no check done for the recv_into() return value. The change in 645ae31393724b0b4ea2a81fb2e3c3670976e67e which introduced the 'negative number of bytes to read' exception relies on correct recv_into() behavior in order to handle partial reads. Even if there was a way how to workaround this in adafruit_minimqtt, I'd steer away from it because such workaround would have to be applied to any module using the function. Ultimately this should be handled correctly in core socket code.

@kllsamui
Copy link
Author

??? bufsize 1 is a call from the WAIT i understand??

@vladak
Copy link

vladak commented Feb 17, 2023

subscribe() prepares a SUBSCRIBE MQTT message and sends it to the broker. It then waits for the reply in the form of SUBACK MQTT message here https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/blob/342b8c99b2c8f10b605cc8311bf5f394f4d18e92/adafruit_minimqtt/adafruit_minimqtt.py#L785-L788

The _wait_for_msg() needs to read a single byte to recognize the message type. For that it uses _sock_exact_recv(): https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/blob/342b8c99b2c8f10b605cc8311bf5f394f4d18e92/adafruit_minimqtt/adafruit_minimqtt.py#L970

This means that the bufsize argument to _sock_exact_recv() will have the value of 1. _sock_exact_recv() uses recv_into() to get that single byte (bufsize = 1): https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/blob/342b8c99b2c8f10b605cc8311bf5f394f4d18e92/adafruit_minimqtt/adafruit_minimqtt.py#L1071
however recv_into() returns bigger length than requested (116) in the bufsize parameter (which is 1 in this case) which it should not.

@vladak
Copy link

vladak commented Feb 17, 2023

@dhalbert given the above I think this should be transferred back to adafruit/circuitpython.

@vladak
Copy link

vladak commented Feb 17, 2023

Also, worth noting about the logs in #7606 is that the SUBACK message is eventually received - the sequence of \x90\x03\x00\x01\x00 is clearly visible, however that happens only after the glitch of recv_into() returning the funky value with the \x00 byte. Basically, this boils down to the partial read handling undoing the changes for adafruit/Adafruit_CircuitPython_MiniMQTT#126.

Maybe _sock_exact_recv() should have similar workaround for the spurious \x00 byte as _wait_for_msg() (#126) in https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/blob/342b8c99b2c8f10b605cc8311bf5f394f4d18e92/adafruit_minimqtt/adafruit_minimqtt.py#L984 (for single byte reads only ??) however I find it dicey at best as it intersects with valid \x00 byte received. Someone should take a look at what happens in core CircuitPython and fix it there. If one cannot rely on recv_into() producing correct results, then all networking programming using it is like throwing hands in the air.

@dhalbert
Copy link
Collaborator

I see you what you mean, thanks -- transferring back.

@dhalbert dhalbert transferred this issue from adafruit/Adafruit_CircuitPython_MiniMQTT Feb 18, 2023
@dhalbert dhalbert modified the milestones: 8.1.0, 8.0.x Feb 18, 2023
@vladak
Copy link

vladak commented Feb 21, 2023

Nice work @DavePutz. For the record, the value of 115 matches MP_EINPROGRESS in circuitpython/py/mperrno.h, might be related considering the single zero byte returned from the function.

@DavePutz
Copy link
Collaborator

One mystery solved; the #define of ETIMEDOUT in /arm-none-eabi/include/sys/errno.h is 116. Now the question is whether that error should be returned to the user, or perhaps a retry in the minimqtt library, or maybe increase the default value for TLS connections from 60 in the library. @kllsamui , are you able to test with your original setup and verify that a keep_alive of 100 is sufficient?

@vladak
Copy link

vladak commented Feb 21, 2023

Cool. I think in such caserecv_into should raise an exception. The _wait_for_msg() will deal with it:

        # CPython socket module contains a timeout attribute
        if hasattr(self._socket_pool, "timeout"):
            try:
                res = self._sock_exact_recv(1)
            except self._socket_pool.timeout:
                return None
        else:  # socketpool, esp32spi
            try:
                res = self._sock_exact_recv(1)
            except OSError as error:
                if error.errno in (errno.ETIMEDOUT, errno.EAGAIN):
                    # raised by a socket timeout if 0 bytes were present
                    return None
                raise MMQTTException from error

@kllsamui
Copy link
Author

kllsamui commented Feb 22, 2023

@DavePutz
Screenshot 2023-02-22 082402

also 200 not work

@DavePutz
Copy link
Collaborator

@kllsamui , the value of 100 I used was based on the two MQTT brokers I had available to test (1 local, 1remote). Some sites could require even more time. The fix in PR #7623 should take care of the problem regardless of the keep_alive timeout.

@kllsamui
Copy link
Author

kllsamui commented Feb 22, 2023

@DavePutz

try 5000
image

so i have to test the:
?next? CP802++daily from
https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/raspberry_pi_pico_w/en_US/
( the newest NOW is 2023-02-21T22:26:38 )

or look for a new /lib/adafruit__minimqtt/ bundle?
newest NOW adafruit-circuitpython-bundle-8.x-mpy-20230221.zip


ok i try

  • nuke
  • adafruit-circuitpython-raspberry_pi_pico_w-en_US-20230222-932b10f.uf2
  • adafruit-circuitpython-bundle-8.x-mpy-20230222.zip

image

NOW IT HANGS

@kllsamui
Copy link
Author

@dhalbert
pls reopen

@kllsamui
Copy link
Author

kllsamui commented Feb 22, 2023

use 'logging' again

image

why it say INSECURE

INFO - Establishing an INSECURE connection to <xxx>.hivemq.cloud:8883

5 days ago it reported SECURE


one minute later:

700.424: INFO - MMQT error: Unable to receive 1 bytes within 60 seconds.
Error: MQTT connect
 Repeated connect failures

i try:
is_ssl=True,

like in

                broker=MQTT_broker,
                port=MQTT_port,
                username=MQTT_user,
                password=MQTT_pass,
                socket_pool=pool,
                is_ssl=True,
                ssl_context=ssl.create_default_context() #,
                #keep_alive=100 # @DavePutz 22.2.2023
            )

good

code.py output:
___ Connecting to router kll-wlan_2.4G OR CHECK THE 'settings.toml' FILE
___ Connected to kll-wlan_2.4G
___ Listening on http://192.168.1.214:80 
___+++ setup MQTT
___+++ setup MQTTclient
___++++ use TLS
___ Attempting to connect to 01d9986933e64070a549e134b27cd218.s2.eu.hivemq.cloud
1519.309: DEBUG - Attempting to connect to MQTT broker (attempt #0)
1519.313: DEBUG - Attempting to establish MQTT connection...
1519.318: INFO - Establishing a SECURE SSL connection to 01d9986933e64070a549e134b27cd218.s2.eu.hivemq.cloud:8883
1522.003: DEBUG - Sending CONNECT to broker...
1522.009: DEBUG - Fixed Header: bytearray(b'\x10.\x00')
1522.013: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
1522.023: DEBUG - Receiving CONNACK packet from broker
___ Connected to MQTT Broker!
___ Flags: 0 RC: 0
1522.352: DEBUG - Resetting reconnect backoff
___ Publishing to PICO_W
Hello Broker: i am a PICO W
1522.361: DEBUG - Sending PUBLISH
Topic: PICO_W
Msg: b'Hello Broker: i am a PICO W'                            
QoS: 0
Retain? False
___ Published to PICO_W with PID 0 
___ Subscribing to PICO_W/set tuning
1522.374: DEBUG - SUBSCRIBING to topic PICO_W/set with QoS 0
___ Subscribed to PICO_W/set with QOS level 0
___ MQTT broker: 01d9986933e64070a549e134b27cd218.s2.eu.hivemq.cloud
___ mqtt_topic: PICO_W
1523.108: DEBUG - waiting for messages for 0 seconds
1523.615: DEBUG - waiting for messages for 0 seconds
..

disable logging
good


pls find a way to help the users in case it just HANGS

@kllsamui
Copy link
Author

1615.053: DEBUG - waiting for messages for 0 seconds
1615.560: DEBUG - waiting for messages for 0 seconds
1616.066: DEBUG - waiting for messages for 0 seconds
1616.572: DEBUG - waiting for messages for 0 seconds

is meant to say 0.5 sec ?

@vladak
Copy link

vladak commented Feb 22, 2023 via email

@vladak
Copy link

vladak commented Feb 22, 2023 via email

@jepler
Copy link
Member

jepler commented Feb 22, 2023

It looks like the initial fix may have been incorrect. re-opening.

@jepler jepler reopened this Feb 22, 2023
@jepler
Copy link
Member

jepler commented Feb 22, 2023

OP's testing code
# ______________________________________________________ TEST CODE for LOCAL REMOTE broker TLS problem

import time
import microcontroller
#import micropython
#import gc # micropython garbage collection # use gc.mem_free() # use gc.collect

import os # ____________________________________________ expect file: settings.toml with:
THIS_REVISION = os.getenv('THIS_REVISION')
THIS_OS = os.getenv('THIS_OS')

WIFI_SSID = os.getenv('WIFI_SSID')
WIFI_PASSWORD = os.getenv('WIFI_PASSWORD')

WIFI_IP = os.getenv('WIFI_IP')

DIAG = True # False # ___________________________________ global print disable switch / overwritten by console [D][enter]
DIAG = bool(os.getenv('DIAG')) # ________________________ now get from settings.toml

def dp(line=" ", ende="\n"):
    if DIAG : print(line, end=ende)

import socketpool
from ipaddress import ip_address
import wifi

from adafruit_httpserver.server import HTTPServer
from adafruit_httpserver.request import HTTPRequest
from adafruit_httpserver.response import HTTPResponse
from adafruit_httpserver.methods import HTTPMethod
from adafruit_httpserver.mime_type import MIMEType

dp("___ Connecting to router {:s} OR CHECK THE 'settings.toml' FILE".format( WIFI_SSID) )
wifi.radio.set_ipv4_address( # _______________________ fixIP ( requires > CP 8.0.0 beta 4 )
    ipv4=ip_address(WIFI_IP),
    netmask=ip_address("255.0.0.0"),
    gateway=ip_address("192.168.1.1"),
    ipv4_dns=ip_address("192.168.1.1"),
)
wifi.radio.connect(WIFI_SSID, WIFI_PASSWORD)
dp("___ Connected to {:s}".format( WIFI_SSID) )

dp("___ Listening on http://{:s}:80 ".format(str(wifi.radio.ipv4_address)) )

pool = socketpool.SocketPool(wifi.radio)

# make a WEB SERVER
server = HTTPServer(pool)

HtmlStyle =   '<style>'
HtmlStyle +=   'html {font-family: "Times New Roman", Times, serif; background-color: lightgreen;'
HtmlStyle +=   'display:inline-block; margin: 0px auto; text-align: center;}'
HtmlStyle +=   'h1{color: deeppink; width: 200; word-wrap: break-word; padding: 2vh; font-size: 35px;}'
HtmlStyle +=   'p{font-size: 1.5rem; width: 200; word-wrap: break-word;}'
HtmlStyle +=   '.button{font-family: {font_family};display: inline-block;'
HtmlStyle +=   'background-color: black; border: none;'
HtmlStyle +=   'border-radius: 4px; color: white; padding: 16px 40px;'
HtmlStyle +=   'text-decoration: none; font-size: 30px; margin: 2px; cursor: pointer;}'
HtmlStyle +=   'p.dotted {margin: auto; width: 75%; font-size: 25px; text-align: center;}'
HtmlStyle +=   '</style>'

def html_index_page():
    htmldata =  '<!DOCTYPE html><html><head><title>KLL Pico W Web Server</title>'
    htmldata += HtmlStyle
    htmldata += '</head><body>'
    htmldata += '<h1>KLL Pico W Web Server</h1><h2> from Circuit Python'
    htmldata += THIS_OS + '</h2>'
    htmldata += '<img src="http://kll.engineering-news.org/kllfusion01/downloads/RPI_PICO_W.png" >'
    htmldata += '<p> image PICO W </p>'
    htmldata += '<p>  <a href="http://kll.engineering-news.org/kllfusion01/articles.php?article_id=213" target="_blank" ><b>kll.engineering-news.org</b></a> rev: '
    htmldata += THIS_REVISION
    htmldata += '</p>'
    htmldata += '</body></html>'
    return htmldata

def mqtt_connect() :
    global server, mqtt_client, mqtt_topic, MQTTok, pool, use_REMOTE_broker
    if ( True ) :
        dp("___+++ setup MQTT")
        import adafruit_minimqtt.adafruit_minimqtt as MQTT
        import json
        import ssl

        MQTTok = False
        MQTT_broker = os.getenv('MQTT_broker') # ___ RPI IP
        MQTT_port = os.getenv('MQTT_port') # __ 1883
        MQTT_user = os.getenv('MQTT_user') # _______ u213
        MQTT_pass = os.getenv('MQTT_pass') # _______ p213
        MQTT_TLS = os.getenv('MQTT_TLS') # _________ "n"
        MQTT_topic = os.getenv('MQTT_topic')

        use_REMOTE_broker = os.getenv('use_REMOTE_broker')
        if ( use_REMOTE_broker == "y" ):
            MQTT_broker = os.getenv('remote_broker') # ___ HIVEMQ
            MQTT_port = os.getenv('remote_port') # __ 8883
            MQTT_user = os.getenv('remote_user') # _______
            MQTT_pass = os.getenv('remote_pass') # _______
            MQTT_TLS = os.getenv('remote_TLS') # _________ "y"
            MQTT_topic = os.getenv('remote_topic') #

        MQTT_count = 0 # _____________________________________ send to broker as id too
        mqtt_hello="Hello Broker: i am a PICO W"
        mqtt_topic = MQTT_topic
        ### MQTT Code ###
        # Define callback methods which are called when events occur
        # pylint: disable=unused-argument, redefined-outer-name
        def connect(mqtt_client, userdata, flags, rc):
            # This function will be called when the mqtt_client is connected
            # successfully to the broker.
            dp("___ Connected to MQTT Broker!")
            dp("___ Flags: {0} RC: {1}".format(flags, rc))


        def disconnect(mqtt_client, userdata, rc):
            # This method is called when the mqtt_client disconnects
            # from the broker.
            dp("___ Disconnected from MQTT Broker!")


        def subscribe(mqtt_client, userdata, topic, granted_qos):
            # This method is called when the mqtt_client subscribes to a new feed.
            dp("___ Subscribed to {0} with QOS level {1}".format(topic, granted_qos))


        def unsubscribe(mqtt_client, userdata, topic, pid):
            # This method is called when the mqtt_client unsubscribes from a feed.
            dp("___ Unsubscribed from {0} with PID {1}".format(topic, pid))


        def publish(mqtt_client, userdata, topic, pid):
            # This method is called when the mqtt_client publishes data to a feed.
            dp("___ Published to {0} with PID {1} ".format(topic, pid))


        def message(client, topic, message):
            #global Va,Vb,Aa,Ab,Wa,Wb # here overwritten
            # Method called when a client's subscribed feed has a new value.
            dp("___ New message on topic {0}: {1}".format(topic, message))
            # here evaluate REMOT COMMANDS

        ### END MQTT functions ###


        # Set up a MiniMQTT Client !! from adafruit example NOT use client name?
        # https://docs.circuitpython.org/projects/minimqtt/en/latest/api.html
        # client_id (str) – Optional client identifier, defaults to a unique, generated string.
        dp("___+++ setup MQTTclient")
        if ( MQTT_TLS == "y" ) :
            dp("___++++ use TLS")
            mqtt_client = MQTT.MQTT(
                broker=MQTT_broker,
                port=MQTT_port,
                username=MQTT_user,
                password=MQTT_pass,
                socket_pool=pool,
                ssl_context=ssl.create_default_context()
            )
        else :
            dp("___++++ NO TLS")
            mqtt_client = MQTT.MQTT(
                broker=MQTT_broker,
                port=MQTT_port,
                username=MQTT_user,
                password=MQTT_pass,
                socket_pool=pool
                #ssl_context=ssl.create_default_context(),
            )

        # Connect callback handlers to mqtt_client
        mqtt_client.on_connect = connect
        mqtt_client.on_disconnect = disconnect
        mqtt_client.on_subscribe = subscribe
        mqtt_client.on_unsubscribe = unsubscribe
        mqtt_client.on_publish = publish
        mqtt_client.on_message = message

        try:
            dp("___ Attempting to connect to %s" % mqtt_client.broker)
            mqtt_client.connect()
            MQTTok = True # _______________________________ used later for publish
        except Exception as e:
            print("Error: MQTT connect\n", str(e))
            MQTTok = False

        try:
            dp("___ Publishing to %s" % MQTT_topic) # _____ only master topic should gets that
            dp(mqtt_hello)
            mqtt_client.publish(MQTT_topic,mqtt_hello )
            MQTTok = True # _______________________________ used later for publish
        except Exception as e:
            print("Error: MQTT publish hello\n", str(e))
            #MQTTok = False

        try:
            # setup subscribe
            mqtt_topic_tune = mqtt_topic + "/set"
            dp("___ Subscribing to %s tuning" % mqtt_topic_tune)
            mqtt_client.subscribe(mqtt_topic_tune)
        except Exception as e:
            print("Error: MQTT subscribe tuning\n", str(e))
            #MQTTok = False

        dp("___ MQTT broker: "+MQTT_broker)
        dp("___ mqtt_topic: "+mqtt_topic)


@server.route("/")
def base(request):  # pylint: disable=unused-argument
    dp("\nwifi served dynamic index.html")
    response = HTTPResponse(request)
    with response:
        response.send(body=html_index_page(), content_type=MIMEType.TYPE_HTML)

server.start(str(wifi.radio.ipv4_address)) # ______________ startup the server

mqtt_connect() # __________________________________________ above MQTT start NOTE: broker must be up first



while True :
    try:
        server.poll()
    except OSError:
        print("ERROR server poll")

    try:
        mqtt_client.loop() # ______________________________ now we see the subscribed tuning come through
    except Exception as e:
        print("Error: MQTT loop\n", str(e))
        MQTTok = False
        #time.sleep(10) # __________________________________ broker reboot expected
        #microcontroller.reset() # _________________________ try reboot case broker recovered

    time.sleep(0.5)

jepler added a commit to jepler/circuitpython that referenced this issue Feb 22, 2023
Rather than returning the negative error value.

This is intended to close adafruit#7606, though I did not test with mqtt.
Instead, I created a simple standalone test program:
```python
import wifi, socketpool, ssl, time
#wifi.radio.connect(<omitted>)
import socketpool
socket = socketpool.SocketPool(wifi.radio)
ctx = ssl.create_default_context()

b = bytearray(8)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sss = ctx.wrap_socket(s, server_hostname='example.com')
sss.connect(('example.com', 443))
sss.setblocking(False)
r = sss.recv_into(b)
print(r, b)  # prints 4294967285 which is -11 as unsigned
sss.close()
```

Before the change, r was the out of range value 4294967285. After the
change, the recv_into call raises OSError instead.

This is comparable to the behavior on standard Python, though an
SSLWantReadError is raised instead.

The original (mis)behavior seems to match what was uncovered deep inside
minimqtt by adding logging:
```
370.578: DEBUG - PKT: _sock_exact_recv: recv_len = 4294967285
```
@kllsamui
Copy link
Author

kllsamui commented Feb 23, 2023

no news, just for info:

  • nuke
  • adafruit-circuitpython-raspberry_pi_pico_w-en_US-20230222-c2c7b93.uf2
  • adafruit-circuitpython-bundle-8.x-mpy-20230223.zip

works with is_ssl=True,
HANGS without

___ Connecting to router kll-wlan_2.4G OR CHECK THE 'settings.toml' FILE
___ Connected to kll-wlan_2.4G
___ Listening on http://192.168.1.214:80 
___+++ setup MQTT
___+++ setup MQTTclient
___++++ use TLS
___ Attempting to <xxx>.hivemq.cloud

after several minutes wait see

Error: MQTT connect
 Repeated connect failures
___ Publishing to PICO_W
Hello Broker: i am a PICO W
Error: MQTT publish hello
 MiniMQTT is not connected
___ Subscribing to PICO_W/set tuning
Error: MQTT subscribe tuning
 MiniMQTT is not connected
___ MQTT broker:<xxx>hivemq.cloud
___ mqtt_topic: PICO_W
Error: MQTT loop
 Unable to receive 1 bytes within 60 seconds.
Error: MQTT loop
 MiniMQTT is not connected

with logging :

___ Connecting to router kll-wlan_2.4G OR CHECK THE 'settings.toml' FILE
___ Connected to kll-wlan_2.4G
___ Listening on http://192.168.1.214:80 
___+++ setup MQTT
___+++ setup MQTTclient
___++++ use TLS
___ Attempting to connect to <xxx>hivemq.cloud
1207.934: DEBUG - Attempting to connect to MQTT broker (attempt #0)
1207.938: DEBUG - Attempting to establish MQTT connection...
1207.943: INFO - Establishing an INSECURE connection to <xxx>.hivemq.cloud:8883
1208.250: DEBUG - Sending CONNECT to broker...
1208.254: DEBUG - Fixed Header: bytearray(b'\x10-\x00')
1208.259: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
1208.264: DEBUG - Receiving CONNACK packet from broker
1268.272: INFO - MMQT error: Unable to receive 1 bytes within 60 seconds.
1268.277: DEBUG - Reconnect timeout computed to 2.00
1268.281: DEBUG - adding jitter 0.10 to 2.00 seconds
1268.286: DEBUG - Attempting to connect to MQTT broker (attempt #1)
1268.290: DEBUG - Attempting to establish MQTT connection...
1268.293: DEBUG - Sleeping for 2.1 seconds due to connect back-off
1270.399: INFO - Establishing an INSECURE connection to <xxx>hivemq.cloud:8883
1270.707: DEBUG - Sending CONNECT to broker...
1270.711: DEBUG - Fixed Header: bytearray(b'\x10-\x00')
1270.715: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
1270.720: DEBUG - Receiving CONNACK packet from broker
1330.729: INFO - MMQT error: Unable to receive 1 bytes within 60 seconds.
1330.734: DEBUG - Reconnect timeout computed to 4.00
1330.738: DEBUG - adding jitter 0.39 to 4.00 seconds
1330.742: DEBUG - Attempting to connect to MQTT broker (attempt #2)
1330.746: DEBUG - Attempting to establish MQTT connection...
1330.750: DEBUG - Sleeping for 4.39 seconds due to connect back-off
1335.145: INFO - Establishing an INSECURE connection to <xxx>hivemq.cloud:8883
1335.453: DEBUG - Sending CONNECT to broker...
1335.458: DEBUG - Fixed Header: bytearray(b'\x10-\x00')
1335.462: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
1335.467: DEBUG - Receiving CONNACK packet from broker
1395.475: INFO - MMQT error: Unable to receive 1 bytes within 60 seconds.
1395.480: DEBUG - Reconnect timeout computed to 8.00
1395.484: DEBUG - adding jitter 0.91 to 8.00 seconds
1395.489: DEBUG - Attempting to connect to MQTT broker (attempt #3)
1395.492: DEBUG - Attempting to establish MQTT connection...
1395.497: DEBUG - Sleeping for 8.91 seconds due to connect back-off
1404.417: INFO - Establishing an INSECURE connection to 01d9986933e64070a549e134b27cd218.s2.eu.hivemq.cloud:8883
1404.723: DEBUG - Sending CONNECT to broker...
1404.728: DEBUG - Fixed Header: bytearray(b'\x10-\x00')
1404.733: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
1404.738: DEBUG - Receiving CONNACK packet from broker
1464.746: INFO - MMQT error: Unable to receive 1 bytes within 60 seconds.
1464.750: DEBUG - Reconnect timeout computed to 16.00
1464.754: DEBUG - adding jitter 0.12 to 16.00 seconds
1464.758: DEBUG - Attempting to connect to MQTT broker (attempt #4)
1464.762: DEBUG - Attempting to establish MQTT connection...
1464.766: DEBUG - Sleeping for 16.1 seconds due to connect back-off
1480.895: INFO - Establishing an INSECURE connection to 01d9986933e64070a549e134b27cd218.s2.eu.hivemq.cloud:8883
1481.201: DEBUG - Sending CONNECT to broker...
1481.206: DEBUG - Fixed Header: bytearray(b'\x10-\x00')
1481.210: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
1481.215: DEBUG - Receiving CONNACK packet from broker
1541.223: INFO - MMQT error: Unable to receive 1 bytes within 60 seconds.
Error: MQTT connect
 Repeated connect failures
___ Publishing to PICO_W
Hello Broker: i am a PICO W
Error: MQTT publish hello
 MiniMQTT is not connected
___ Subscribing to PICO_W/set tuning
Error: MQTT subscribe tuning
 MiniMQTT is not connected
___ MQTT broker: 01d9986933e64070a549e134b27cd218.s2.eu.hivemq.cloud
___ mqtt_topic: PICO_W
1541.238: DEBUG - waiting for messages for 0 seconds
Error: MQTT loop
 Unable to receive 1 bytes within 60 seconds.
1601.748: DEBUG - waiting for messages for 0 seconds
1601.751: DEBUG - KeepAlive period elapsed - requesting a PINGRESP from the server...
Error: MQTT loop
 MiniMQTT is not connected
1602.259: DEBUG - waiting for messages for 0 seconds
Error: MQTT loop
 Unable to receive 1 bytes within 60 seconds.
1662.770: DEBUG - waiting for messages for 0 seconds
1662.774: DEBUG - KeepAlive period elapsed - requesting a PINGRESP from the server...
Error: MQTT loop
 MiniMQTT is not connected
1663.282: DEBUG - waiting for messages for 0 seconds

does not the broker send a info that the login failed / connection was refused / ?

so here again WITH is_ssl = True and logging

___ Connecting to router kll-wlan_2.4G OR CHECK THE 'settings.toml' FILE
___ Connected to kll-wlan_2.4G
___ Listening on http://192.168.1.214:80 
___+++ setup MQTT
___+++ setup MQTTclient
___++++ use TLS
___ Attempting to connect to <xxx>hivemq.cloud
2641.719: DEBUG - Attempting to connect to MQTT broker (attempt #0)
2641.723: DEBUG - Attempting to establish MQTT connection...
2641.728: INFO - Establishing a SECURE SSL connection to <xxx>hivemq.cloud:8883
2645.262: DEBUG - Sending CONNECT to broker...
2645.268: DEBUG - Fixed Header: bytearray(b'\x10.\x00')
2645.272: DEBUG - Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
2645.282: DEBUG - Receiving CONNACK packet from broker
___ Connected to MQTT Broker!
___ Flags: 0 RC: 0
2645.850: DEBUG - Resetting reconnect backoff
___ Publishing to PICO_W
Hello Broker: i am a PICO W
2645.857: DEBUG - Sending PUBLISH
Topic: PICO_W
Msg: b'Hello Broker: i am a PICO W'                            
QoS: 0
Retain? False
___ Published to PICO_W with PID 0 
___ Subscribing to PICO_W/set tuning
2645.873: DEBUG - SUBSCRIBING to topic PICO_W/set with QoS 0
___ Subscribed to PICO_W/set with QOS level 0
___ MQTT broker:<xxx>hivemq.cloud
___ mqtt_topic: PICO_W
2646.419: DEBUG - waiting for messages for 0 seconds
2646.925: DEBUG - waiting for messages for 0 seconds
2647.433: DEBUG - waiting for messages for 0 seconds

pls see that actually in booth cases there is a

Receiving CONNACK packet from broker

i am confused, it seems like a "lost in translation"

@dhalbert
Copy link
Collaborator

We believe this is fixed by #7632.

@jepler
Copy link
Member

jepler commented Feb 23, 2023

from what I can see, hivemq only offers mqtt over tls (what we call is_ssl=True). It's no surprise if they can't successfully communicate when one side is expecting TLS and the other is expecting plaintext.

image

@jepler
Copy link
Member

jepler commented Feb 23, 2023

Port 1883 is allocated for non-secure MQTT. However, hivemq machines do not respond on port 1883. I think that non-TLS (use_ssl=False) is not supported by hivemq.

jepler added a commit to jepler/circuitpython that referenced this issue Mar 22, 2023
This reverts commit 7e6e824.

Fixes adafruit#7770

The change in adafruit#7623 needs to be revered; the raise-site added in adafruit#7632
is the correct one and the one in socketpool needs to be reverted.

This is not affecting 8.0.x because adafruit#7623 was not back-ported to there
before we realized it was not a full fix.

Both adafruit#7770 and adafruit#7606 should be re-tested. I didn't test.
@berarduc
Copy link

Has this issue been fixed? I'm using latest 8.2 circuitpython and minimqtt library and this problem still occurs.

@vladak
Copy link

vladak commented Jul 14, 2023

Has this issue been fixed? I'm using latest 8.2 circuitpython and minimqtt library and this problem still occurs.

This issue is closed, so it would be better to open new one, describe your problem in detail and reference this issue.

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

Successfully merging a pull request may close this issue.

6 participants