Modul PRESENCE killt SSL-Connections

[buennerbernd]

Hallo,

Ich habe ein Modul geschrieben,  das über DevIo eine SSL Verbindung zur Velux Box KLF200 aufbaut.
Leider wird das Modul unbrauchbar, wenn gleichzeitig das Modul Presence läuft. Die SSL Verbindung bricht schnell wieder ab.
Siehe https://forum.fhem.de/index.php/topic,92907.msg868921.html#msg868921

Scheinbar bin ich nicht der einzige mit diesem Problem:
https://forum.fhem.de/index.php/topic,60393.msg517807.html#msg517807

Wenn das Modul Presence nicht parallel läuft, habe ich diese Probleme nicht.

Hat da jemand einen Tipp?

Danke, Stefan.

[Markus Bloch]

Hallo Stefan,

es gibt hierbei 2 Probleme die etwas unterschiedlicher Art sind.

PRESENCE nutzt das Modul Blocking.pm um die Check-Aufrufe vom Hauptprozess zu entkoppeln. Dabei verwendet Blocking.pm intern Forks um einen Kindprozess zu öffnen in dem dann der Check läuft. Wenn so ein Kindprozess geöffnet wird, werden auch alle offenen TCP-Verbindungen/Serial-Verbindungen mit in diesen Kindprozess "kopiert". Daher wird als aller erstes alle kopierten Verbindungen im Kindprozess geschlossen, damit keine Nachrichten ungewollt bei dem Kindprozess landen und damit nicht mehr an den Hauptprozess geht, der die Nachricht eigentlich bräuchte. Also werden zu Beginn sämtliche Verbindungen geschlossen. Das funktioniert bei normalen TCP- und Serial-Verbindungen problemlos. Bei SSL-Verbindungen geht dieses jedoch so einfach nicht, da das zugrundeliegende Modul IO::Socket:SSL nicht "fork"-kompatibel ist. Wenn man also in einem Kindprozess eine SSL-Verbindung schließt wird auch die Verbindung im Hauptprozess in Mitleidenschaft gezogen (aus Sicherheitsgründen), da bestimmte Zustandsdaten nicht sauber an den Kindprozess vererbt werden. Bisher ist mir zumindest kein Modul untergekommen, was eine dauerhafte SSL-Verbindung nutzt, daher hatte ich dieses Problem noch garnicht.

Ich würde daher vorschlagen mal folgende Änderung in der Funktion fhemFork() in fhem.pl Zeile in 5334 bei Dir auszuprobieren:

alt:

Code (fhem.pl ab Zeile 5334) Auswählen Erweitern

    if($h->{DeviceName}) {
      require "$attr{global}{modpath}/FHEM/DevIo.pm";
      DevIo_CloseDev($h,1);
    }
neu:

Code (fhem.pl ab Zeile 5334) Auswählen Erweitern

    if($h->{DeviceName} && !$h->{SSL}) {
      require "$attr{global}{modpath}/FHEM/DevIo.pm";
      DevIo_CloseDev($h,1);
    }

Das setzt jedoch vorraus, dass die SSL-Verbindung mit DevIo und dem SSL-Flag aufgebaut wurde. Bei dem Websocket_Client Modul bspw. ist das nicht der Fall. Bei KLF200 ist richtig implementiert. Eine Doku führ Modulentwickler zu DevIo gibt es unter https://wiki.fhem.de/wiki/DevIo

Probier mal die Änderungen bitte aus, ob das Problem dadurch weggeht.

Vielen Dank

Gruß
Markus

[buennerbernd]

Danke für die die Antwort.
Das Forken hatte ich auch im Verdacht.

Ich werde das mal ausprobieren.
Ist das &amp im Code richtig oder wurde das irgendwie umgewandelt?

Gruß, Stefan.

[Markus Bloch]

Also bei mir ist kein &amp zu sehen.

Gruß
Markus

[buennerbernd]

Dachte ich mir es doch. In Tapatalk sieht es anders aus.

Bin gespannt, ob es hilft.

[santa0912]

Hallo zusammen,

ich habe, wie von buennerbernd und in dem anderen Thread https://forum.fhem.de/index.php/topic,92907.0.html bereits geschrieben, ebenfalls das Problem beim KLF200.

Ich habe die Änderung von Markus Bloch in der fhem.pl ausprobiert.

Code Auswählen Erweitern

    if($h->{DeviceName} && !$h->{SSL}) {
      require "$attr{global}{modpath}/FHEM/DevIo.pm";
      DevIo_CloseDev($h,1);
    }

Leider bricht auch hier nach 10min. die Verbindung zw. FHEM und KLF200 ab, wenn PRESENCE läuft.
Wird PRESENCE nicht genutzt, läuft es.

Code Auswählen Erweitern

2018.12.16 20:26:26 3: Velux device opened
2018.12.16 20:26:27 1: KLF200 (Velux) - connectionBroken -> reboot started, reconnect in 30 seconds
2018.12.16 20:26:56 1: 192.168.178.91:51200 reappeared (Velux)
2018.12.16 20:26:57 1: KLF200 (Velux) - ignored:  02030003
2018.12.16 20:26:57 1: KLF200 (Velux) - ignored:  0101
2018.12.16 20:36:57 5: KLF200 (Velux) GW_GET_STATE_REQ
2018.12.16 20:36:57 5: KLF200 Velux: unwrapped bytes     000c
2018.12.16 20:36:57 5: KLF200 Velux: wrapped bytes c00003000c0fc0
2018.12.16 20:36:57 1: 192.168.178.91:51200 disconnected, waiting to reappear (Velux)
2018.12.16 20:36:57 5: HttpUtils url=https://192.168.178.91:51200/
2018.12.16 20:36:57 4: IP: 192.168.178.91 -> 192.168.178.91
2018.12.16 20:37:17 4: HttpUtils: https://192.168.178.91:51200/: Can't connect(2) to https://192.168.178.91:51200:  SSL wants a read first
2018.12.16 20:37:17 5: KLF200 (Velux) - error while connecting: https://192.168.178.91:51200/: Can't connect(2) to https://192.168.178.91:51200:  SSL wants a read first
2018.12.16 20:37:17 1: KLF200 (Velux) - connectionBroken -> closed connection

...just my 2 cents...



Viele GRüße,

Claus

[buennerbernd]

Hallo Markus,

Danke nochmals für die Erläuterungen. Sie haben mir geholfen, das Problem zu verstehen.

Nachdem ich hier heute schon kurz geposted hatte, dass dein Tipp nicht funktioniert, hatte ich noch einen kleinen Fehler bemerkt und bin zu folgender Lösung gekommen:

Ich habe jetzt nicht die fhem.pl manipuliert, sondern die DevIo.pm:

Bei etwa Zeile 500 habe ich jetzt:

Code Auswählen Erweitern


sub
DevIo_CloseDev($@)
{
  my ($hash,$isFork) = @_;
  my $name = $hash->{NAME};
  my $dev = $hash->{DeviceName};

  return if(!$dev);
 
  if($hash->{TCPDev}) {
    if($isFork && $hash->{SSL}) {
      $hash->{TCPDev}->close(SSL_no_shutdown => 1);
    } else {
      $hash->{TCPDev}->close();
    }
    delete($hash->{TCPDev});

  } elsif($hash->{USBDev}) {


Es scheint so, als ob meine SSL-Verbindung jetzt gegen die blocking calls resistent ist.
Das wäre eine wirklich kleine Änderung, die in DevIo.pm rein muss.

Gruß, Stefan.

[rudolfkoenig]

Ich habe die o.g. Aenderungen in DevIo.pm eingecheckt.

[Markus Bloch]

Danke Rudi

[buennerbernd]

Ich habe gerade ein FHEM-update gemacht und eine Version von DevIo.pm vom 7. November erhalten.

Code Auswählen Erweitern

# $Id: DevIo.pm 17702 2018-11-07 19:02:28Z rudolfkoenig $

Dauert das noch?

Gruß, Stefan.

[Markus Bloch]

Gibts erst morgen via update, da es Rudi heute eingecheckt hat (Karenzzeit falls andere Developer/Tester gravierende Seiteneffekte feststellen.

Gruß
Markus

[buennerbernd]

Danke für's einchecken. Es läuft!

Ich würde das Thema als "gelöst" betrachten.

Gruß, Stefan.