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]

Gibt´s nachwievor bei der Konnex: http://www.knx.org/fileadmin/downloa...ure%20v3.0.zip und noch mehr unter KNX Association ::[Official website] Downloads / Support Downloads

[bjoernb]

Hast Du hier ab Seite 15 schon mal geguckt?

Uwe

Hallo,

ich beschäftige mich auch gerade mit dem Telegrammaufbau eines KNXnet/IP UDP-Paketes. Ist das Dokument noch irgendwo verfügbar?

Gruß
Björn

[Chris M.]

Ich versuch mich gerade daran, ein Paket an den EIB-Bus über ein EIBNet-Interface zu versenden.

Hi,

zum einen kannst Due den eibd nehmen und den die schmutzigen Details übernehmen lassen. Oder falls Du's unbedingt selbst machen willst, kannst Du dort zumindest in den Source Code schauen...

[latinchriz]

Hallo,

Sorry dass ich das Thema erneut aufgreifen muss.
Ich versuch mich gerade daran, ein Paket an den EIB-Bus über ein EIBNet-Interface zu versenden.
(Simples ein/ausschalten von einer Lampe .. :-) )

Mit Wireshark hab ich mich auch schon gespielt und habe bereits die Nutzdaten des UDP-Pakets ausgelesen.
Dann bin ich heute über den Thread gestolpert und hab mal verglichen mit meinen Daten und (erstaunlicherweiße) sind die verdammt ähnlich ;-).

Was ich mich noch Frage, muss ich mich gegenüber dem Ethernetdevice irgendwie verbinden ? Da ihr da irgendwas von Channel Request redet ?
Reicht es nicht einfach einen Socket aufzumachen und ein UDP-Paket auf die IP&Port des Ethernetdevice zu senden ?

Gibt es mittlerweile eine endgültige Liste was WAS ist im Telegram ?
(Wofür steht Ctrl1/Ctrl2, L TPCI ACPI usw. ?)


DANKE!

[BliBlaBlo]

Kann mich vielleicht mal jemand aufklären wann eine DataConnection gültig ist?
Das komische bei mir ist ja, dass ich im lokalen WLAN immer NO_ERROR bekomme und wenn ich mich per VPN verbinde eben einen Fehler die Daten Verbindung betreffend. Und das obwohl ich über die Datenverbindung sehrwohl schalten kann.

Danke für eure Hilfe

Lg

[BliBlaBlo]

So,
jetzt haut bei mir alles hin. Mein Problem war scheinbar das ich 2 Sockets offen hatte. Einen zum senden und einen zum empfangen und das mag der KNXnet/IP Router scheinbar nicht.

Wenn ich jetzt im lokalen Netz bin, haut alles super hin, nur wenn ich mich mit meinem iPhone über VPN einlogge, kann ich zwar alles schalten und auch die Stati auslesen, aber ich bekomme beim connection state request die Meldung das keine Data Connection mit der specified ID da ist. Das finde ich komisch da es aber ja trotzdem funktioniert...!?!

Lg

[swenga]

Hallo,

Ich habe damals ebenso mit Sniffen der Kommunikation von ETS und Interface angefangen. Wichtig war es bei mir, zuerst den Data-Kanal zu öffnen, um die lokale Portnummer dafuer zu haben. Erst dann den Control-Kanal öffnen und dann beim Connection Request den eigenen Port des Data-Channels angeben.

Man kann natuerlich beim Erstellen des Sockets auch nen eigenen Port vorgeben, aber wehe der ist blockiert....

Als ich keine ACKs geschickt habe, hat der Weinzierl 730 mir immer nur ein Paket gesandt und das auch ein paarmal wiederholt. Nach einigen Wiederholungen dann kam der Disconnect Request auf dem Control-Kanal.

Paralleles Mittel bei meiner Entwicklungszeit war immer der Sniffer und die ETS, hier versuchte ich mich auf einfache Pakete abzustützen, also 1-Bit DPT's. Da findet man dann schnell raus, wie die aufgebaut sind und zu versenden sind.

Mittlerweile ist das Tunneling-Interface beerdigt, es wird nur noch IP-Routing über Multicast gefahren....

[BliBlaBlo]

Genau, nur ein Thread zum Receiven. Hab es aber auch schon versucht mit einem 2. Kanal zum Empfangen und das hat auch nichts geändert...

Lg

[swenga]

Noe, das ACK Paket sieht gut aus. Jetzt bleibt die Frage, ob derselbe Port für Control und Data ein Problem darstellt. Kannst Du das bei Dir anpassen? Warum eigentlich derselbe, wolltest Du nur einen ReceiveThread haben?

mfg Swen

[BliBlaBlo]

Was mir ja aufgefallen ist, ist das ich jedes Paket zwei Mal bekomme. Kann das an meinem ACK liegen? Ich hab das ACK jetzt nämlich mal ausgeschalten und bekomme trotzdem noch Pakete (auch zwei mal) also scheint es so, als würde das KNXnet/IP Gateway einfach nicht auf meine ACKs reagieren...?!?

Das hier wäre ein Bsp ACK das ich schicke:
06100421 000a0417 0400

in dem Fall war ich auf Channel 23 = 0x17 verbunden und es war ein ACK auf ein Paket das als Sequence Count 4 geliefert hat.

Mach ich da was falsch?

[BliBlaBlo]

Richtig... auf den ConnectRequest bekomme ich eine 0x00 als Stauts... also E_NO_ERROR und eine ConnectionID. Das haut alles wunderbar hin...
Nur bekomme ich halt keine ACKs auf Tunneling Requests

[swenga]

Ja, Strukturlänge des Connection Headers, also 4 Bytes.

Also auf dem selben Port Control- und Datenfluss zu handeln hab ich noch nicht probiert. Was kriegst Du denn auf Deinen Connect Request geantwortet? Du muesstest Status 0 und Deine Session-ID zurueckbekommen.

mfg Swen

[BliBlaBlo]

Hallo,

06100420 001e0402 00002b09 03010006 040a3b1e b2bcdb0e 0904e100 81fb
also, schauen wir mal:
0610 Header ok
0420 Tunneling Request, auch ok
001e Paketlänge = 30 Byte
0402 erstes Byte ist die CCH-Länge = 4

Ist der 04er nicht die Structure Länge... also 4
und der 2er die ConnectionID?
Zumindest sagt mir das der Wireshark so

Was zeigt denn die ETS für ein Paket an? Habe auf die Schnelle keine 10Byte-DPTs gefunden....

Die ETS versteht das Paket. Die genaue Aufzeichnung hab ich von dem Paket jetzt nicht mehr...

Wieso bekomme ich eigentlich immer 2 Pakete beim drücken eines Schalters? Ein kurzes und ein langes. Das lange verstehe ich jetzt mittlerweile einigermaßen, aber das kurze nicht.


Btw.:
Bei meiner Kommunikation habe ich noch das Problem dass ich zwar vom KNXnet/IP Gateway (das Weinzierl 730) zwar Datenpakete erhalte, wenn ich aber selbst welche schicke, bekomme ich darauf hin kein ACK. Obwohl ich wirklich Byte für Byte das gleiche schicke wie die ETS (halt mit angepasstem Sequenz Counter) Aber sonst ist alles gleich und ich bekomme keine Antwort.
Wenn ich einen ConnectionState Request schicke bekomme ich den Status E_DATA_CONNECTION (0x26)... also ein Problem mit meiner data connection.
Beim connect haut aber alles hin. Ist es ein Problem das bei mir die Data Connection und die Controlling Connection bei mir am gleichen Port sind? (Abgesehen von der IP und dem Port in HPAI für data und controlling schicke ich auch hier genau das gleiche wie die ETS wenn ich auf Diagnostics->Group Monitor geht und dann da Daten rausschreibe)
Den ConnectionState Error bekomme ich auch wenn ich ihn direkt nach dem connect schicke .


Lg

[swenga]

Hallo,

06100420 001e0402 00002b09 03010006 040a3b1e b2bcdb0e 0904e100 81fb
also, schauen wir mal:
0610 Header ok
0420 Tunneling Request, auch ok
001e Paketlänge = 30 Byte
0402 erstes Byte ist die CCH-Länge = 4
0000 erstes Byte ist die SequenceNumber, 0
Der cEMI-Teil ist nun
2b09 03010006 040a3b1e b2bcdb0e 0904e100 81fb
2b09 hier wuerde ich eigentlich ne 29 00 erwarten, hm
0301 Steuerfeld und Datentyp/Routing, oberstes Bit vom 01-Wert ist Destination-Flag, aus
0006 Sender 0.0.6
040a Destination 0.4.10
3b1e erstes Byte DataLength, allerdings mit 15 unden, also 11
b2bc erstes Byte, obere zwei Bits ReadWrite, Wert 2=Schreiben
Payload des Paketes also 10 Bytes ab
db0e 0904e100 81fb sind aber nur 8, hm komisch....

Was zeigt denn die ETS für ein Paket an? Habe auf die Schnelle keine 10Byte-DPTs gefunden....

mfg

Swen