FHEM - Entwicklung > FHEM Development

SSL wants a read first

(1/3) > >>

Prof. Dr. Peter Henning:
Liebe Mitstreiter,

Erstmal Beschreibung der Symptome.

2 fast identische Staubsaugerroboter von Roomba. Besonderheit: Roomba baut dort einen MQTT-Server ein, der Zugriff von außen muss also über einen MQTT-Client erfolgen. Geht soweit, beide liefen damit astrein.

Dann ein Komplett-Reset des einen Roomba. Das gibt natürlich ein neues Passwort, soweit, so gut. Alles eingetragen, Verbindungsversuch endet mit einer Fehlermeldung der HttpUtils:


--- Zitat ---2021.04.26 17:16:51 4: IP: 192.168.0.xx -> 192.168.0.xx
2021.04.26 17:16:54 4: HttpUtils: https://192.168.0.xx:8883/: Can't connect(2) to https://192.168.0.xx:8883:  SSL wants a read first
--- Ende Zitat ---
Das Attribut sslargs hat den Wert SSL_version:SSLv23 und die Verbindung des zweiten MQTT-Client mit dem zweiten Roboter läuft problemlos. Es kann also nicht an den SSL-Einstellungen liegen.

Die Perl-Module sind soweit alle aktualisiert - und ich stehe vor einem Rätsel.

Natürlich bemühe ich brav die Suchfunktion und finde ganz viele FHEM-Posts mit der gleichen Problembeschreibung. Mal löst sich das Problem durch Update der Perl-Module. Mal verschwindet es von alleine. Und mal gar nicht.

So etwas finde ich unbefriedigend - hat jemand einen Schimmer, wie ich da herauskommen kann und was die systematische Lösung für dieses Problem ist?

LG

pah

herrmannj:
Das ist entweder ein Fehler in IO::Socket:SSL (oder ..IP), kann aber auch unglücklich auftreten wenn geforked wird.

Beim SSL Handshake kann es passieren das perl (du) Nutzdaten schreiben möchte, die darunter liegende (transparente) SSL Verbindung aber etwas lesen muss was mit den SSL Handshake zu tun hat.

Forkst Du für den roomba? Wenn ja, versuch mal interimsweise ohne fork auszukommen (falls möglich). Die sich abzeichnende Frage ;) wäre danch: was dann? Falls es wirklich an dem forken liegt wäre eine Möglichkeit die Verbindung komplett im fork aufzubauen (also kein handle dieser Verbindung in den fork "rüber" zu nehmen)

Prof. Dr. Peter Henning:
Zunächst einmal habe ich das nicht im Zugriff, weil der Aufruf der HttpUtils aus MQTT2_DEVICE heraus erfolgt. Vlt. muss ich mal Rudi ansprechen.
Und warum es bei der einen Kiste geht, und bei der anderen nicht, ist mir beliebig unklar.

LG


pah


Edit: ich kriege Schreikrämpfe: Nach dem Update der Perl-Module funktioniert das Connect auch nicht mehr mit dem 2. Roboter. Und da gibt es noch nicht mal eine Fehlermeldung....

rudolfkoenig:
Ich gehe davon aus, dass hier kein fork involviert ist, MQTT_CLIENT (bzw. => DevIo => HttpUtils_Connect) macht sowas nicht.
Da nach der TCP connect sofort IO::Socket::SSL->start_SSL aufgerufen wird, duerfte sich auch kein fork eines anderes Moduls sich dazwischendraengeln.

Vor start_SSL wird $hash->{conn}->blocking(1) gesetzt, mAn darf start_SSL deswegen nicht "want a read first" melden => Ich meine das ist ein Bug im IO::Socket::SSL bzw. darunter.

Als workaround koennte HttpUtils start_SSL nonblocking durchfuehren, und "want a read" / "want a write" so lange auswerten, bis das SSL-Handshake fertig ist. Trau mich noch nicht das anzugehen, da die Aendrung signifikant ist, und viele Module indirekt betrifft.
Vermutlich brauche ich Ermunterung :)

Prof. Dr. Peter Henning:
Meinst Du so etwas? ;D

LG

pah

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln