Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
KNXIP dissector für Windows 32/64 und Linux 64 bit.
Bei problemen benötige ich das Capture file. Wenn jemand Paket sieht con den Typen die noch nicht decodiert werden (siehe RAEDME) dann wäre Ich für das Capture-File dankbar.
Feedback positiv & negativ ist auch willkommen
P.S.: Dieser Dissector läuft am 31. März aus
P.P.S.: Der Dissector wurde mit V1.6.4 entwickelt sollte aber auch auf anderen Versionen laufen (1.6.3 unter Windows getestet)
Nene, ich meinte das schon allgemein, ich mache das jeden Tag und 32bit mehr bedeuten in meiner Welt 80% mehr troubles
Ohne mich jetzt auf eine Polemik über Sinn und Unsinn von 64-bit bei Applikationen einzulassen (immerhin arbeite Ich schon seit über 15 Jahren mit einem 64-Bit Betriebssystem) so ist IMHO 64-Bit bei den Betriebssystemen heute der Standard und das ist gut so. Wenn der Prozessor, wie bei Intel, dann auch noch 32-bit kann, so ist das technisch gesehen zwar Interessant aber für die Entwickler ein realer Mehraufewand das stimmt.
Richtig haarig ist es mit Applikationen die es in beiden "Geschamacksrichtungen" gibt und die Plugins unterstützen (z.B. Wireshark, Office,...) da man hier in das Dilema geraten kann dass es ein Plugin nur auf 32-bit das andere nur auf 64 gibt, man also nie beide zusammen nutzen kann.
Dies gesagt gibt es wohl bei den ersten Versionen doch keine 32-Bit auf Linux da Ich es nicht geschaft habe eine 32-bit Version auf meinem 64-bit Linux zu compilieren. Das autoconf sieht zwar einige optionen dafür vor scheint dann jedoch selbst nicht an allen Stellen (z.B. GTK) danach zu sehen. Ich muss da noch ein wenig rumexperimentieren und dann u.U. in einer VM compilieren
Hab jetzt nicht nachgelesen aber gibts die per Standard überhaupt theoretisch ? (AFAIK: nein)
Aba sicha gibts die , nur nicht für "routing" Packete. Bei den anderen Servicearten (z.B. tunneling) ist TCP optional ausser bei "remote logging" da ist UDP optional und TCP muss unterstützt werden.
Linux, 64 Bit & Experimente? Das läuft doch schon ewig problemlos
Nene, ich meinte das schon allgemein, ich mache das jeden Tag und 32bit mehr bedeuten in meiner Welt 80% mehr troubles und 100% mehr Aufwand für jedes intern gepfegte Paket: doppelt bauen, ich komme mit den 2GB/Anwendung gut aus und für den Rest hab ich keine Zeit weil IMHO 99% unnötig
(ausgenommen FF, der ab 50++ Tabs mal gern mehr als 2GB hätte, das ist aber ein memleak-Problem, das man bitte nicht mit 64Bit OS lösen sollte)
Der Dissektor funzt im Moment nur für UDP Pakete. Hab bei mir auch noch keine TCP Pakete gesehen. Falls jemand TCP KNXnet/IP Pakete hat so waäre Ich an einem Wireshark cap file interessiert mit solchen paketen um den Dissektor anzupassen.
Linux, 64 Bit & Experimente? Das läuft doch schon ewig problemlos
Ich denke makki spricht von der Wireshark 64-bit version , nicht von Linux
Ich bin im Moment dabei noch einige der wichtigen KNXnet/IP service codes einzubauen (Connect, Connection State, Search, Disconnect) und werde dann mal eine Alpha Version zur Verfügung stellen.
Ich hatte eigentlich geplant nur 64-bit Alpha-Versionen zu releasen, werde aber dann beide machen.
Flaws in einem KNXnet/IP Wireshark-Dissector zu finden halte ich für sinnvoller, die 64Bit-Experimente sollen mal bitte andere Enthusiasten machen, die daran glauben
Linux, 64 Bit & Experimente? Das läuft doch schon ewig problemlos
Äh, Voranmeldung, ich hätte dann gerne 32bit für Ubuntu (oder eben den Source zum selber-kompilieren), für 0.0.64-Experimente auf Produktivsystemen habe&ver(sch)wende ich genausoviel Zeit wie für IPv6: Null.Null
Flaws in einem KNXnet/IP Wireshark-Dissector zu finden halte ich für sinnvoller, die 64Bit-Experimente sollen mal bitte andere Enthusiasten machen, die daran glauben
Gaston, jetzt fehlt mir nur noch ein SVN, GIT/whatever wo das zum testen liegt
Source wird es erst mal keine geben. Ich denke Ich werde in Kürze mal 2 64-bit Verssionsn (Linux & Windows) als library zum Testen releasen. Diese Tests releases werden allerdings Zeitlich begrenzt sein.
Aber keine Angst, das bedeutet nicht dass Ich den irgendwann verkaufen möchte. Ich möchte nur nicht dass diese ganz frühen Versionen ewig rum geistern.
Status: DPTs sind bis 20.xxxx inklusive alle entschlüsselt
(ich überlege mir nur wegen einem gewissen Buildroot seit Wochen dafür eine SSD anzuschaffen, damit die Fehlersuche nicht immer mind. 30min dauert)
SSD hst mich nachhaltig beeindruckt. Bei dem Wechsel vom alten Laptop (8 Jahre; Pentium M 1,4 GHz) auf den neuen (i7, SSD + HDD) merke ich den anderen Prozessor kaum, die SSD bei jedem Boot sehr deutlich.
Gaston, jetzt fehlt mir nur noch ein SVN, GIT/whatever wo das zum testen liegt
Das VS sowie auch (auto)make teils grobe körperliche schmerzen bereitet: ist halt so (ich überlege mir nur wegen einem gewissen Buildroot seit Wochen dafür eine SSD anzuschaffen, damit die Fehlersuche nicht immer mind. 30min dauert)
Die 4 Stunden kamen wohl davon dass Ich auf einem samba share compiliert habe. Local läuft das ganze ganz flott.
Windows version funktioniert jetzt. Prozedur müsste 32 & 64 bit erstellen können. Habe jetzt mal 64-bit getestet, mit 1.6.4 compiliert und in 1.6.3 getestet.
Mit meinen Generatoren ein Makefile zu erstellen das sowohl auf Linux wie auch auf Windows läuft war ein Spagat-Akt.
naja, Ich wusste nicht ob sich das auf meine text bezog oder auf das Protokol. Falls das Protokol damit gemeint ist dann tust Du Ihm unrecht denn auch wenn das protokoltechnisch komplex ist so ist das jedoch sehr gut durchdacht da bei den Geschwindigkeiten von TP & PL die Ersparnis jedes Bits eine gute Sache ist.
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.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: