Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
Echo <-> HS Bridge ohne zusätzlichen Internettraffic
bevor ich ein Docker Image für die Synology baue, frage ich lieber vorher ob jemand das schon angegangen ist. Muss ja nicht doppelt gemacht werden
Da ich keinen Rechner nebenbei laufen habe wäre das für mich die Ideale Lösung wenn ich die bridge auf einem Ubuntu-Image mit Java laufen lassen würde.
bin zwar nicht ganz fit mit der SSL Geschichte und offensichtlich noch deutlich unwissender als du. Also:
1. Logik läuft
2. Zertifikat erstellt und hochgeladen (habe es über die Synology (Einstellungen/Sicherheit->Zertifikat gemacht)
3. Auf Debugseite taucht auch alles auf
4. ohne Zertifikat alles besten (Konnte auch ein Test Objetk anlegen)
5. Mit hochgeladenem Zertifikat nicht mehr erreichbar
Unter Zertfikat wird alles inkl. dyndns.org Adresse richtig angezeigt.
Dadruch startet die Dockerbridge auch nicht richtig und bricht sofort mit Fehlern ab.
Ich denke das liegt noch an dem Zertifikat... Werde morgen bzw. Sontag noch rumtesten....
Info folgt!
Hast aber super schnell gemacht - Klasse!!! Hab Dank
2017-02-23 20:51:49
stdout
at com.hotstepper13.alexa.GiraBridge.main(GiraBridge. java:66)
2017-02-23 20:51:49
stdout
at com.hotstepper13.alexa.gira.Discovery.<init>(Disco very.java:44)
2017-02-23 20:51:49
stdout
at com.hotstepper13.alexa.gira.Discovery.parseDiscove ryResponse(Discovery.java:64)
2017-02-23 20:51:49
stdout
Exception in thread "main" java.lang.NullPointerException
2017-02-23 20:51:49
stdout
... 19 common frames omitted
2017-02-23 20:51:49
stdout
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocke tImpl.java:973) ~[na:1.8.0_121]
2017-02-23 20:51:49
stdout
at sun.security.ssl.InputRecord.read(InputRecord.java :505) ~[na:1.8.0_121]
2017-02-23 20:51:49
stdout
Caused by: java.io.EOFException: SSL peer shut down incorrectly
2017-02-23 20:51:49
stdout
at com.hotstepper13.alexa.GiraBridge.main(GiraBridge. java:66) [gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at com.hotstepper13.alexa.gira.Discovery.<init>(Disco very.java:43) [gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at com.hotstepper13.alexa.gira.Discovery.fetchDiscove rySSL(Discovery.java:57) [gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at com.hotstepper13.alexa.network.Util.triggerHttpGet WithCustomSSL(Util.java:98) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.client.CloseableHttpClient.ex ecute(CloseableHttpClient.java:107) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.client.CloseableHttpClient.ex ecute(CloseableHttpClient.java:82) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.client.InternalHttpClient.doE xecute(InternalHttpClient.java:184) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.execchain.RedirectExec.execut e(RedirectExec.java:110) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.execchain.RetryExec.execute(R etryExec.java:88) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.execchain.ProtocolExec.execut e(ProtocolExec.java:184) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.execchain.MainClientExec.exec ute(MainClientExec.java:236) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.execchain.MainClientExec.esta blishRoute(MainClientExec.java:380) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.conn.PoolingHttpClientConnect ionManager.connect(PoolingHttpClientConnectionMana ger.java:353) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.impl.conn.DefaultHttpClientConnect ionOperator.connect(DefaultHttpClientConnectionOpe rator.java:134) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.conn.ssl.SSLConnectionSocketFactor y.connectSocket(SSLConnectionSocketFactory.java:35 3) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at org.apache.http.conn.ssl.SSLConnectionSocketFactor y.createLayeredSocket(SSLConnectionSocketFactory.j ava:394) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-23 20:51:49
stdout
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLS ocketImpl.java:1387) ~[na:1.8.0_121]
2017-02-23 20:51:49
stdout
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLS ocketImpl.java:1403) ~[na:1.8.0_121]
2017-02-23 20:51:49
stdout
at sun.security.ssl.SSLSocketImpl.performInitialHands hake(SSLSocketImpl.java:1375) ~[na:1.8.0_121]
2017-02-23 20:51:49
stdout
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocke tImpl.java:992) ~[na:1.8.0_121]
2017-02-23 20:51:49
stdout
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
2017-02-23 20:51:49
stdout
20:51:49.658 [main] ERROR com.hotstepper13.alexa.network.Util - Error executing the request.
2017-02-23 20:51:48
stdout
20:51:48.529 [main] INFO c.h.alexa.configuration.Config - Token: ********** (Hint: enable debug to show cleartext!)
2017-02-23 20:51:48
stdout
20:51:48.528 [main] INFO c.h.alexa.configuration.Config - HomeserverPort: 30000
2017-02-23 20:51:48
stdout
20:51:48.528 [main] INFO c.h.alexa.configuration.Config - HomeserverIp: 192.168.10.100
2017-02-23 20:51:48
stdout
20:51:48.519 [main] INFO c.h.alexa.configuration.Config - Initialized config
hmm.. ich glaube wir haben hier ein grundsätzliches Verständnisproblem....
Die Fehlermeldung bezieht sich auf die Verbidung zwischen alexa-gira-bridge und dem Homeserver.
Das Zertifikat musst du im Homeserver hochladen (siehe auch https://github.com/Picpol/HS-AmazonE...ikat-erstellen)
Die alexa-gira-bridge braucht kein ssl zertifikat da sie komplett unverschlüsselt arbeitet. Lediglich der Zugriff auf dem Homeserver selbst erfolgt mit SSL.
BTW. DynDNS oder sowas brauchst du nicht da der Netzwerkverkehr komplett innerhalb deines eigenen Netzwerks abläuft.
Dein Browser wird vermutlich jammern das das Zertifikat nicht vertrauenswürdig ist, aber das kann man in der Regel übergehen btw. den Zugriff trotzdem zulassen. alternativ kannst du die RootCA (also das master zertifikat) in deinem Browser als Vertrauenswürdig importieren.
Wenn der oben erwähnte Request im Browser funktioniert aber die Bridge dennoch nicht startet, dann müssen wir da definitiv nochmal genauer schauen.
Achtung! Hintergrundinfos (nicht wirklich relevant für das aktuelle Thema)
SSL Funktioniert in der Regel nach folgendem Schema
Erstellen einer RootCA
Erstellen eines CertificateSigningRequest (CSR) inkl. Private Key
Verwendung der RootCA um den CSR zu signieren
Der Vollständigkeit halber; Bei gekauften Zertifikaten (zum Beispiel von Symantec) gibt es noch einen Zwischenschritt (ein sogenanntes Intermediate Zertifikate).
Bei jeder Verbindung wird geprüft ob die RootCA im eigenen Betriebsystem als Vertrauenswürdig gilt. Es gibt ein paar große sog. Authorities die im globalen Truststore (z.B. bei Mozilla, Microsoft, Apple, Google oder ähnlichen) enthalten sind. Die sogenannte Certificate Chain muss dabei vollständig sein. D.g. der RootCA muss vetraut werden, diese stellt (eventuell) ein intermediate aus dem vertraut werden muss und mit diesem intermediate wird dann das eigentliche Zertifikat ausgestellt.
Beste Grüße
Frank
Zuletzt geändert von Hotstepper13; 24.02.2017, 16:18.
hatte die Anleitung schon durch. Auch so gemacht und verstanden.
Zum einen wenn das Zertifikat (im HS) hochgeladen ist, kann ich über die HS Debugseite mir das Zertifikat anzeigen lassen, aber ich erreiche Appliances configuration bzw. Logfile nicht mehr (http/https). Sobald die Zertifikatsdatei nicht im HS upload Verzeichnis ist, klappt es wunderbar. (ohne HTTPS).
Klar hat das nichts mit dem Docker zu tun Liegt verm. an dem falsch erstellten Zertifikat... Muss mich da noch reinabeiten, da ich kein Linux habe um mir ein einfach nach Anleitung zu erstellen.
Zum Docker: Also den habe ich geladen und die Umgebungsvariablen hinzugefügt (Ports waren ja schon in deiner Vorgabe)
und den gestartet. Er bricht aber den Start ab, mit dem o.g. Protokoll. Muss ich für deine Docker-alexa-bridge den kompletten Ablauf (also AWS account etc.) durch haben? Hat doch erstmal damit nichts zu tun, oder?
nein, musst du nicht. Aber die Appliance muss über https erreichbar sein.
Der Start wird abgebrochen an da die Software als erstes versucht die Verbindung zum Homeserver aufzubauen um die Appliances abzurufen. Ich werde mal schauen ob ich da noch die Fehlersituation abfangen und eine ordentliche Fehlermeldung ausgeben kann.
Mir fällt aber gerade ein das ich sicherlich auch ne Version bauen kann bei es konfigurierbar ist ob man mit ssl (https) oder http anfragt.
Hier ist übrigens ne Anleitung wie man ein selbst signiertes Zertifikat unter windows erzeugen kann: https://blog.didierstevens.com/2015/...sl-on-windows/
Es kann sein, dass du im Anschluss das Zertifikat noch einmal in das x509 format (PEM) umwandeln musst. Da bin ich aber gerade nicht ganz sicher. Im Thread von Werner findest du da bestimmt hilfe. Soweit ich das gesehen habe, waren da einige die mit dem SSL Zertifikat ihre Probleme hatten.
Kleiner Tipp... das Passwort steht zweimal im Log In der Discovery URL ist das passwort im Debug modus auch nochmal im Klartext aufgeführt.
Wenn ich gleich dazu komme, schaue ich mal ob ich das mit dem ssl konfigurierbar machen kann.
Gruß
Frank
Zuletzt geändert von Hotstepper13; 25.02.2017, 17:41.
-e sorgt dafür das Umgebungsvariables in den Container eingefügt werden und dort zur Verfügung stehen
-p bindet netzwerkports
Wie schon angemerkt kann es passieren das sich die Software eine interne docker ip raussucht, dann würde sie nicht funktionieren.
Wichtig ist die folgende Logausgabe (wird auf INFO geloggt):
Code:
[main] INFO c.h.alexa.network.TcpServer - TCP Server found IP: 10.18.97.73
Wenn da keine IP aus deinem Netzwerk steht dann wird es nicht funktionieren. Testen kannst du das indem du mit deinem browser einen Abruf auf
http://<ip-aus-dem-log>/description.xml machst. Wenn das funktioniert, dann sollte auch alexa alles finden was sie braucht.
In diesem Release habe ich den von dir beschriebenen Fehler bei der SSL Kommunikation abgefangen (das Programm sollte dann eine saubere Fehlermeldung ausgeben und terminieren).
Ausserdem kann man nun SSL für die Bridge<->Homeserver kommunikation auch deaktivieren.
Zuguterletzt kann man jetzt auch eine IP mitgeben, die beim Discovery an das anfragende Gerät gesendet wird. Das ist praktisch wenn man hinter einem Proxy oder zum Beispiel im Dockerumfeld ist.
Zum Beispiel:
HostIP: 192.168.0.23
IP des Containers: 172.13.0.2
Dann einfach docker mit den ports starten und zusätzlich die Umgebungsvariable "-e HTTP_IP=192.168.0.23" mitgeben. Bei allen Anfragen die die Software dann bekommt, wird sie den Anfragenden mitteilen das die Befehle unter 192.168.0.23 erreichbar sind.
erst einmal einen großen Respekt für die Arbeit! Docker erleichtert einem Linux-Laie, wie ich einer bin, das schon Leben. Danke!
Die Lösung von Werner läuft bei mir, wollte aber Deine Umsetzung ausprobieren.
Habe soeben Deinen Dockercontainer mit den passenden Einstellungen auf der Synology gestartet. Der Abbruch und das Fehlerprotokoll sieht 100% genauso aus wie bei Hiele.
Gruss
Jörg hotstepper13-alexa-gira-bridge1
2017-02-26 13:48:07
stdout
at com.hotstepper13.alexa.GiraBridge.main(GiraBridge. java:66)
2017-02-26 13:48:07
stdout
at com.hotstepper13.alexa.gira.Discovery.<init>(Disco very.java:44)
2017-02-26 13:48:07
stdout
at com.hotstepper13.alexa.gira.Discovery.parseDiscove ryResponse(Discovery.java:64)
2017-02-26 13:48:07
stdout
Exception in thread "main" java.lang.NullPointerException
2017-02-26 13:48:07
stdout
at com.hotstepper13.alexa.GiraBridge.main(GiraBridge. java:66) [gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at com.hotstepper13.alexa.gira.Discovery.<init>(Disco very.java:43) [gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at com.hotstepper13.alexa.gira.Discovery.fetchDiscove rySSL(Discovery.java:57) [gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at com.hotstepper13.alexa.network.Util.triggerHttpGet WithCustomSSL(Util.java:98) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.client.CloseableHttpClient.ex ecute(CloseableHttpClient.java:107) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.client.CloseableHttpClient.ex ecute(CloseableHttpClient.java:82) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.client.InternalHttpClient.doE xecute(InternalHttpClient.java:184) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.execchain.RedirectExec.execut e(RedirectExec.java:110) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.execchain.RetryExec.execute(R etryExec.java:88) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.execchain.ProtocolExec.execut e(ProtocolExec.java:184) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.execchain.MainClientExec.exec ute(MainClientExec.java:236) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.execchain.MainClientExec.esta blishRoute(MainClientExec.java:380) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.conn.PoolingHttpClientConnect ionManager.connect(PoolingHttpClientConnectionMana ger.java:353) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.impl.conn.DefaultHttpClientConnect ionOperator.connect(DefaultHttpClientConnectionOpe rator.java:134) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.conn.ssl.SSLConnectionSocketFactor y.connectSocket(SSLConnectionSocketFactory.java:35 3) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.conn.ssl.SSLConnectionSocketFactor y.createLayeredSocket(SSLConnectionSocketFactory.j ava:395) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
at org.apache.http.conn.ssl.SSLConnectionSocketFactor y.verifyHostname(SSLConnectionSocketFactory.java:4 65) ~[gira-bridge-2.0.9-SNAPSHOT-jar-with-dependencies.jar:na]
2017-02-26 13:48:07
stdout
javax.net.ssl.SSLPeerUnverifiedException: Host name '10.1.1.11' does not match the certificate subject provided by the peer (CN=GiraHS-AmazonEcho, O=xxx, L=xxx, ST=BY, C=DE)
2017-02-26 13:48:07
stdout
13:48:07.840 [main] ERROR com.hotstepper13.alexa.network.Util - Error executing the request.
2017-02-26 13:48:04
stdout
13:48:04.516 [main] INFO c.h.alexa.configuration.Config - Token: ******* (Hint: enable debug to show cleartext!)
2017-02-26 13:48:04
stdout
13:48:04.515 [main] INFO c.h.alexa.configuration.Config - HomeserverPort: 30000
2017-02-26 13:48:04
stdout
13:48:04.514 [main] INFO c.h.alexa.configuration.Config - HomeserverIp: 10.1.1.11
2017-02-26 13:48:04
stdout
13:48:04.487 [main] INFO c.h.alexa.configuration.Config - Initialized config
Ja, das habe ich befürchtet. Die Synology verwendet den UDP port bereits für eigene Services. Deshalb kann die dieser Port nicht nochmal gebunden werden.
In der Regel wird auf der Synology das UPNP von dem Software "MediaServer" verwendet (meine ich gelesen zu haben).
Ich hab mal auf meiner Synology geschaut und dort ist Port tatsächlich gebunden
Ok.. ich glaube ich hab da was gefunden.. der letzte Screenshot von hiele und der logoutput von Jörg zeigen das mit net=host das portbinding funktioniert. Da taucht lediglich noch ein ssl fehler auf weil die Adresse die im Zertifikat angelegt ist, nicht mit der Adresse übereinstimmt die ihr aufruft.
Version 2.0.10 sollte euer Problem fixen. Ich erlaube nun alle Zertifikate, auch wenn der Name nicht passt (wie es bei euch der Fall ist). Dazu müsst ihr dann augenscheinlich das host networking verwenden (--net=host) aber jetzt sollte es dann wirklich funktionieren *daumendrück*
Achtung: Solltest ihr das docker Tag "latest" verwenden, solltet ihr vorher einmal manuell einen docker pull ausführen um auch wirklich die neueste Version zu haben.
Grundsätzlich empfehle ich allerdings immer die Verwendung von Versionierten Tags, da weiß man was man hat
Die Bridge läuft jetzt! Die Variable "ENABLE_SSL" = true war mir jetzt nicht logisch. Ich hatte erst false probiert, weil ich ja die Zertifikatsprüfung aus haben wollte
Die Appliances vom HS werden geladen. Heute Abend wird weiter probiert.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar