MQTT2_Server nicht erreichbar

[patlabor]

Hallo zusammen,

ich versuche gerade meine ersten Schritte mit MQTT und möchte meinen aktuellen Standort über Opentracks an Fhem übertragen.

Zuerst habe ich es per moquitto versucht, das hat auch von der Einrichtung her super funktioniert, nur habe ich es nicht geschafft irgendwelche sinvollen Daten nach Fhem zu bekommen.
Nach ein bisschen lesen bin ich dann über den MQTT2_Server gestolpert, der mir etwas einfacher zu beherrschen scheint. also mosquitto wieder desinstalliert und den Server mit

Code Auswählen Erweitern

define MQTTBroker MQTT2_Server 1883 global
in betrieb genommen.
An Opentracks habe ich nichts geändert.
Leider bekomme ich jetzt ständig Fehler ala "Verbindung wurde getrennt" oder "Connection refused" in Opentracks, und bei Fhem kommt nichts an.
Nach langem suchen bin ich über folgende Zeile im Fhemlog gestolpert

Code Auswählen Erweitern

2018.09.22 12:33:50 1: Connection refused from the non-local address xx.xx.xxx.xxx:46722, as there is no working allowed instance defined for it
Die Fehlermeldung bezieht sich auf meine öffentliche IP und von der Zeit her scheint es dann ausgelöst zu werden, wenn ich versuche per Opentrack vom Handy aus zu senden.
Leider geht aber aus der Fehlermeldung nicht hervor woher der Fehler stammt. Wer lehnt denn hier die Verbindung ab und was für eine "erlaubte Instanz"?
Habe auch das allowed device in fhem gefunden, evtl hat es ja damit was zu tun, also habe ich mir versuchsweise mal ein

Code Auswählen Erweitern

define alowed_MQTT allowed angelegt und dem MQTTBroker zugeordnet, aber das hat auch keine abhilfe geschaffen.
Bin ich hier überhaut auf der richtigen Spur oder mache ich etwas total falsch?

[rudolfkoenig]

Um Unbefugten den Zugriff zu erschweren (bzw. damit FHEM nicht mit doofen Schlagzeilen in den Medien landet, nur weil Anfaenger ihre Installation direkt ins Internet haengen) unterbindet FHEM seit etwa einem Jahr den Zugang zu Netzwerkdiensten (FHEMWEB, telnet, MQTT2_SERVER) ohne Passwort, wenn die Gegenseite "offensichtlich" aus dem wilden Internet stammt.

Mit einer allowed Instanz kann man den o.g. Diensten ein Passwort zuweisen, und die Fehlermeldung weist darauf hin. Btw. diese Meldung sollte als motd auch auf der Einstiegsseite von FHEMWEB erscheinen.

Wenn man aus dem Internet auf FHEM zugreift, sollte man die Verbindung verschluesseln. Das ist in FHEM noch unter SSL bekannt, in Wirklichkeit wird aber TLS verwendet. SSL/TLS ist zwar fuer den MQTT2_SERVER implementiert, ich habe aber keinen client gefunden, um es testen zu koennen.
Eine andere Alternative ist VPN, dann kann man sich sogar allowed schenken.

[patlabor]

Danke für den Tip.
Fhemweb ist selbstverständlich per Passwort abgesichert und läuft TLS verschlüsselt hinter Caddy. Nur hatte ich seinerzeit im Fhemweb das Passwort festgelegt.

Diese allowed Dinger sind wohl während irgend einem Update dazugekommen. Habe lange kein Update gemacht, weil ich mir die Probleme mit @ und ! ersparen wollte, und die Sache mit dem csrf-token war mir auch ziemlich unheimlich, bzw. habe immer noch keine Ahung wie ausser das Ding im allowed totzuschalten ich damit umgehen soll.
Da mich der MQTT2 Server aber sehr interresiert, habe ich dann irgendwann den Sprung gewagt.

Leider komme ich aber auch mit einem in einem für den MQTT Server zuständigen allowed mit hinterlegtem Passwort nicht weiter.

Unter Fhem taucht immer noch der gleiche Fehler auf.
Opentrack gibt folgende Fehlermeldung

Code Auswählen Erweitern

Verbindung wurde getrennt (32109) - java.io.EOFException

[hexenmeister]

SSL/TLS ist zwar fuer den MQTT2_SERVER implementiert, ich habe aber keinen client gefunden, um es testen zu koennen.

mqtt-spy kann TLS.
Manage-Connections -> Security -> TLS

Habe bis jetzt allerdings nur mit Mosquitto getestet.

[rudolfkoenig]

Leider komme ich aber auch mit einem in einem für den MQTT Server zuständigen allowed mit hinterlegtem Passwort nicht weiter.

Konnte das Problem nachvollziehen, und habe es im 96_allowed.pm behoben. Sollte nach dem update morgen funktionieren.

mqtt-spy kann TLS.

Mag sein, aber wir (ich und mqtt-spy) moegen uns gegenseitig nicht. Faengt damit an, dass in Java11 kein JavaFX gibt, und geht damit weiter, dass Fehlermeldungen als Java-Exception (vulgo: unverstaendlich) kommen.  Ich will eigentlich "nur" TLS testen, und nicht anfangen Zertifikate fuers Client zu generieren, und einen offiziellen Serverzertifikat besorgen. Seufz.