Neues Modul: 70_Jabber.pm

Begonnen von BioS, 18 Januar 2014, 11:51:20

Vorheriges Thema - Nächstes Thema

hexenmeister

Hallo!

Goil! Es geht wieder ;)
Vielen Dank, dass Du Dir so viel Mühe gibst :)
Jetzt läuft alles sauber. Allerdings nicht ganz ohne Überraschungen. Die Idee, Jessy-Version zu nehmen erwies sich als nicht besonders schlau, da ging einiges nicht, so habe ich Squeezeserver nicht zum Laufen gekriegt. Dann alles nochmal mit Wheezy - problemlos.

Grüße,

Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

XPectIT

Ist es möglich über dieses Jabber-Modul nachrichten in einen MUC (Mulit-User-Chat) zu schicken?

Hätte Vorteile - teilweise nur wenn der Server die entsprechende Erweiterung unterstützt:
- Benachrichtigung mehrerer Personen mit einer Nachricht
- Es werden keine Nachrichten verpasst wenn der Empfänger mal offline ist

Grüße
XPectIT

Morganoure

Wunderbar!

Probiere seit ein paar Tagen mit FHEM rum, und neben Pushover ist Jabber meine wichtigste Informationsquelle, daher ist es natürlich toll, dass ich FHEM hier entsprechend nutzen kann.

Anhand der Doku auch gleich eingerichtet, inklusive Notify.

Dabei ist mir ein kleiner Bug aufgefallen: ich weiß nicht ob es am Client (Pidgin) oder Server (Openfire) liegt, auf jeden Fall kommen am FHEM auch Statusmeldungen an - zum Beispiel, wenn ich das Chatfenster mit dem FHEM-Account wieder schließe. Was dazu führt, dass das Notify eine neue Meldung rausgibt und es wieder öffnet :D

Ich habe mal das Debugging eingeschaltet; beim Schließen des Fensters kommt folgendes (anonymisiert):

2015.09.08 10:12:27 0: MyChatServer Jabber PollMessages
2015.09.08 10:12:27 0: MyChatServer DoProcess Call
2015.09.08 10:12:27 0: MyChatServer INC_Message: mensch@jabberserver/Pidgin:

2015.09.08 10:12:27 0: MyChatServer Regex m/mensch@jabberserver/ matched
2015.09.08 10:12:27 0: MyChatServer ReadingsUpdate:

2015.09.08 10:12:27 0: MyChatServer Poll End


Das gleiche passiert übrigens auch schon, wenn ich nur tippe (daher bekomme ich auf eine Anfrage 2-3 Antworten). Vermutlich sind das Nachrichten wie die Benachrichtigung an den Client, das ein anderen zu tippen begonnen hat, oder dass der andere das Fenster geschlossen hat.

Einfacher Workaround: in 70_Jabber.pm nur das Notify auslösen, wenn die Länge der $message größer 0 ist. Wahrscheinlich in der Whitelist-Zeile... in Jabber_INC_Message (plus schließende Klammer am Ende natürlich):
  #Check the Whitelist if the sender is allowed to send us.
  if ($message eq "") {
  Log 0, "$hash->{NAME} INC_Message: is status message\n" if $debug;
  } else {
  if ($senderShort =~ m/$attr{$name}{RecvWhitelist}/) {


Noch einfacherer Workaround ohne Änderung am Modul: im Notify die Message auslesen und nur bei ne "" eagieren.

Schönere Lösung: separate Notifys für Öffnen, Schließen, ...

BioS

Ahoi Morganoure und XPectIT :)

Danke für die super Ideen, ich schau mal was ich davon umsetzen kann.

@XPectIT
Das mit den MUC's muss ich mir technisch erstmal reinziehen, besonders was ich vom XMPP dafür abhandeln muss.

@Morganoure
Das Pidgin Thema ist seltsam, denn eigentlich sollte FHEM nur den Typ "Message", also wenn eine Nachricht geschrieben wird, empfangen - keine anderen Typen. Möglicherweise schickt das Pidgin und/oder Openfire in einer "Message" XML mit einem extra Tag an FHEM und da kein Text dabei ist, ist die Nachricht augenscheinlich leer.

Könntest du mir dazu mal die /tmp/jabberdebug.log (anonymisiert) zukommen lassen? Da sollten die XML Nachrichten die ich brauche drin stehen.

Grüße,
BioS
FHEM auf Debian in ESXi5 VM
Homematic mit HMLAN
Raspi mit Pilight für Relais der Heizung

Morganoure

Vielen Dank dass Du reinschauen willst!

Schicke ich gleich per Forenmail hier. Usernamen, Servernamen und die Datenabschnitte (nur Avatar) rausgeschnitten (sonst wären es über 100kb).

Bei "anonymisiert" ist mir übrigens noch eingefallen, dass OTR natürlich die Krönung des ganzen wäre - selbst ein MITM-Angriff oder gestohlene Login-Daten wären dann erfolglos. Gibt sogar ein Crypt::OTR-Perl-Paket, und gängige Jabber-Clients können das auch...

Aber das ist nur ein Vorschlag - IT-Sicherheit ist leider mein Beruf, da kann ich nicht anders als das zumindest zu erwähnen ;)

BioS

Hi ihr beiden,
ich denke nächste Woche wird das fertig, MUC's und OTR.
OTR natürlich nur im 1-1 Chat ;)

Bei den Multi-User-Channeln gibt es die Möglichkeit den FHEM Client in mehrere Channels mit unterschiedlichen Nick's sowie Passwortschutz joinen zu lassen.
Dafür gibt es dann auch extra readings, whitelist und ein neues msgmuc um Nachrichten zu senden.

Bei OTR wird es auch extra readings und ein send commando geben, so kann man nur auf verschlüsselte Nachrichten von bestimmten Empfängern reagieren.

Es gibt auch ein paar trade-off's die ich bisher gefunden hab:
- Das Crypt::OTR Modul muss jeder selber compilieren wenn man diese Option benutzen will.
- Ich muss noch ein bisschen mit perl kämpfen dass ich das Modul dynamisch laden kann, sodass die bisheriger Userbase nicht ohne Jabber-Modul dasteht *gg*
- Bei mir hat es 2 Stunden gedauert bis nach der ersten Nachricht der private key für OTR generiert war. Das mag jetzt vielleicht an meiner VM liegen aber in dieser Zeit macht FHEM _nichts_ und ich hab' bisher nicht herausgefunden wie man solche keys von hand generiert.
Auf der anderes Seite: wer OTR benutzen will wartet auch gerne 2 Stunden :)

Also, danke nochmal euch für die Ideen!

Grüße,
BioS
FHEM auf Debian in ESXi5 VM
Homematic mit HMLAN
Raspi mit Pilight für Relais der Heizung

Morganoure

Das klingt ja echt großartig, da freue ich mich sehr drauf. Vielen Dank :)

BioS

Ahoi zusammen,

die neue Version ist eingecheckt, d.h. ihr bekommt per update am heutigen Abend die neue Version mit MUC und OTR Unterstützung.

Have Phun :)
FHEM auf Debian in ESXi5 VM
Homematic mit HMLAN
Raspi mit Pilight für Relais der Heizung

spikeh1

Zitat von: BioS am 17 September 2015, 11:30:26
Ahoi zusammen,

die neue Version ist eingecheckt, d.h. ihr bekommt per update am heutigen Abend die neue Version mit MUC und OTR Unterstützung.

Have Phun :)

Danke. Funktioniert (MUC) 1A.  :)

lukasbastelpeter

Mahlzeit!

Ich habe folgendes Problem mit dem Modul:
Ich starte meinen "Client" und anscheinend bekommt der FHEM-Account eine "ist-jetzt-online-Meldung" gepusht....
Gefolgt von einem Absturz von Fhem folgender Meldung auf der Konsole:

Not a CODE reference at /usr/local/share/perl/5.14.2/Net/XMPP/Protocol.pm line 3537.

Jemand Vorschläge?!


Danke!
# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT

Morganoure

#130
Das macht Jabber imho zur sichersten Remote-Control-Lösung :)

Leider ist Crypt::OTR etwas umständlich, da es noch Digest::SHA1 statt Digest:SHA haben will, für das es kein Debian-Paket mehr gibt.

Falls jemand wie ich länger daran hängt, was nötig ist, hier ein paar Debian-Schritte:

sudo aptitude update
sudo aptitude install libotr2-dev libyaml-perl liblog-log4perl-perl
sudo cpan Digest::SHA1
sudo cpan Crypt::OTR


Jetzt läuft die Schlüsselgenerierung (aber schon parallel, hast Du gut hinbekommen!), nachdem ich OTREnable auf 1 gesetzt habe, mehr Erfahrungsberichte wenn das soweit ist :)

Nachtrag: in unter einer Viertelstunde fertig, auf einem Raspberry Pi2.
Kontakt läuft verschlüsselt, großartig :)

Was noch schön wäre:
Wenn der Fingerprint im FHEM angezeigt würde, so dass ich im Chat-Client auch verifizieren kann, dass ich richtig verbunden bin.
Wenn es eine optionale Whitelist für Fingerprints der Clients gäbe (AdiumX macht scheinbar das mit dem Shared Secret nicht, das muss ich demnächst noch getrennt mit Pidgin testen).

@lukasbastelpeter: ohne jetzt genug Ahnung von Perl & XMPP zu haben würde ich denken, dass Typ des Clients und des Servers hilfreich wären, damit jemand mit gleicher Konstellation das Problem ggfls. bestätigen oder nicht bestätigen kann.

lukasbastelpeter

ich bin mit meinen accounts bei jabber.ccc.de, der "client" läuft auf meinem macbook in der iMessage-app...
und FHEm läuft auf einem rPi2...

Ich denke das es an der Verschlüsselung irgendwo hakt! Ich werde mal die ganzen Pakete via Cpan manuell installieren heute abend/nacht und gucken ob es was kann...

Ich hatte nämlich spontan gehofft die Unitymedia/IPv6 Problematik mit jabber umgehen zu können. Morgen gehts in den Urlaub und fernzugriff wäre zumindest rudimentär schon Porno 8)
# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT

lukasbastelpeter

#132
Jetzt habe ich mal ein Log...
Leider hat das manuelle installieren aller Pakete auch nix gebracht...
Die genannte Zeile ist übrigens in dem "protocol.pm" folgende Methode: "callbackIQ - default callback for <iq/> packets." was macht die?!


edit: ich habe die Zeile auskommentiert, was auch immer sie macht, ich kann drauf verzichten. Jetzt funktioniert's!
# Raspberry Pi
# Homematic, Z-Wave
# HUE, Tradfri
# Harmony
# ESP8266  Basteleien per MQTT

BioS

#133
Aleoha ihr beiden,
@lukasbastelpeter: da wir keine zeit zum debuggen haben (dein urlaub ruft :P) probier mal spontan per CPAN diese Modulversionen zu installieren:
Zitat von: BioS am 27 August 2015, 13:36:08

  • XML::Stream 1.23 mit Net::XMPP 1.02 = alles gut

EDIT: lol, du hast es ja schon gelöst, also wenn das für dich so passt ist's erstmal OK, vielleicht kannst du mir mal nach deinem Urlaub PM'n dann kann ich evtl. fixen sofern es ein Problem bei meinen Callbacks ist.. Schönen Urlaub dann mal!


@Morganoure:
Schön, dass das OTR Addon seinen Zweck erfüllt, freut mich ;)

Das mit dem Fingerprint hatte ich schon so gut wie implementiert (hashes angepasst, notify's mit trused flag vorbereitet, etc.) bis ich dann am Schluß gemerkt hab, dass Crypt::OTR mir weder den Trust-Status gibt, noch den Fingerprint des users..
Man kann sich das auch nicht manuell holen weil die Crypt-OTR diese Funktionen von libotr nur während der Prüfung des shared secret benutzt. Hmpf  >:(

Das hat mich ganz schön genervt.. Also hab ich alles wieder zurückgebaut und mach eben keinen Verify/Trust Status..

Adium kenn ich leider nicht, ich hab mal Conversations für Android und Pidgin getestet. Die Android App kann auch kein shared secret, wohl aber die Frage/Antwort: Das ist dasselbe - gib einfach dein shared secret bei der Antwort ein und irgendeine Frage.

Ich setze mal bei OTR Benutzung noch eine Prüfung auf Crypt::SHA1 auf meine TODO ;)

Cya,
BioS
FHEM auf Debian in ESXi5 VM
Homematic mit HMLAN
Raspi mit Pilight für Relais der Heizung

BioS

Ist zwar offtopic, aber vielleicht trotzdem intressant für den ein oder anderen:

Zitat von: lukasbastelpeter am 24 September 2015, 19:16:38
Ich hatte nämlich spontan gehofft die Unitymedia/IPv6 Problematik mit jabber umgehen zu können.

nachdem ich nur 6 Stunden Unitymedia Kunde war, mir aber der IPv4/6 Problematik bekannt ist hatte ich dafür aber auch 'ne Lösung: Ich habe mit meinem (eh schon vorhandenen) V-Server, der eine feste v4 und v6 hat, eine art relay-server gebaut der Pakete von der v4 Addresse auf die v6 Unitymedia addresse gemacht und das hat eigentlich ganz gut funktioniert.

Damit konnte ich mit dem Handy über den Umweg v4/v6 auf meine FHEM Kiste zugreifen.

Kommando war damals:
socat TCP4-LISTEN:9999,fork,su=nobody TCP6:[2001:123:22:abc::2]:8083

:)

FHEM auf Debian in ESXi5 VM
Homematic mit HMLAN
Raspi mit Pilight für Relais der Heizung