Ankündigung

Einklappen
Keine Ankündigung bisher.

Mal wieder "Websocket error undefined"

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Mal wieder "Websocket error undefined"

    Hallo,

    vorweg: shNG/sV laufen seit langem bei mir stabil in einer zentralen Debian-VM auf dem NAS (QNAP). In der gleichen VM liegt auch eine nextCloud-Installation, die unseren Kalender enthält. Diese nextCloud-Installation mault seit Ewigkeiten beim Selbstcheck, ich solle doch gefälligst ein Zertifikat installieren und auf https wechseln. Also hab ich mich mal drauf eingelassen.

    Nach Installation des selbst ausgestellten Zertifikats wurden zwar noch die SV-Seiten dargestellt, aber keine Daten mehr durch shNG angeliefert. Nach einigen Sekunden erschien immer das rote ERROR-Warndreieck rechts oben mit der Meldung

    Driver: smarthome.py
    Could not connect to smarthome.py server!
    Websocket error undefined.
    Die sV-eigenen Plugins (nextCloud, Fritzbox) erhielten aber nach wie vor ihre Daten.

    Da Chrome und Firefox auf https bestehen, war ein testweises Fallback auf http dort nicht möglich. http ging aber sehr wohl in Edge, in dem die Visu dann auch ordnungsgemäß mit allen shNG-Daten angezeigt wurde.

    Die Chrome-Konsole hat auf ein Problem in driver/io_smarthome.py.js in Zeile 115 verwiesen:
    Code:
    protocol = location.protocol === 'https:' ? 'wss://' : 'ws://';
    Nach einer temporären Änderung in
    Code:
    protocol = location.protocol === 'https:' ? 'ws://' : 'ws://';
    lädt Chrome alle Daten wieder ordnungsgemäß. Offensichtlich gibt es also ein Kommunikationsproblem mit shNG bei der Verwendung von wss://.

    Es werden zwar in der Konsole zwei Warnungen ausgegeben:
    io_smarthome.py.js:130 Mixed Content: The page at 'https://192.168.178.7/smartvisu/index.php?page=heizung' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://192.168.178.7:2424/'. This endpoint should be available via WSS. Insecure access is deprecated.

    io_smarthome.py.js:130 Connecting to a non-secure WebSocket server from a secure origin is deprecated.
    Es ist also fraglich, wie lange noch ('deprecated') - aber es läuft. Auch dauert es jetzt ca. 30s, bis erste Daten von shNG angeliefert werden (Eieruhr), vorher kamen die immer gleich.

    Ist das ein Fehler auf der Treiberseite von sV/shNG, oder liegt hier ein anderes Problem vor? Nach meinem Verständnis haben ja eigentlich Websockets mit einem Zertifikat für den http-Webserver (Apache) eher wenig zu tun, oder? Hat hier jemand die Kombi shNG/sV mit installiertem (selbstausgestellten) Zertifikat erfolgreich am Laufen?

    /tom

    ps: Ich bin weder ein https-/Zertifikatsexperte (der ganze Krimskrams geht mir sogar auf die Nerven), noch bin ich mir sicher, ob das Thema in shNG nicht vielleicht besser aufgehoben wäre. Oder ob es sogar ein Konfigurationsproblem des Webservers bzw. Betriebssystems ist. Auch gibt es hier im Forum über die Jahre verteilt mehrere Threads zu genau diesem Fehlerbild; aber keinen einzigen mit einer Lösung (selbst Marcus/Callidomus hatte dann irgendwann aufgegeben). Danke also für neue Lösungsansätze!

    #2
    Nachtrag: Der konkrete Fehler im Browser bei Verwendung von wss lautet:

    io_smarthome.py.js:130 WebSocket connection to 'wss://192.168.178.7:2424/' failed: WebSocket opening handshake timed out
    /tom

    Kommentar


      #3
      Nächster Nachtrag: Diese Fehlermeldungen sind im shNG-Log zu finden (Log ist der Lesbarkeit halber gekürzt und formatiert). Jedes Mal, wenn die sV eine Kommunikation über den Websocket aufbauen will, wird ein UTF8-Fehler geworfen. Ist es vielleicht ein Zeichensatzproblem?

      Code:
      2020-04-03 19:32:39 ERROR plugins.visu_websocket _websocket.json_parse exception: 'utf-8' codec can't decode byte 0x80 in position 3: invalid start byte
      Traceback (most recent call last):
      File "/usr/local/smarthome/plugins/visu_websocket/__init__.py", line 838, in rfc6455_parse
      self.json_parse(payload.decode())
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 3: invalid start byte
      
      2020-04-03 19:45:34'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      
      2020-04-03 19:47:04'utf-8' codec can't decode byte 0x8a in position 2: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 2: invalid start byte
      
      2020-04-03 19:56:34'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      
      2020-04-03 20:08:34'utf-8' codec can't decode byte 0xb3 in position 0: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb3 in position 0: invalid start byte
      
      2020-04-03 20:11:34'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      
      2020-04-03 20:12:17'utf-8' codec can't decode byte 0xd2 in position 0: invalid continuation byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd2 in position 0: invalid continuation byte
      
      2020-04-03 20:12:17'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte
      
      2020-04-03 20:12:17'utf-8' codec can't decode byte 0xc7 in position 1: invalid continuation byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc7 in position 1: invalid continuation byte
      
      2020-04-03 20:13:39'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      
      2020-04-03 20:20:37'utf-8' codec can't decode byte 0x8a in position 2: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 2: invalid start byte
      
      2020-04-03 20:21:36'utf-8' codec can't decode byte 0x8a in position 1: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 1: invalid start byte
      
      2020-04-03 20:23:35'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      
      2020-04-03 20:34:36'utf-8' codec can't decode byte 0xd1 in position 3: invalid continuation byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd1 in position 3: invalid continuation byte
      
      2020-04-03 20:41:36'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
      
      2020-04-03 20:50:05'utf-8' codec can't decode byte 0xa0 in position 2: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 2: invalid start byte
      
      2020-04-03 20:50:36'utf-8' codec can't decode byte 0x85 in position 0: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x85 in position 0: invalid start byte
      
      2020-04-03 20:59:35'utf-8' codec can't decode byte 0x88 in position 1: invalid start byte
      UnicodeDecodeError: 'utf-8' codec can't decode byte 0x88 in position 1: invalid start byte
      /tom

      Kommentar


        #4
        Zitat von Tom Bombadil Beitrag anzeigen
        Offensichtlich gibt es also ein Kommunikationsproblem mit shNG bei der Verwendung von wss://.
        Hast Du denn in SmartHomeNG Zertifikate hinterlegt? Ich selber die Verbindung noch nie per wss probiert, aber bei einem Blick in den Code des visu_websocket Plugins sieht es so aus, als würde es wss beherschen (wenn man tls und Zertifikate kondiguriert hat).
        Viele Grüße
        Martin

        There is no cloud. It's only someone else's computer.

        Kommentar


          #5
          Die Verbindung auf wss wird ja automatisch aktiviert, sobald auf dem Server ein Zertifikat eingespielt wird; da kann man meines Wissens mit "normalen Mitteln" nichts händisch beeinflussen. Irgendwelche Zertifikate habe ich daher auch nur gemäß Anleitung eingespielt; nach meinem Laienwissen also nur für den Apache.

          Wie geschrieben - alle anderen Systeme liefen ja auch auf Anhieb, inkl. Backend/Admin-Interface von shNG, die sV, NextCloud usw. Der NextCloud "System check" hat auch ganz stolz "Keine Fehler oder Probleme" gemeldet. Nur der Websocket zwischen shNG und sV wird nicht aufgebaut. Manuelles Fallback durch den bösen 'Hack' (siehe oben) in der io_smarthome.js bringt dann auch den Websocket wieder hoch.

          Ich habe jetzt hoffentlich den richtigen Schalter gefunden, um SSL global wieder auszuschalten (Datei /etc/apache2/ssl/1, SSLEngine on --> off, danach service apache2 restart). Dann heult zwar NextCloud wieder rum, aber zumindest läuft die sV wieder auf allen Geräten. Wenn alles wieder ok sein sollte, fasse ich diesen ganzen Zertifikatsquatsch / SSL usw in den nächsten 1.000 Jahren ganz sicher nicht wieder an. Dieser ganze Blödsinn ist nix weiter als eine Arbeitsbeschäftigungsmaßnahme ...

          /tom

          Kommentar


            #6
            Da SmartHomeNG nicht unter Apache läuft, kann es auch nicht auf die dort eingespielten Zertifikate zugreifen. Siehe auch hier in der Config-Doku zum Plugin: http://www.smarthomeng.de/user/plugi...ght=zertifikat
            Viele Grüße
            Martin

            There is no cloud. It's only someone else's computer.

            Kommentar


              #7
              Ja, den Hinweis hatte ich gelesen. Nun ist ja aber das gute alte TLS nicht zwingend das gleiche wie SSL.

              Auch finde ich nach den Installation im SSL-Verzeichnis des Apache zwar eine apache.crt und eine apache.key, aber keine ca.crt.

              Am Rande: Die Beispieldaten in der plugin.yaml.default scheinen auch noch einen Fehler aus alten Zeiten zu enthalten:
              Code:
              websocket:
                  plugin_name: visu_websocket
                  #ip: 0.0.0.0
                  #port: 2424
                  #tls: no
                  #wsproto: 4
                  #acl: rw
              Da tls gemäß Doku und gemäß plugin.yaml im Plugin-Verzeichnis ein boolscher Wert ist, müsste hier nach meinem Verständnis False/True und nicht no/yes verwendet werden.

              Das ganze finde ich zumindest mittelprächtig verwirrend. Daher hatte ich ja auch eingangs gefragt, ob überhaupt schon jemand sowas am Laufen hat ...

              /tom

              Kommentar


                #8
                Wie ich schrieb, habe ich das noch nie mit wss genutzt. Das ist noch die selbe Implementation wie schon im alten smarthome.py. Du kannst im SmartHomeNG Forum ja mal fragen ob jemand das Websocket Plugin mit wss nutzt. (Ich kenne keinen).

                Ich habe das in der plugin.yaml.default mal auf tls: False geändert.
                Viele Grüße
                Martin

                There is no cloud. It's only someone else's computer.

                Kommentar


                  #9
                  Ja, ich war mir ja auch nicht sicher, wo die Ursache liegt und hatte dann das sV-Forum gewählt, da der Fehler hier offensichtlich auftritt (wie eingangs geschrieben). Und hatte bei der Recherche gleich mehrere Threads mit genau diesem Fehlerbild gefunden - aber keinen mit einer Lösung.

                  Mittlerweile wird das Bild etwas klarer.

                  Im Grunde müßte der Treiber der sV einen Parameter "force_ws_instead_of_wss: False/True' für den mixed Mode bekommen, der bei https:// im Websocket trotzdem ws:// statt wss:// benutzt. Kann mich ja mal dranmachen, wenn gewünscht - die richtige Stelle hab ich ja eh schon am Wickel, und mehr als ein Dreizeiler plus ein neuer Parameter in der Config-Datei dürfte es eigentlich nicht sein.

                  Allerdings dürfte solch ein Fix nur temporärer Natur sein, da zumindest Chrome und FF bereits Deprecated-Warnungen schmeißen, wenn man 'mixed Mode' fährt. Besser wäre vermutlich ein klare Dokumentation, wie man SSL unter shNG einrichtet, und wo die dafür benötigten Daten/Dateien auf dem Webserver rumlungern. Das bringt dann aber auch regelmäßige (doppelte) Zertifikatsupdates mit sich - 1x Webserver, 1x separat in shNG. Die meisten freien Zertifikaten sind nur 3 Monate gültig...

                  /tom

                  Kommentar


                    #10
                    Das ist der Grund warum ich in meinem privaten Netz auch die Visu ohne https fahre.
                    Viele Grüße
                    Martin

                    There is no cloud. It's only someone else's computer.

                    Kommentar


                      #11
                      Zitat von Tom Bombadil Beitrag anzeigen
                      Im Grunde müßte der Treiber der sV einen Parameter "force_ws_instead_of_wss: False/True' für den mixed Mode bekommen, der bei https:// im Websocket trotzdem ws:// statt wss:// benutzt. Kann mich ja mal dranmachen, wenn gewünscht - die richtige Stelle hab ich ja eh schon am Wickel, und mehr als ein Dreizeiler plus ein neuer Parameter in der Config-Datei dürfte es eigentlich nicht sein.
                      Ich antworte mir mal selbst:

                      driver/io_smarthome.py.js ab Zeile 111:
                      Code:
                      var protocol = '';
                      if (!io.address || io.address.indexOf('://') < 0) {
                        // adopt websocket security to current protocol (https -> wss and http -> ws)
                        // if the protocol should be forced, add it to the address
                        protocol = location.protocol === 'https:' ? 'wss://' : 'ws://';
                        if (!io.address) {
                          // use url of current page if not defined
                          io.address = location.hostname;
                        }
                      [...]
                      }
                      So wie ich das interpretiere, muss man also nur in der config.ini statt driver_address="192.168.178.7" die Angabe driver_address="ws://192.168.178.7" machen, und der mixed Mode wird eingeschaltet. Hab's aber mangels Zertifikats-Nerven nicht ausprobiert.

                      /tom

                      Kommentar


                        #12
                        Hi bist Du schon weitergekommen?

                        Ich bin gerade ein wenig verwirrt mit dem ganzen Sicherheits gedönse.
                        Wenn ich über den reverse proxy mit https zugreife geht die VISU ohne Probleme (ohne Zertifikate zu installieren) auf --> nur die Wegsacket Verbindung klappt nicht.
                        Wenn ich intern im Netz bin kann ich die VISU nicht mal mit https aufmachen geht nur mit http deshalb weiß ich gerade nicht ob nur die Zertifikate das Problem sind.

                        Kommentar


                          #13
                          Nein - ich konnte glücklicherweise alles wieder einigermaßen 'zurückbiegen', die Visu funktionierte dann wieder auf allen meinen Geräten. Die ganze (am Ende erfolglose) Spielerei hat mich mehrere Tage und jede Menge Nerven gekostet, das fasse ich ohne Zwang ganz sicher nicht nochmal an ...
                          /tom

                          Kommentar

                          Lädt...
                          X