Fehler: Handshake failed with Client-ID 1

[steffen79]

Moin,

haben eigentlich noch andere das Problem, dass immer wieder Fehler wie
VISU 5723 Handshake failed with Client-ID 1
im Log auftauchen?

Liegt das an der Websocket-Schnittstelle die undefiniert beendet wird, wenn ich meine IPhone-Visu öfter mal auf und zu mache?

Wird das in 1.53 behoben bzw. kann man dann zumindest den Fehler verstecken damit der nicht immer rot aufleuchtet?

Gruß,
Steffen

[michaeldamm2]

Habe den Fehler auch drinnen!

[gaert]

Der Fehler bedeutet, dass der Handshake nicht korrekt geklappt hat. Näheres weiß ich natürlich auch nicht Ich hatte dieses Fehler noch nie, trotz zig gleichzeitiger Instanzen etc. während meiner Tests...

Fehler zu "verstecken" halte ich für irreführend - schließlich ist es ein Fehler mit irgendeiner Ursache.

[Winni]

Nur zur Info: Musste nach einem solchen Fehler EDOMI neu starten, bin zwar noch auf die Admin Seite gekommen, die Visu war nicht mehr erreichbar. Ist aber bisher nur einmal aufgetreten.

[gaert]

Sehr merkwürdig... Der Visu-Prozess sollte eigentlich unbeeindruckt weiterlaufen - habe ich x-mal getestet und ist auch logisch (intern).

[maque]

Guten Abend zusammen,

vielleicht ein Hinweis: Ich bekomme diese Meldung "VISU 1936 Handshake failed with Client-ID 0 ERROR" alle 3 Sekunden in mein Syslog, sowie ich versuche die Visu -Seite mit https aufzurufen und mit einem Account anzumelden.
Die Admin Seite läuft mit https einwandfrei, auf die Visu komme ich bis zur Anmeldung aber nicht mehr weiter. Die Zertifikate werden vom Browser korrekt erkannt.

Gruesse
Matthias

[WWebber]

Bei mir kommen diese Meldungen auch "sporadisch regelmäßig". Ich habe aber gar keinen Client drauf hängen. Im MessageLog stehen zu diesen Zeitpunkten nur die SekundenTick Meldung. Aufs Internet kann mein edomi Rechner auch nicht - d.h. alles läuft nur lokal ab.

Mit wem will edomi da was handshaken und warum kommt diese Meldung eigentlich nicht regelmäßig? Welches "Tool" könnte ich bemühen, um das rauszufinden?

2018-03-17 22:28:53    495239    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-17 23:04:37    109812    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-17 23:24:39    272633    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-18 01:18:49    024611    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-18 03:44:20    436316    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-18 03:44:20    801639    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-18 03:44:21    167542    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-18 03:44:21    534869    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-18 04:20:28    592993    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-18 07:40:25    350707    VISU    32052    Handshake failed with Client-ID 0    ERROR
2018-03-18 07:40:26    103282    VISU    32052    Handshake failed with Client-ID 0    ERROR

[saegefisch]

Habe sehr sporadisch diese Meldungen auch schon gesehen; just heute Nacht eine.

In der Fehlermeldung: Ist die Client-ID die ID des Visuaccounts oder die Visu-ID? Oder ist dies eine von php/websocket generiert ID, die keinen Bezug zu edomi hat?

[jonofe]

Habt ihr evtl. eine Weiterleitung von einem Reverse Proxy auf Port 8080 des EDOMI Servers. (EDOMI Websocket)
Evtl. passiert dies, wenn irgendein potenzieller Anǵreifer den Port 8080 des DSL Routers scannt.

[saegefisch]

Habe ich in der Tat im Einsatz. Aber ohne Client Certificate kommt ein Angreifer ja nicht einmal in die Nähe von edomi, sondern prallt schon am RevProxy ab.
Aber ein guter HInweis...werde mal das NGINX-Log anschauen...

[gaert]

Die Client-ID ist eine interne fortlaufende ID des Clients (quasi ein Array-Index).

[WWebber]

Habt ihr evtl. eine Weiterleitung von einem Reverse Proxy auf Port 8080 des EDOMI Servers. (EDOMI Websocket)
Evtl. passiert dies, wenn irgendein potenzieller Anǵreifer den Port 8080 des DSL Routers scannt.

Einen Reverse Proxy hab ich nicht, aber ich habe mal testweise edomi vom Internetrouter komplett abgehängt. Ich lass es mal einen Tag durchlaufen.

[saegefisch]

jonofe : Tatsächlich sind bei mir alle server per Client certifcate geblockt. Port 8080 nicht. Hab's gerade noch mal versuucht: Wenn man CC aktiviert, kommt der rote edomi-Kreis dauerhaft, wenn man CC für Port 8080 entfernt und reload ausführt, geht der Visu-Zugriff unmittelbar los.

Daher die Frage: Kann man Port 8080 irgendwie sinnvoll an die client certificates hängen/einbinden? Das sporadische Auftreten und Deine Rückmeldung lassen mich ahnen, dass Du Dir schon selbst die Frage gestellt hast und websocket eine vermutete Ursache ist...

[jonofe]

saegefisch: Bislang nutze ich den Reverse Proxy nicht für den Zugriff auf EDOMI, sondern nur für die Alexa und Spotify LBS. Daher hat sich mir das Problem noch nicht gestellt. Wie genau wird denn bei dir der Port 8080 weitergeleitet?

[saegefisch]

Den Port-443-Teil lass' ich mal weg, der funktioniert wunderbar und nachweislich mit Client Certificates (inkl. Test zu revoke, etc)

 upstream websocket {
        server <IP_edomi>:8080;
        }
[...]
# >>>> Port 8080: Websocket edomi
 server {
        listen 8080 ssl;
        listen [::]:8080 ssl;
#        ssl_client_certificate /etc/ssl/ca_int/cacert.pem;
#        ssl_crl /etc/ssl/ca_int/private/ca.crl;
#        ssl_verify_client on;    # on | off | optional | optional_no_ca
        location / {
                proxy_pass http://websocket;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}

In manchen Anleitungen im WWW mit RevProxy und WebSocket (aber non-edomi) habe ich gesehen, dass dort gegentlich gar nicht zwischen server 443 und server für wesocket (bei edomi die 8080) trennen. Allerdings schient mir das für edomi nicht passend, oder. Es braucht für beide Ports einen Server-Teil, oder?

Irgendwie komm' ich da gerade ins grübeln, ob das ein Sicherheits-Risiko ist, weil der Port 8080 durchgereicht wird und das nicht einmal per SSL... irgendwie habe ich das wohl mangels Erfahrung nicht zu Ende gedacht und dachte, dass der der websocket ja immer eine (upgrade-)Reaktion auf einen 443-SSL-Verbindung sein würde. Aber vielleicht war das zu optimistisch...?!?