Echo <-> HS Bridge ohne zusätzlichen Internettraffic

[Hotstepper13]

Hallo zusammen,

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.


Grüße Hiele

Dockerimage ist nun verfügbar: https://hub.docker.com/r/hotstepper1...a-gira-bridge/

Es kann eventuell probleme mit dem IP Lookup geben. GGfs. muss Host networking aktiviert werden. Sag bitte bescheid wenn du es getestet hast.

Beste Grüße

Frank

[Hiele]

Hi Frank,

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

[Hotstepper13]

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.

Für den Test ob im Homeserver alles richtig eingerichtet ist, hat WernerL eine vorzügliche Dokumentation aufgebaut:
https://github.com/Picpol/HS-AmazonE...a-Installation

Sobald der folgende Request funktioniert (natürlich musst du die daten anpassen), sollte auch meine Software sauber arbeiten:

https://[GIRA_HOMESERVER_IP]:[PORT_LBS]/discovery?accessToken=[TOKEN]&messageId=xyz

Wenn dein Homeserver also auf der IP 192.168.10.100 erreichbar ist und du TollesPasswort als token verwenden würdest, würde der link so aussehen:

https://192.168.10.100:30000/discovery?accessToken=TollesPasswort&messageId=xyz

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

1. Erstellen einer RootCA
2. Erstellen eines CertificateSigningRequest (CSR) inkl. Private Key
3. 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

[Hiele]

Hallo Frank,

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)

HOMESERVER_IP=192.168.1.100
HOMESERVER_PORT=30000
TOKEN=superSecretPassword <- Mein Passwort
DEBUG=FALSE

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?

[Hotstepper13]

Hallo Hiele,

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

[Hiele]

Oh man, so typisch ;-) PW geändert...

AWS etc. läuft
https Zugriff läuft
Muss jetzt nur noch den Docker hinbekommen.

Muss ich einen bestimmten Ausführungsbefehl angeben, oder reichen die "Umweltvariabeln"?


Gruß
Hiele

[Hotstepper13]

Oh man, so typisch ;-) PW geändert...

AWS etc. läuft
https Zugriff läuft
Muss jetzt nur noch den Docker hinbekommen.

Muss ich einen bestimmten Ausführungsbefehl angeben, oder reichen die "Umweltvariabeln"?


Gruß
Hiele

Bei Docker musst du die Umgebungsvariablen in den Container injecten. Das passiert mit dem -e attribut.

Beispielbefehl:

docker run -e HOMESERVER_IP=192.168.0.23 -e HOMESERVER_PORT=30000 -e TOKEN=superSecretPassword -e DEBUG=false -p 4711:4711 -p 1900:1900/udp hotstepper13/alexa-gira-bridge:latest

-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):

[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.

Gruß
Frank

[Hotstepper13]

Es gibt ein neues Release 2.0.9

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.

Gruß
Frank

[Hiele]

Hi Frank,


hat bei mir ein bisschen gedauert, aber hier mal zwei Ergebnisse:

1. run Docker wie von dir vorgeschlagen


2. run Docker im Hostnetz // --net=host



Startet also so nicht :-(

Sorry hier das 3. Bild mit dem akt. Build 2.09

[Jörg D.]

Hallo Frank,

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

[Hotstepper13]

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

[B]root@NetApp[/B]:[B]~[/B]# netstat -lnp |grep 1900
udp        0      0 0.0.0.0:[B]1900[/B]            0.0.0.0:*                           8555/dms            
udp        0      0 0.0.0.0:[B]1900[/B]            0.0.0.0:*                           8195/minissdpd

Merkwürdigerweise scheint der da doppelt gebunden zu sein. Das sollte eigentlich nicht gehen.

[Hotstepper13]

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.

Ich denke das kann ich in der Software abfangen.

Melde mich wieder

[Hotstepper13]

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

Gruß
Frank

[Hiele]

Läuft :-)

[Jörg D.]

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.

Vielen Dank für Deine schnelle Reaktion!

Einen schönen Restsonntag noch


Jörg