MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054

[jonofe]

Es wird genauso gepublished wie vorher, d.h. immer wenn ein Update oder Insert eines KO's in der mysql Tabelle gemacht wird.
Deine TLS Meldungen kommen aber vom Subscribe Server. Den hab ich nicht geändert und auch nicht neu hochgeladen.

[sunnyhd]

Hi André,

mir ist noch aufgefallen das beim Publisher kein Log geschrieben wird obwohl der Eingang 13 mit 8(debug) belegt ist. Die Logwarnung war tatsächlich vom Subscribe Server.

In der Hilfe gibt es 14 Eingänge. Nach Eingang 8 wird der Eingang 10 beschrieben.

Wenn ich die Verschlüsselung im Publisher aktiviere erfolgt kein Update mehr vom Topic in der MQTT Anwendung wenn von EDOMI<=>KNX geschaltet wird. Sobald ich die Verschlüsselung deaktiviere geht es wieder.

Gruß
Klaus

[jonofe]

mir ist noch aufgefallen das beim Publisher kein Log geschrieben wird obwohl der Eingang 13 mit 8(debug) belegt ist. Die Logwarnung war tatsächlich vom Subscribe Server.

Das ist korrekt. Der EXEC Teil ist kein LBS im EDOMI Sinne, sondern wird lediglich aus der MySQL Procedure aufgerufen. Daher funktioniert auch der EDOMI Logging Mechanismus nicht. Derzeit würde nur der LBS Teil ein Log erstellen und dies auch nur wenn etwas beim Erstellen der MySQL Trigger oder der MySQL Procedure schief geht. Kein Log ist also erstmal ein gutes Zeichen.

In der Hilfe gibt es 14 Eingänge. Nach Eingang 8 wird der Eingang 10 beschrieben.

Habe die Erklärung von Eingang 9 in der Hilfe ergänzt. Danke für den Hinweis.

Wenn ich die Verschlüsselung im Publisher aktiviere erfolgt kein Update mehr vom Topic in der MQTT Anwendung wenn von EDOMI<=>KNX geschaltet wird. Sobald ich die Verschlüsselung deaktiviere geht es wieder.

Sprichst du vom Publish Server oder vom Publish Client?
Welchen Broker verwendest du? Wenn der Broker verifizierbare SSL Zertifikate erwartet, dann geht das natürlich schief. Du musst den Broker so konfigurieren, dass er alle Zertifikate (auch self-signed-certificates) akzeptiert oder TLS ausschalten.

[sunnyhd]

Ich spreche vom Publishing Server. Im Mosquitto Broker erhalte ich Fehlermeldungen im log. Die Kommunikation vom Broker zu Edomi funktioniert. Im Subscribe Server ist tls auch aktiviert.
[
CODE]
1499125087: OpenSSL Error: error:140F3042:SSL routines:SSL_UNDEFINED_CONST_FUNCTION:called a function you should not call
1499125089: Error in poll: Interrupted system call. [/CODE]

[sunnyhd]

Ich bin nochmal auf den Publishing Server v0.3 zurückgegangen. Hier funktioniert die Kommunikation verschlüsselt aber eben mit Verzögerung.

[jonofe]

Habe es gerade noch mal bei mir überprüft. TLS funktioniert problemlos mit lokalem MOSQUITTO.
In welchem Log steht der Fehler? Im mosquitto.log ?
Wie sieht denn deine mosquitto config aus?

Sollte ungefähr sowas drinstehen:

listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
certfile /etc/mosquitto/certs/raspbx.crt
keyfile /etc/mosquitto/certs/raspbx.key

[sunnyhd]

Der Fehler steht im Serverlog des Cloudanbieters CloudMQTT.com (mosquitto version 1.4.10). Zugriff auf die mosquitto config habe ich nicht. Die Konfiguration erfolgt in einer Weboberfläche. Komisch das es in Version v0.3 funktioniert und in der v0.3.1 nicht. Auf deren Website gibt es diese Info.

How do I connect using TLS (SSL)? Where do I find cert and key files?

If you connect by TLS/SSL, add --capath or --cafile and point it to a cert store. Our server cert is signed by Comodo, which has the AddTrust CA as root. Most OSs comes with it by default, so can you point to your default trust/CA store. (example: --cafile=/etc/ssl/certs/ca-certificates.crt) More information can be found here, under Certificate based SSL/TLS Support. You also need to use the port for MQTT over TLS (see above).

[jonofe]

So wie ich das verstehe ist dies ein Performance Problem beim Aufbau der SSL Verbindung.
Kannst mal im Sourcecode das

$client->loop(1); 

in

$client->loop(5); 

ändern. Vielleicht geht es dann. Derzeit looped das Skript nur für 100ms. In dieser Zeit muss die Publish Transaction abgeschlossen sein. Bei einem externen Provider inkl. SSL Handshake ist das vermutlich zu kurz.

Einfach mal testen und kurzes Feedback geben ...

[sunnyhd]

Leider funktioniert es nicht. Bei dir werden die Topics bei aktivierter Verschlüsselung upgedatet wenn Du zum Beispiel über einen Taster eine GA schaltest?
Bei mir werden die Topics nicht mehr upgedated. In Version v0.3 funktioniert es.

[tobo]

Habe es gerade noch mal bei mir überprüft. TLS funktioniert problemlos mit lokalem MOSQUITTO.

Hallo André,

vielleicht hast Du eine Idee hierzu: Ich betreibe eine eigene kleine CA für mein Netzwerk, sprich, auf allen Clients stelle ich das öffentliche Zertifikat zur Verfügung, so dass die Server die mit diesen Zertifikaten laufen akzeptiert werden. Läuft auch überall sonst. Meine Mosquitto Konfiguration ähnelt Deiner, der mosquitto Server startet und lauscht auf Port 8883:

listener 8883
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/cert.crt
keyfile /etc/mosquitto/certs/cert.key

Im Publish Server habe ich mein CA Zertifikat (ca.crt) angegeben, welches ich vorher lokal abgelegt habe. Der Pfad stimmt, das Zertifikat habe ich mit chmod 777 für alle verfügbar gemacht. Dennoch bekomme ich in der mosquitto.log diesen Fehler:

1502533230: New connection from 192.168.11.168 on port 8883.
1502533230: OpenSSL Error: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
1502533230: OpenSSL Error: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
1502533230: Socket error on client <unknown>, disconnecting.

[jonofe]

Sprechen wir hier weiterhin vom SSL Fehler oder von was anderem?

Bei mir funktioniert es mit und ohne SSL in gleicher Weise. Hast du mal mit einem lokalen Mosquitto getestet?

Ich habe allerdings gerade festgestellt, dass ich KNX KOs, die per Ausgangsbox gesendet werden, nicht im Mosquitto sehe, sondern nur die Antwort des Aktors mit der enstprechenden Status-GA. Wenn ich allerdings dieselbe Schaltaktion aus der Admin Oberfläche von EDOMI auslöse, dann sehe ich beide GAs im Mosquitto, d.h. die ausgehende Schalt-GA als auch die Status-GA, die vom Aktor zurückkommt. Dies liegt aber nicht am SSL, sondern scheinbar sendet EDOMI die GA per Ausgangs-LBS irgendwie anders und nicht über die Tabelle auf der der Trigger läuft.

EDIT: Der letzte Absatz war Blödsinn. Dieser Effekt tritt nur auf, wenn das KNX Signal aus einer anderen EDOMI Instanz gesendet wird, auf der der MQTT Publisher nicht läuft. Das sollte ja eigentlich nicht passieren.

[tobo]

Ich glaube nicht dass es an Deinem Baustein liegt, lass mich die Frage präzisieren: Kann ich anstelle des ca-bundle auch ein einzelnen CA-Zertifikat für den Baustein verwenden?

[jonofe]

tobo: Ehrlich gesagt bin ich nicht der SSL/TLS Experte. Das müsstest du ausprobieren. Mein letzter Post war übrigens die Antwort für sunnyhd nicht die Antwort auf deinen Post. Grundsätzlich bedeutet aber certificate unknown, dass die Validierung des Zertifikats fehlgeschlagen ist, d.h. irgendwas passt beim Vergleich Zertifikat und Client nicht. Könnte z.B. der verwendete Common Name bei der Erstellung des Zertifikats sein.

[jonofe]

tobo : Du könntest mal in Sourcecode (ziemlich am Ende) beim

//$client->setTlsInsecure(true); 

die Kommentarzeichen entfernen:

$client->setTlsInsecure(true); 

[Nanosonde]

Hi jonofe ,

ich habe ja aktuell nur die MQTT Client LBS bei mir im Einsatz.

Dabei ist mir folgendes Problem beim Subscribe-Client aufgefallen: dadurch, dass er logic_setOutput() an den Ausgängen verwendet, werden manche Nachrichten einfach schlicht verschluckt, wenn mal etwas schneller Daten reinkommen.

Da man jetzt nicht alle anderen MQTT Clients umschreiben kann, die Daten per MQTT Publish veröffentlichen, muss also eine Lösung auf der Subscribe-Seite eingebaut werden.

Die einfachste Lösung, die bei mir auch aktuell so läuft, ist, logic_setOutput() gegen logic_setOutputQueued() zu tauschen.
So überlässt man natürlich das Queuing Edomi. Da ich nicht genau weiß, inwiefern jetzt Edomi durch kurzeitiges erhöhtes Queuing von LBS Ausgängen beeinträchtigt wird, müsste man evtl. über Alternativen nachdenken. Gestern hatte ich nämlich kurz mal einen SeqCounter Error, als ca. 20 Datenpunkte meiner Lüftungsanlage per MQTT übertragen wurden (ca. 3 MQTT Telegramme pro Sekunde, mit logic_setOutputQueued()).

Dieses Problem war mir auch schon bei meinem TCP-Server LBS aufgefallen, bei dem ich es jetzt so gemacht habe, dass der User per Eingang wählen kann, ob logic_setOutput() oder logic_setOutputQueued() verwendet wird.

Äußerst unschön ist, dass ich noch nicht einmal eine Möglichkeit habe, zu überprüfen, ob ein Aufruf von logic_setOutput() überhaupt berücksichtigt wurde.

Eine Alternative wäre natürlich noch, ein eigenes Queuing für LBS mit EXEC-Teil zu implementieren, um so sicherzustellen, dass das Edomi Queuing nicht überlastet wird(siehe Edomi LBS Funktionsreferenz zu logic_setOutputQueued()), indem reinkommende Daten einfach ausgebremst werden und nur mit vorgegebender Geschwindigkeit an Edomi weitergereicht werden.