-
Notifications
You must be signed in to change notification settings - Fork 1k
umqtt.simple's check_msg triggers OSError -1 with TLS servers #363
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
Comments
Same here (ESP8266 and MicroPython 1.12). When change SSL to noSSL connection, works fine. |
I too have this issue using a ublox modem and AWS over TLS. Are there any workarounds? |
Same problem, in ESP32 it works perfectly but in ESP8266 it doesn't. |
there seems to be some kind of problem when the ssl socket is set to nonblocking and it occasionally returns b"" which results in the OSError(-1). Ignoring it did not help. to work around the problem I created a poll object after the ssl_wrap and in check_msg() I check the poll object instead of mucking around with setblocking(True/False). YMMV / workaround / not an optimal solution, but it works for me simple.py
and comment out the #self.sock.setblocking(True) in get_msg() |
try to fix it with modified uqmtt lib following micropython/micropython-lib#363 (comment)
According to my test, the problem does not occur because of SSL. The problem is because the server's waiting time is over according to the keepalive=??? My solution is to add a timer that PINGs the server before the keepalive time expires. This solves the problem. Here is a sample code to solve the problem:
|
Please consider this code:
It systematically gives the same output (and I can reproduce it with another broker e.g. AWS IoT)
What's strange is that if I use port 1883 and ssl=False (i.e. no encryption), the same code works.
I reproduced this issue on my Mac (MicroPython 1.11) and on my ESP8266 board (MicroPython 1.12).
Looping over
mqtt.wait_msg()
works like a charm, so I suspect switching back and forth a TLS socket from blocking to non-blocking generates such error.The text was updated successfully, but these errors were encountered: