KNXnet/IP Dissector für Wireshark

[Gaston]

Der erster Versuch unter Windows war wie erwartet ernüchternd

Nachdem Visual Studio 10 installiert war und Ih mich durch den development guide durchgearbeitet hatte und mir daraus eine Prozedur zum compilieren gebastelt hatte lief das make erstmal nicht durch, was zwar nicht weiter verwunderlich ist, aber bei jedem neuen Versuch wurden die fehler schlimmer, bzw. dort Fehler die beim ersten mal durchliefen

Nach vielen Anpassungen lieft das Make diese Nacht durch, und das dauerte über 4 Stunden !!! ...um dann festzustellen dass er mein Plugin stillschweigend "ignoriert" hat

Log gibt's natürlich keins. Also nochmal und mit mit "tee" ein Log schreiben. Dies zeigte dass das Plugin nicht ignoriert wird aber auch nix gemacht wird.

Hab jetzt mak das Makefile für das Plugin verändert. Erneuter export zu windows....und 4 Stunden kompilieren...

Gruss,
Gaston

[Gaston]

Der generierte Code funktioniert so weit für alle DPTs ohne entschlüsselung der Bytes. Bei der Entschlüsselung bin Ich mittlerweile bei DPT 10.xxx angelangt.

Angehängt ein Beipiel einer 16-bit Fliesskommatemperatur DPT 9.001

[Gaston]

So,

Der generierte Code läuft jetzt soweit. Ich habe mal ein Screenshot angehängt wie das im Moment aussieht.

Für diejenigen die das Protokol nicht so genau kennen sei gesagt dass eine Besonderheit des KNX Protokols ist dass die Pakete weder Typen noch genau datenlängen Informationen enthalten. Nur die gesamtlänge der daten in Bytes ist bekannt. Darüberhinaus werden Daten unter 6 bit Länge in das ACPI byte codiert da dieses 6 unbenutzte Bits hat.

Das bedeutet dass der dissector weder den DPT Typ noch dessen bitlänge vom Paket ableiten kann. Er kann nur herausfinden dass der DPT 1-6Bits haben muss, oder 7..8, 9..16, 17..32, etc...

Im Moment geht der dissector hin und decodiert alle DPTs die auf die Datenlänge passen. Ist die Datenlänge z.B. 1 Byte dann weis er dass die bitlänge 7 oder 8 bits sein muss und decodiert alle DPTs mit dieser Lännge.

Dies wir auch voresrt zum Bugfinden auch mal so bleiben. Später ist dann vorgesehen dass DPTs ein default flag haben, und nur solche die dieses gesetzt haben werden auch decodiert. So wird dann z.B bei 1 Bit z.B. nur noch 1 DPT angezeigt werden (DPT_Switch on/off).

Wie man sehen kann werden DPTs mit bitfeldern auch entschlüsselt (z.B. DPT_Control_Dimming im Screenschot)

Gruss,
Gaston

[Gaston]

Die DPT's ändern sich ja nun nicht so häufig und wie der Code generiert wurde ist "Upstream" sicherlich egal (solange es GPL..)

Das mit dem Python hat sich in diesem Kontext von selbst erledigt

Der Python generator kommt daher dass Ich repetitive Aufgabe hasse. Die Idee den ins Makefile zu integrieren rührt deswegen nicht so sehr daher dass die DPTs sich ändern würden (bzw. neue hinzukommen könnten) sondern eher wenn man eine generelle Änderung im Aussehen des dissectors vornehmen möchte. Dann genügt es nämlich den generator anzupassen um alle DPTs in einem Zug zu verändern.

Da der python Generator aber nur Mittel zum Zweck ist, ist sein code mittlerweilse so zum Hack degeneriert dass Ich den niemals OSS machen könnte

Status update: Der Generator generiert jetzt den kompletten code (eine Dissectorfunktion pro DPT inclusive bit decoder, eine dissektor tabelle mit allen DPTs, deine default funktion zum auswälen der DPTs je nach bitlänge der Daten im CEMI frame). Mit der Tabelle wird es dann später möglich sein die DPTs per ETS export zu wählen.

Das ist was im Momnet generiert wird, Ich hab nicht gesagt dass das generierte fehlerfrei sei

Gruss,
Gaston

gruss,
Gaston

[makki]

LOL

Ich denke wir wissen, was wir meinen.. Wenn die Falken halt nicht landen sondern abstürzen

Das Python Modul das daraus den C-Code generiert nimmt so langsam form an.

Die DPT's ändern sich ja nun nicht so häufig und wie der Code generiert wurde ist "Upstream" sicherlich egal (solange es GPL..)
Mensch, das muss, ich will nach dem übernächsten Ubuntu-Upgrade das nicht wieder zusammenfrickeln müssen

Makki

[Gaston]

Nur wenn das kein Otto-normal benutzen kann ist das halt schade..

ACK

wir haben noch drei Tage das für den KNX-award einzureichen (oder hat schonmal jemand den ETS-Busmonitor 3 tage am stück durchlaufen sehen? das wär nen Preis Wert..)

LOL

Kleiner Status update: Ich habe zur Zeit so ca die ersten 60 DPTs definiert, dh in einer "Beschreibungssprache" die Felder, Bitfelder, Formate, Werte und Einheiten beschrieben.

Das Python Modul das daraus den C-Code generiert nimmt so langsam form an.

Gruss,
Gaston

[makki]

Ich denke wir haben etwas aneinander vorbei geredet

Wohl

Ich glaube da reden wir aneinander vorbei. Mein Ziel ist es das ganze binär zur Verfügung zu stellen so dass man das nur in den Plugin ordner kopieren muss.

Schon wieder, vieleicht spreche ich zu undeutlich

Jedenfalls, was ich damit schon mehrfach "sanft" rüberbringen wollte (ist ja nicht nur auf Gaston bezogen!): das ist super! absolut!
Nur wenn das kein Otto-normal benutzen kann ist das halt schade..

Ich selbst benötige es 2x in der Woche und frickle mich halt dann auch durch Makefile.am aber das ist nicht die Regel und auch keine Lösung.. Nur so als Denkanstoss, wenn ich OSS mache freue ich mich darüber, wenn Otto sie auch benutzen kann..

Mein Ziel für dieses Mini-projekt

Für Wireshark ist es sicher eher ein Mini-Projekt, für KNX ein Meilenstein, wir haben noch drei Tage das für den KNX-award einzureichen (oder hat schonmal jemand den ETS-Busmonitor 3 tage am stück durchlaufen sehen? das wär nen Preis Wert..)

Makki

[Gaston]

Das wäre sehr schade!
Begründung: Ich für mich bekomme das ja wohl hin, aber die breitere Masse hat niemals was davon, Otto editiert kein Makefile.am oder wirft einen gcc an

Ich glaube da reden wir aneinander vorbei. Mein Ziel ist es das ganze binär zur Verfügung zu stellen so dass man das nur in den Plugin ordner kopieren muss.

Auch wenn ich davon nur 30% verstehe, könnte ich mich da evtl. einbringen

Es ist nicht so dass ich autoconf und consorten nich tkenne da ich schon einige projekt edamit aufgesetzt habe und ein script geschrieben habe das dies auch automatisch macht.

Mein Ziel für dieses Mini-projekt ist es einfach das ganze auf Linux und Windows zum Laufen zu bringen.

Das geht vermutlih mal garnicht, aber auch das sollte sich lösen lassen; wirklich programmieren kann ich nicht, aber scripten eigentlich schon

Ursprünglich war das erste Skript ein bash script, wurde aber dann so kompliziert dass Ich es in python neu geschrieben habe. Das Skript für die DPTs ist aber viel komplexer als das Erste. Dieses hatte Ich auch erst in Python "Spaggethi"-Code geschrieben bevor Ich es Objektorientiert gemacht haben um die Komplexität des Codes zu reduzieren.

[salixer]

Ansonsten haben wir eine Themaverfehlung, oder was hat der EibPC noch gleich mit einem KNXnet/IP-Dissector für das Standard-tool in Netzwerkfragen zu tun, wenn er kein KNXnet/IP spricht ?
Nochmal sorry..

Es ging hier nur darum, dass man keine KNXnet/IP Telegramme im Wireshark sieht, wenn im EibStudio die Telegrammanzeige läuft. Das EibStudio unterhält sich eben nicht über KNXnet/IP mit dem EibPC, es erfüllt ja einen ganz anderen Zweck (Programmierung des EibPC, Infoanzeigen, etc.). Zum Loggen muss ohne KNXnet/IP Routing eben die ETS mit Gruppenmonitor laufen, oder...

Welche? Das ist alles schrott, das beste was ich kenne ist eben jenes hier diskutierte

...man kauft sich die Hardware, die für anständige Wireshark-Benutzung nötig ist: einen Switch mit Monitoring. Damit sieht man dann auch direkt die Kommunikation des EibPCs mit der KNXnet/IP-Schnittstelle.

Ich denke wir haben etwas aneinander vorbei geredet

[makki]

Dann braucht man eben einen Monitoringport am Switch.

Nicht für Routing (Multicast, von dem ich bekanntermassen wenig halte)

Daheim habe ich z.B. so etwas auch nicht und habe es auch noch nie vermisst

dann hast Du dort wohl noch nie ein Netzwerkproblem gesucht & gefunden

Ich sehe keinen Grund, warum sich ..

der Grund ist (in diesem Kontext zumindest!) ganz einfach: weil man das dann mit unabhängigen Standard-Werkzeugen diagnostizieren kann. Ich bin mir bis heute nicht sicher, ob der HS die Telegramme falsch mit Prio:System rausschickt oder..
Jedenfalls stehe ich auf dokumentierte Standards, deswegen macht ein WG das (dank eibd) auch so, wenn man seine eigene Suppe dazukochen will und denkt das diese sinnvoll ist, können wir in diesem Kontext weiterreden, wenn es zu dieser prop. Suppe dann auch einen Wireshark-Dissector gibt
Ansonsten haben wir eine Themaverfehlung, oder was hat der EibPC noch gleich mit einem KNXnet/IP-Dissector für das Standard-tool in Netzwerkfragen zu tun, wenn er kein KNXnet/IP spricht ?
Nochmal sorry..

soll sich die entsprechende Hardware kaufen

Welche? Das ist alles schrott, das beste was ich kenne ist eben jenes hier diskutierte

[*]Upstream wird er wohl nie gehen weil

Das wäre sehr schade!
Begründung: Ich für mich bekomme das ja wohl hin, aber die breitere Masse hat niemals was davon, Otto editiert kein Makefile.am oder wirft einen gcc an

[*]ich ihn wohl nicht für autoconf anpassen werde (nicht ausgeschlossen)

Auch wenn ich davon nur 30% verstehe, könnte ich mich da evtl. einbringen

[*]python für den build benötigt wird

Das geht vermutlih mal garnicht, aber auch das sollte sich lösen lassen; wirklich programmieren kann ich nicht, aber scripten eigentlich schon

.. werde Ich mich definitiv einem Windows Build widmen

Was halt essentiell dafür ist, das sowas 99% auch irgendwie sinnvoll finden.. ist halt so..

Makki

[joggele777]

Wenn auf der gleichen Workstation die ETS mit Gruppenmonitor läuft, dann solltest du auch etwas sehen.

So habe das nun mit dem Gruppenmonitor ausprobiert - und siehe da nun sehe ich auch im Wireshark die entsprechenden KNX Pakete!

Vielen Dank nochmals für den Tip!

Grüsse
Jochen

[salixer]

Hmm, sorry, wer hat die ETS oder deren Busmonitor mit ihrem Abstürzenden Vogel schonmal mehr als 24h am Stück funktionierend gesehen? Deswegen wünschen sich vielleicht manche einen Dissector für Männer-Programme wie Wireshark (vormals Etherreal fürs Log), wo sowas einfach geht

Dann braucht man eben einen Monitoringport am Switch. Und den haben wohl die wenigsten an ihrem Popelgerät. Daheim habe ich z.B. so etwas auch nicht und habe es auch noch nie vermisst

Deswegen sind Standards auch sowas verdammt gutes

Ich sehe keinen Grund, warum sich der EibPC mit dem EibStudio über den "tollen" KNXnet/IP-Standard unterhalten sollte, um die Telegramme anzuzeigen. Wer Superduper-Debugging mit Wireshark will, soll sich die entsprechende Hardware kaufen

[Gaston]

Klar.. daher nochmal der Aufruf: bis das (hoffentlich!) im Upstream ist, wird sich doch hier bitte jemand finden der bei VS keine Pickel bekommt und das bauen kann!?!
Verteilen dessen ist kein Problem..

Was meinen Dissektor in diesen Punkten angeht:

• Upstream wird er wohl nie gehen weil
  • ich ihn wohl nicht für autoconf anpassen werde (nicht ausgeschlossen)
  • python für den build benötigt wird
  • ich nicht die Zeit habe um sie zu investieren um die benötigten standards einzuhalten
• Ich bin auch kein Freund von VS sondern benutze i.d.R. Codegear RAD Studio C++ (früher Borland C++ Builder)
• Wenn der Dissektor soweit fertig bin werde Ich mich definitiv einem Windows Build widmen

[makki]

Weitermachen

Wenn auf der gleichen Workstation die ETS mit Gruppenmonitor läuft, dann solltest du auch etwas sehen.

Hmm, sorry, wer hat die ETS oder deren Busmonitor mit ihrem Abstürzenden Vogel schonmal mehr als 24h am Stück funktionierend gesehen? Deswegen wünschen sich vielleicht manche einen Dissector für Männer-Programme wie Wireshark (vormals Etherreal fürs Log), wo sowas einfach geht

Ausserdem dürften die meisten den unter Windows wollen

Klar.. daher nochmal der Aufruf: bis das (hoffentlich!) im Upstream ist, wird sich doch hier bitte jemand finden der bei VS keine Pickel bekommt und das bauen kann!?!
Verteilen dessen ist kein Problem..

..schickt dabei auch keine KNXnet/IP Telegramme

Deswegen sind Standards auch sowas verdammt gutes

Makki

[Gaston]

Sollte nicht alzu lange dauern.

Kurzes Update:

Wird wohl doch etwas länger als angedacht dauern, da Ich mich entschlossen habe alle 230 DPT Typen in einem Durchgang einzubauen.

Der erste Grund ist weil Ich den Code dann besser optimieren kann als wenn ich zuerst einige wichtige herauspicke und später merke Ich hätte mir viel Arbeit sparen können wenn Ich das Entschlüsseln anders aufgebaut hätte.

Später soll dann die Möglichkeit eingebaut werden ein projekt aus der ETS zu importieren um dann die richtigen Datentypen anzuzeigen sofern sie dort definiert sind. Aber zumindest wird die Datenlänge dann bekannt sein.

Ich habe mir nun die DPT Tabelle aus den Spezifikationen in eine Textdatei gezogen und schreibe ein Pythpn tool das mir den Grossteil der Codes generieren sollte. Mal sehen was die Zeit hergibt...

Gruss,
Gaston