Kommunikation mit KNX ohne knxd

Begonnen von jewuma, 29 April 2018, 15:13:03

Vorheriges Thema - Nächstes Thema

anatius

Sehr cooles Paket! Und ich werde (hoffentlich) endlich den KNXD los - der benimmt sich wie eine Diva bei mir...

Problem ist allerdings, dass KNXTUL laufend FHEM zum Absturz bringt mit:

'x' outside of string in unpack at ./FHEM/00_KNXTUL.pm line 181.

Was kann ich an Infos bereitstellen, um das Problem einzugrenzen?

Danke und Grüße aus Hamburg!
Christian

erwin

HI Anatius,
bin jetzt nicht der experte für den KNXTUL,
evtl. könntest du folgende Änderung an der KNXTUL versuchen:
statt bisher:
ab Zeile 175:                my $header_size=unpack("C",$buf);
                if (length($buf)<$header_size)
                {
                        $hash->{CHUNK}=$buf;
                        return "";
                }

soll dann so aussehen:
                my $header_size=unpack("C",$buf);
                return if ($header_size < 6); # discard chunk -  must be invalid frame   
                if (length($buf)<$header_size)
                {
                        $hash->{CHUNK}=$buf;
                        return "";
                }

danach ein shutdown restart... und warten.... Der Fehler tritt nur auf, wenn die Kommunikation mit dem KNX-Router nicht ganz rund läuft....
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

jw9

Hallo,

ich versuche KNXTUL einzubinden, komme aber nicht so richtig weiter. Für der ersten Test habe ich folgendes definiert:


define KNXIP KNXTUL 1.1.249
setuuid KNXIP 6000d69f-f33f-4bd1-4fe9-9d08f13388479817
attr KNXIP room KNX
attr KNXIP verbose 5

define Roll_EZ KNX 3/1/14:dpt1.008:Roll_EZ KNXIP
setuuid Roll_EZ 6000d69f-f33f-4bd1-1b50-3af1e2b1737f14f5
attr Roll_EZ IODev KNXIP
attr Roll_EZ room KNX
attr Roll_EZ webCmd on:off


Nach dem Start von FHEM steht im Logfile lediglich:


2021.01.15 00:46:34 5: KNXTUL - Read started
2021.01.15 00:46:34 5: No useable Messageheader: 0002


Wenn ich ein "set" mache, passiert rein gar nichts. Auch die LEDs am Router reagieren nicht. Im Logfile erscheint dann lediglich:

2021.01.15 00:51:13 5: No useable Messageheader: 0002
2021.01.15 00:51:17 5: KNXTUL - Write started
2021.01.15 00:51:17 5: KNXTUL: sending C w0310e00
2021.01.15 00:51:17 5: KNXTUL_encode_eibd: dst: 0310e apci: 2 datalen: 1 data: 0
2021.01.15 00:51:17 5: KNXTUL_sendGroup: dst: 0310e, msg: 6414 1 0 128

2021.01.15 00:51:17 5: KNXTUL_sendRequest: 224.0.23.12:3671 msg: 0610053000112900bcd00005190e010080

2021.01.15 00:51:17 5: KNXTUL - Read started
2021.01.15 00:51:17 5: RawMessage read: 2900bcd00005190e010080
2021.01.15 00:51:17 5: Message read - CtrlByte: 11010000 Source: 0005 Dest: 190e Data: 0080
2021.01.15 00:51:17 5: KNXIP: dispatch C00005w0310e00
2021.01.15 00:51:17 5: enter parse: hash: HASH(0x563e0cedcf78) name: KNXIP, dest: 0310e, msg: C00005w0310e00
2021.01.15 00:51:17 5: exit parse


Als Router verwende ich einen MDT SCN-IP100.03

Kann mal jemand schreiben, wie der Router konfiguriert werden muss, damit er die Pakete auch annimmt und durchreicht?

Im ETS habe ich bei Allgemein "Alle Telegramme weiterleiten" und bei Hauptlinie(IP) sowie bei Linie(KNX TP) "Gruppen weiterleiten, Physikalische filtern" eingestellt.

Wer hat eine Idee, woran es hier scheitert?

jw9

Hallo nochmal,

ich habe jetzt mal in die Funktion KNXTUL_Read eine zusätzliche Debug-Zeile eingebaut. Es scheint so, dass da tatsächlich Telegramme übermittelt werden, allerdings in einem anderen Format als KNXTUL diese erwartet

Im Ruhezustand empfängt KNXTUL im Abstand von 10 Sekunden (evtl Zeitstempel?) folgende Telegramme:

2021.01.15 22:15:33 3: KNXTUL hexmessage:000274ed2a170083714009243f3e999b3332fadce3233f858c4aefdac039
2021.01.15 22:15:43 3: KNXTUL hexmessage:000274ed520d00837140092452ec5d1f5573aec6b4c13f1f2224fe231c03
2021.01.15 22:15:53 3: KNXTUL hexmessage:000274ed79ef008371400924114a34bcee6771646cbdcc40ca2e5ac33e3f
2021.01.15 22:16:03 3: KNXTUL hexmessage:000274eda177008371400924b1d827a55ee2bd1b22df22d36add20bbc6ed
2021.01.15 22:16:28 3: KNXTUL hexmessage:000274ee00f90083714009247fa2bbe56c62edf9c1c4ec1687e3f1f52534
                             061009550024000274ee00f90083714009247fa2bbe56c62edf9c1c4ec1687e3f1f52534

Die letzte Zeile zeigt, wie Wireshark die Nutzdaten anzeigt. Da hat KNXTUL offensichtlich schon 6 Bytes Header entfernt. Ausserdem kann auch Wireshark das nicht dekodieren, denn es zeigt die Nutzdaten lediglich als Raw-Data an.

Wenn KNXTUL was sendet (GA 3/1/14, wie in obigem Beispiel), dann sieht das so aus:

2021.01.15 22:15:49 5: KNXTUL - Write started
2021.01.15 22:15:49 5: KNXTUL: sending C w0310e01
2021.01.15 22:15:49 5: KNXTUL_encode_eibd: dst: 0310e apci: 2 datalen: 1 data: 1
2021.01.15 22:15:49 5: KNXTUL_sendGroup: dst: 0310e, msg: 6414 1 0 129
2021.01.15 22:15:49 5: KNXTUL_sendRequest: 224.0.23.12:3671 msg: 0610053000112900bcd00005190e010081
2021.01.15 22:15:49 5: KNXTUL - Read started
2021.01.15 22:15:49 3: KNXTUL hexmessage:2900bcd00005190e010081
2021.01.15 22:15:49 5: RawMessage read: 2900bcd00005190e010081
2021.01.15 22:15:49 5: Message read - CtrlByte: 11010000 Source: 0005 Dest: 190e Data: 0081
2021.01.15 22:15:49 5: KNXIP: dispatch C00005w0310e01
2021.01.15 22:15:49 5: enter parse: hash: HASH(0x55d844bc89c8) name: KNXIP, dest: 0310e, msg: C00005w0310e01

Dieses Telegramm kann Wireshark dekodieren und zeigt es brav als KNXnet/IP an.

Wenn ich eine Taste drücke (gleiche GA, 3/1/14), dann schaut es so aus:

2021.01.15 22:16:09 3: KNXTUL hexmessage:0000000274edb69b0083714009240000393f8377df07eab2646ce3e9880644577fa10bbdf074be1b396fef6ca479cb9636bf
2021.01.15 22:16:12 3: KNXTUL hexmessage:0000000274edc370008371400924000055f8289a40cb89724cf1b2d533021bdcab681b10953ea4229bfdc82f64a96fb1abe5
2021.01.15 22:16:15 3: KNXTUL hexmessage:0000000274edce9d0083714009240000364acc809b186a0c226b444885a06a6bbedac2c473694f272cbd475fdd9776b1970a
2021.01.15 22:16:18 3: KNXTUL hexmessage:0000000274edd92c0083714009240000e0cc35221f62f253c2accc88b5d501bd8cc6824bc3194a3aaa34ebe9a108b0586f82
                             0610095000380000000274edd92c0083714009240000e0cc35221f62f253c2accc88b5d501bd8cc6824bc3194a3aaa34ebe9a108b0586f82

Auch das kann Wireshark nicht dekodieren und stellt es als Raw-Data dar (letzte Zeile)

Auffällig ist, dass die Daten doch sehr unterschiedlich ausschauen, obwohl es in allen drei Telegrammen die gleich GA ist (abwechselnt on und off)

Sieht also ganz danach aus, als ob der Router die Telegramme ganz anders kodiert als KNXTUL. Da in den Telegrammen die GA nicht zu erkennen ist, könnte das sogar (teilweise) verschlüsselt sein.

Ideen?

GammaTwin

Grüße,

der Router hat in der Beschreibung folgede Begriffe "Mit IP Secure und KNX Data Secure". Ich denke, Du kannst in der ETS das Secure deaktivieren und dann mal probieren. Wenn es dann klappt, würde es an diesem Feature liegen.

Ein Versuch ist es Wert...

jw9

In der Tat lag das Problem am "KNX IP Secure"

Habe jetzt die Anbindung über ein TPUART-Modul gemacht. Damit hat fhem eine direkte Anbindung an KNX, ohne dass die Pakete über LAN/WLAN gehen müssen..

netpirat

Hallo,

wie genau habt Ihr das mit dem IP Secure gelöst?

Ich stehe jetzt vor dem selben Problem.

Gruß

jw9

Gar nicht. Mit dem TPUART-USB-Modul ist kein IP mehr dazwischen. Kommunikation erfolgt direkt mit dem Bus.

erwin

Welches Gerät ist das?

Bei den Gateways von Weinzierl lässt sich das IP-secure deaktivieren... (mit Hilfe der ETS). Evtl in der Beschreibung lesen.
und dann steht der Verwendung nichts im Weg.
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

jw9

Zitat von: erwin am 25 Januar 2021, 18:02:38
Welches Gerät ist das?
Das TPUART-USB-Modul von Busware. Verbindet USB direkt mit KNX. Kein LAN dazwischen.

Zitat
Bei den Gateways von Weinzierl lässt sich das IP-secure deaktivieren... (mit Hilfe der ETS).
Gute Idee! Verschlüsselung ist nur was für Weicheier!

Zitat
und dann steht der Verwendung nichts im Weg.
Muss ich nicht haben... Über mein LAN gehen nur verschlüsselte Pakete.

YMMV!

erwin

.. Allerdings war die Frage:
Zitatwie genau habt Ihr das mit dem IP Secure gelöst?

und aus deinem Beitrag kann ich nichts konstruktives dazu erkennen, und security im LAN ist ein ganz anderes Thema.
Wer allerdings in seinem privaten LAN verschlüsseln muss, muss konsequenterweise auch auf dem TP1 verschlüsseln! Das geht zwar technisch aber sicher nicht mit dem TP-UART-Modul!
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

jw9

Zitat von: erwin am 25 Januar 2021, 21:19:38
.. Allerdings war die Frage:
und aus deinem Beitrag kann ich nichts konstruktives dazu erkennen, und security im LAN ist ein ganz anderes Thema.
Na dann lies noch einmal: GAR NICHT! Da geht gar nichts über das LAN, somit besteht auch kein Bedarf an KNX IP Secure!

ZitatWer allerdings in seinem privaten LAN verschlüsseln muss,
Das ist aber reichlich kurz gedacht.

Zitat
muss konsequenterweise auch auf dem TP1 verschlüsseln! Das geht zwar technisch aber sicher nicht mit dem TP-UART-Modul!
Wieso soll das mit dem TP-UART nicht gehen? Das Modul reicht Pakete transparent durch. Wenn das Modul verschlüsselte Pakete erhält, dann werden diese auch verschlüsselt weitergeleitet. Die Verschlüsselung müsste im FHEM-Modul erfolgen.

Aber Verschlüsselung auf TP! ist derzeit sowieso noch Zukunftsmusik.

erwin

Um das jetzt zu klären,
mein reply gestern um 18:02 war nicht für dich gedacht, sondern auf die Frage von netpirat!

Ich kann durchaus deine Anforderung Verschlüsselung im Lan akzeptieren, hab überhaupt kein Problem damit.
Allerdings haben möglicherweise andere User diese Anforderung nicht, und auch das sollte man akzeptieren, bzw. Hilfestellung geben dürfen!
Bis vor 2 Jahren gabs m.W. noch keine Gateways mit KNX-NET/IP secure am Markt, und sehr viele User hier haben Geräte, die das einfach nicht können. Und zum Thema security im LAN gibts viele Lösungen, nicht nur Verschlüsselung - aber das gehört nicht hierher.

PS: ich denke weder kurz noch nenne ich jemand Weichei, ob er/sie nun verschlüsselt oder nicht. Und: "Gar nicht" fällt beim mir nicht unter konstruktive Antworten, sorry!
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

jw9

Zitat von: erwin am 26 Januar 2021, 01:11:07
Allerdings haben möglicherweise andere User diese Anforderung nicht, und auch das sollte man akzeptieren, bzw. Hilfestellung geben dürfen!
Das Internet ist voll von Zombies, derer User diese Anforderung nicht haben. Leider.

Zitat
Und zum Thema security im LAN gibts viele Lösungen, nicht nur Verschlüsselung - aber das gehört nicht hierher.
Ich denke schon, dass das Thema Security zu einer Heimautomatisierung dazugehört. Immer mehr Geräte wollen angeschlossen werden und nur ein Bruchteil davon erhält regelmässige Sicherheitsupdates. Und ausgerechnet Provider-Router sind häufig auf einem erschreckend alten Firmware-Stand.

Better safe than sorry!

Zitat
Und: "Gar nicht" fällt beim mir nicht unter konstruktive Antworten, sorry!
Oh, ich finde das ist sogar sehr konstruktiv. Du hättest halt auch die anderen beiden Sätze lesen müssen.

Noch einmal ganz ausführlich: So ein TPUART-Modul kostet nur einen Bruchteil desssen, was ein KNX-Router kostet. Damit sind auf einen Schlag sämtliche denkbaren Angriffsvektoren über LAN/WLAN zuverlässig eliminiert. Ohne physikalischen Zugang zum grünen Kabel hat ein Angreifer NULL Chance.

Viel konstruktiver geht es eigentlich gar nicht...

PS: Selbstverständlich bildet der fhem-Rechner selbst auch weiterhin noch einen Angriffspunkt. Aber das ist ein ganz anderes Thema.


Amenophis86

Zitat von: jw9 am 26 Januar 2021, 09:38:29
Ich denke schon, dass das Thema Security zu einer Heimautomatisierung dazugehört.
....
PS: Selbstverständlich bildet der fhem-Rechner selbst auch weiterhin noch einen Angriffspunkt. Aber das ist ein ganz anderes Thema.

Dann lasst uns in diesem Thread doch jetzt bitte diese beiden Punkte besprechen und nicht mehr das eigentliche Thema ;)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...