Aufbau eines KNXnet IP Telegramms

[bjoernb]

Danke für die schnelle Antwort. Leider steht in dem Dokument ja kaum was nützliches drin. Ich habe den Thread hier mal etwas genauer verfolgt und frage mich, warum meine über Wireshark mitgeschnittenen Pakete dem hier erwähnten Aufbau überhaupt nicht ähneln. Gibt es einen Unterschied zwischen den einzelnen IP-Gateways bzw. IP-Interfaces? Ich kann leider gerade nicht genau sagen, welches Gerät wir in der Uni verwenden. Es ist jedenfalls von Siemens und entweder ein N146 bzw. ein N148. Der Payload der mitgeschnittenen Pakete ist z.B. "10060013020129bc1b280002d5004041c51eb5" wobei ich schon rausgefunden habe, dass der Teil "41c41eb5" Byte 16-19 Nutzdaten sind (vom Temperatursensor mit ca. 25,3°C) und Byte 4 "13" wahrscheinlich bedeutet, dass das komplette Telegramm 19 (0x13 Hex) Byte lang ist. Zumindest deckt sich das mit "0x0F" bzw. 15 Byte Länge die ich bei anderen Paketen bekomme. Alles andere, vor allem die anscheinend gedrehten ersten beiden Bytes, sind mir schleierhaft. Habt ihr irgendeine Ahnung, woran das liegen kann oder was mein Telegrammaufbau zu bedeuten hat?
Als kleiner Hinweis, den ich mir denken könnte: Ich habe die Pakete durch die ETS erzeugen lassen (Rechtsklick auf eine Gruppenadresse und dann "Lesen/Schreiben") welche über USB am Bus hängt und dann die Multicast-Pakete, die über das IP-Gateway rausgehen (bei mir über 239.192.29.238 und Port 51000) mitgeschnitten. Ich hoffe ihr könnt mir ein paar Anregungen geben. Danke!

Gruß
Björn

[Michel]

Leider steht in dem Dokument ja kaum was nützliches drin.

Deswegen kosten die genauen KNX-Spezifikationen ja auch 1.000 € bei der Konnex (KNX Association ::[Official website] KNX Standard How to Order...) für Nicht-Mitglieder oder alternativ zu erwerben z.B. bei beuth.de, wobei ich mir bei letzteren die Mühe erspart habe, die Einzelpreise zu addieren

[swenga]

Ich hoffe ihr könnt mir ein paar Anregungen geben. Danke!

Hast Du dir diesen Fred mal von Anfang an reingezogen? Da stehen alle Infos drin. Vor die Payload hat die ISO die Header der niedrigeren Layer gesetzt, die da Tunneling Request oder Routing Indication heissen...

Etwas verwirrend: Setzt Du jetzt ein Gateway ein (Dann Tunneling uber Unicast) oder einen Router (Routing ueber Multicast)? Deine MC-Adresse ist irgendwie nicht ganz Standard, oder?

mfg

[bjoernb]

Hast Du dir diesen Fred mal von Anfang an reingezogen? Da stehen alle Infos drin. Vor die Payload hat die ISO die Header der niedrigeren Layer gesetzt, die da Tunneling Request oder Routing Indication heissen...

Etwas verwirrend: Setzt Du jetzt ein Gateway ein (Dann Tunneling uber Unicast) oder einen Router (Routing ueber Multicast)? Deine MC-Adresse ist irgendwie nicht ganz Standard, oder?

mfg

Hallo,

ich habe mir alles angesehen und auch die bisherigen Übersichten über den Telegrammaufbau gesehen. Deswegen wundere ich mich ja, dass da bei mir alles anders ist. Ich bin mir sehr sicher, dass es der Siemens-Router ist. Multicast ist es so und so, da die IP eine Multicast-Adresse ist. Hier und hier habe ich auch Hinweise drauf gefunden, dass die Adresse von KNX genutzt wird. Das es eigentlich nicht die Standard-Adresse ist, ist mir auch aufgefallen. Falls noch jemand Infos hat, würde ich mich freuen, die hier zu lesen.

Viele Grüße
Björn

Ich habe mir meine Daten eben noch mal genau angesehen und die Sache wird schon etwas klarer, wenn auch nicht komplett nachvollziehbar:
Bytes 1-7 (10060013020129) sind mir komplett schleierhaft.
Byte 8 ist das Kontrollbyte, Byte 9-10 Quelladresse (1.11.40), Byte 11-12 Zieladresse (0/0/2), danach wie im ersten Post beschrieben gehts mit Routingzähler & Länge der Nutzdaten (5 Byte) weiter.
Danach wird es mit einem Null-Byte schleierhaft. Die darauffolgende 40 könnte das erste Nutzdatenbyte sein und zusammen mit den ersten beiden Bits der 41 darauf hinweisen, dass es ein Response-Telegram ist (war es auch). Was mich daran wundert: 4041 ist 0100000001000001. Die 1 an zweiter Stelle dürfte laut ersten Post in diesem Thread nicht sein. Da es sich um einen 4-Byte-Temperaturwert handelt dürfte auch die letzte 1 nicht sein, da die 6 Bit, die für Nutzdaten zur Vefügung stehen, nicht genutzt werden, wenn sich nicht alle Nutzdaten in 6 Bits darstellen lassen. Wenn zudem die obersten beiden Bits der 41 immer noch für den Befehlstyp genutzt werden würden für die eigentlichen Nutzdaten ja auch nur 3Byte + 6Bit zur Verfügung stehen. Alles sehr komisch...

[swenga]

Hallo Bjoern,

kann es sein dass mit dem Dissector was nicht stimmt, Byte Swap oder so? Ist das wirklich die Payload aus dem UDP-Paket (also Layer 5)?

Das muss mit 0610 0530 <Länge in 2 Bytes> beginnen. Und das macht jeder Router und die ETS so.

mfg

[bjoernb]

Hallo,

danke für die ganzen Tipps. Ich habe das Problem mittlerweile anders gelöst. Anfangs hatte ich ein Gateway und da wir bei uns in der Uni noch einen Router gefunden haben, wurde einfach der mal probiert. Und siehe da: die Pakete kommen auf der Standard-MC-Adresse und sind standardmäßig aufgebaut. So muss das sein :-) Danke tortzdem.

Gruß
Björn

[shadovv1]

Probleme mit Telegramm

Meine Telegramme sehen folgendermaßen aus:

2B 07 03 01 00 04 02 14 D0 B4 31 64 51 02 E0 00 XX AD
2B 07 03 01 00 04 02 9E 77 B4 31 64 51 01 E0 00 XX AE

Das schwarz geschrieben versteh ich gar nicht (leider) das blaue komplett und beim roten hab ich den verdacht das dieser teil fehlt (das Telegramm funktioniert nicht).
Das Telegramm wurde über einen Programmkombi (KNX@Home) und Calimero erschaffen.

Zur erklärung :

B4: wir senden aus irgeneinen grund mit hoher priorität
31 64 : von der PA 3.1.100
5102: An die GA 10/1/2
E0 00: is klar
Aber dann müste doch für das senden der Null 80 kommen oder?
AD bzw AE sind CRC Cheksum die über Xor erstellt wurde

Also zusammenfassend:
Kann mir bitte wer den ersten Teil des Telegramms erklären und ob die 80 hier wirklch nicht mitgesendet wurde

Danke im voraus

shadovv1

[makki]

2B 07 03 01 00 04 02 14 D0 B4 31 64 51 02 E0 00 XX AD

Ja grade XX wär jetzt interessant.. Wurde es ausgeXXt oder fehlt es am Bus? Wer/wie wurde das aufgezeichnet? =UDP-Payload? Routing oder Tunneling? Fragen über Fragen

Das schwarz geschrieben versteh ich gar nicht

Aus dem Kopf: Stichwort KNXnet/IP Header (6 Byte) & HPAI (2 Byte), ist ein Byte übrig.. steht in 3/8/2 +-2 im Standard sicher irgendwo (ich gehe mal davon aus die Dokumente liegen vor, ansonsten ist es reichlich müssig, 5x50 Seiten in häppchen in Forum zu erläutern..)

Das Telegramm wurde über einen Programmkombi (KNX@Home) und Calimero erschaffen.

Über eibd und Verwendung dessen API schonmal in Betracht gezogen? da funktioniert das einfach so, fertig.. Besonders wenn die KNX-Docs nicht vorliegen oder es nicht um die wissenschaftliche Erkenntniss geht, das man das Rad auch dreimal erfinden kann, dürfte das relativ zielführend sein

B4: wir senden aus irgeneinen grund mit hoher priorität

Hmm, sähe ich anders, ((0xB4 & 0xC) >> 2) ergibt 1 = Prio alarm, high wäre 10b oder 2dez (hatte/habe da selbst ein kleines Verständnissproblem zwischen den vielen EMI's und eben je nach Anzeige/Sicht, daher die Frage wie das aufgezeichnet wurde..)

Kann mir bitte wer den ersten Teil des Telegramms erklären und ob die 80 hier wirklch nicht mitgesendet wurde

Falls XX am Bus nicht da, stimmt es, egal wie IMHO nicht, liegt vielleicht an der Länge (Byte #6), aber zum detaillierten nachfieseln ists zu spät heute..

Ich würde versuchen erstmal ein "echtes" KNX-Telegramm eines TLN auf dieselbe Art aufzuzeichnen und dann "zu verstehen", wenn das stimmt lässt sich die Ursache eingrenzen, in dem Fall dann möglicherweise die Komponente die genanntes fabriziert.

Makki

[salixer]

Aus dem Kopf: Stichwort KNXnet/IP Header (6 Byte) & HPAI (2 Byte)

Ist hier nicht der Fall. Der KNXnet/IP Header fängt immer mit 0x06 0x10 (Länge des Headers: 6 Byte, KNXnet/IP Version 1.0) an.

2B 07 03 01 00 04 02 14 D0...

Das ist der Beginn eines cEMI Frames mit Message Code 0x2B. Aufbau des Frames steht im Standard

[shadovv1]

Zitat von shadovv1
2B 07 03 01 00 04 02 14 D0 B4 31 64 51 02 E0 00 XX AD
Ja grade XX wär jetzt interessant.. Wurde es ausgeXXt oder fehlt es am Bus? Wer/wie wurde das aufgezeichnet? =UDP-Payload? Routing oder Tunneling? Fragen über Fragen

Aufzeichnung stammt vom ETS4 Busmonitor über USB

Das Signal wurde über tunneling vom Calimero gesendet.

XX felt ist nich existent bei mir also so : B4 31 64 51 02 E0 00 AD

laut meinen beschreibungen ist b4 hohe priorität und bc die normale

Das Handbuch liegt vor leider in der Ausgabe 1.0 von 1999...
3/8/2 is bei mir noch nicht ausgefüllt

Zum Thema das "Rad" neu erfinden:
Das Projekt KNX@Home bekommt eine Neuauflage mit Calimero NG und die erste (alpha oder beta) version soll noch im april erscheinen. Im moment programmieren wir an der verbindungssoftware zum Calimero und später dann auch an sachen wie GUI und erweiterte funktionen

mfg
shadovv1

[salixer]

Hi,
wirf einen Blick in 3/6/2 und da vor allem unter "4. cEMI".

Den KNXnet/IP-Teil zeigt die ETS nicht an. Dafür siehe: KNXnet/IP Wireshark plugin

[shadovv1]

wirf einen Blick in 3/6/2 und da vor allem unter "4. cEMI".

habt ihr ein anderes handbuch aus der eib handbookseries? Bei mir steht da :

4. PEI Logical Specification

und da steht nix vo cEMI leider

so problem erkannt hab das EIBA Handbook Series und die is etwas veraltet (12Jahre alt)


Wireshark läuft mit plugin wenn ich ergebnisse hab rühr ich mich wieder


So Neuigkeiten:

jetzt spuckt der Busmon von der ETS4 T_Connect aus also hab ich wo anders noch Probleme hatte wer schon ähnlich Probs?

so etz passts und funktioniert wir waren im tp um 1 oktett verschoben das war der ganze käse.. nun funktionierts)

[makki]

Ja, dann gibt das mehr Sinn, ich war etwas auf den Titel KNXnet/IP fixiert Im ETS-Busmonitor auf TP1 sieht man davon natürlich garnichts sondern wie salixer schon schrieb cEMI..

habt ihr ein anderes handbuch aus der eib handbookseries?

Vermutlich: das aktuelle
Wenn ich das richtig in Erinnerung habe aus Pamplona: sollte die FH als scientific member doch auch eine aktuelle Version davon haben (?!)..

Makki

P.S.: Auf diesem Wege vermutlich am einfachsten: im KNX@home-Wiki stehen lauter lustige kyrillische Links..

[shadovv1]

Habe ich das wiki wurde aktualisiert und die links müssten draussen sein (i schau schnell nochmal)


sollte eig nicht passieren, anscheinend haben die neuen sicherheitsfunktionen nicht gefrucht sind drauf und dran das zu ändern

[salixer]

sollte eig nicht passieren, anscheinend haben die neuen sicherheitsfunktionen nicht gefrucht sind drauf und dran das zu ändern

Achtung Off-Topic: Aus eigener, leidlicher Erfahrung kann ich sagen: Ein Mediawiki abzusichern ist Dauerarbeit. In einem eigenen Wiki habe ich schon allerhand Anti-Spam Extensions eingesetzt. Irgendwas kam immer wieder durch. Schließlich habe ich öffentliche Neuregistrierungen gesperrt. Registrierung und damit die Berechtigung zum editieren gibt's jetzt nur noch auf Anfrage. Auch wenn's gegen den Wiki-Gedanken ist, nichts nervt mehr als ständige Spamjagd.
Für mehr Info oder Gedankenaustausch: PN.