Kommunikation mit KNX ohne knxd

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

Code: [Auswählen]

                my $header_size=unpack("C",$buf);
                if (length($buf)<$header_size)
                {
                        $hash->{CHUNK}=$buf;
                        return "";
                }soll dann so aussehen:

Code: [Auswählen]

                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

[jw9]

Hallo,

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

Code: [Auswählen]

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:

Code: [Auswählen]

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:

Code: [Auswählen]

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:

Code: [Auswählen]

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:

Code: [Auswählen]

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:

Code: [Auswählen]

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

[jw9]

Welches Gerät ist das?

Das TPUART-USB-Modul von Busware. Verbindet USB direkt mit KNX. Kein LAN dazwischen.

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!

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:

wie 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!

[jw9]

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

Wer allerdings in seinem privaten LAN verschlüsseln muss,

Das ist aber reichlich kurz gedacht.

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!

[jw9]

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.

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!

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]

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