Hallo Forengemeinde, Bei µracoli bin ich auf eine freie Sniffer-Möglichkeit für 802.15.4/ZigBee Netzwerke gestoßen (http://www.nongnu.org/uracoli/manual/contrib/pgContribCapture.html). Dafür gibts ne kleine Setup-Anleitung die bis zu Punkt 7 (Python) auch wunderbar funktionierte. Nun krieg ich aber folgenden Fehler nach der Konsoleneingabe (unter Ubuntu Linux) ausgespuckt: Eingabe: "python Contrib/PacketCapture/ieee802154.py -p /dev/ttyUSB0 -i foo" Fehlerausgabe: Traceback (most recent call last): File "Contrib/PacketCapture/ieee802154.py", line 254, in <module> DEVIN.open(CTX.PORT) File "/usr/uracoli-cvs20090201/Contrib/PacketCapture/ieee802154_io.py", line 133, in open self.init() File "/usr/uracoli-cvs20090201/Contrib/PacketCapture/ieee802154_io.py", line 145, in init self.tscale = eval(l.split(":")[1]) File "<string>", line 1, in <module> NameError: name 'TICK_NUMBER' is not defined destruct posix NamedPipe Exception AttributeError: "NamedPipe instance has no attribute 'pipe_handle'" in <bound method NamedPipe.__del__ of <ieee802154_pipe.NamedPipe instance at 0xb7c0fd8c>> ignored Ein flüchtiger Blick auf die Fehlerstelle hat mit nix gesagt (hab von Python aber auch null Ahnung), aber vielleicht hat ja schon jemand ein ähnliches Problem gehabt bzw. nutzt es. Vielen Dank schon mal!
Hallo Christoph, was fuer eine Sniffer-Hardware verwendest du ? Wenn TICK_NUMBER nicht von der Firmware kommt, scheint die serielle Schnittstelle nicht richtig zu funktionieren. Du kannst das pruefen, indem du ein Terminal an /dev/ttyUSB0 oeffnest und Reset durchfuehrst. Dann sollte zumindest der Firmware Identify String auftauchen und der Controller sollte sich auch interaktiv bedienen lassen (http://uracoli.nongnu.org/manual/app/group__grpAppSniffer.html) Die Version vom Februar hat mittlerweile einige Bugfixes erfahren, am besten du nimmst die aktuelle Version 0.0.9 (von gestern). Viele Gruesse, Axel PS: Die Sniffer Pakete fuer Linux/Windows werden in den naechsten Tagen (http://download.savannah.nongnu.org/releases/uracoli/apps) aktualisiert.
Hallo Axel, Ich verwende das Atmel Z-Link Sniffer Kit (STK541). Dies wird ja per USB an den PC angeschlossen. Daher weiß ich nicht, ob das mit der seriellen Schnittstelle weiter von Relevanz ist. Oder wird dafür der USB als virtuelle serielle Schnittstelle verwendet? Zum öffnen von seriellen Schnittstellen habe ich bis jetzt meist Minicom verwendet, wie das nun mit der USB funktioniert weiß ich nicht. Kann deine Tipps also leider gerade nicht sofort in die Tat umsetzen. Heruntergeladen habe ich die uracoli-cvs20090201-src.zip
Hier habe ich mal zusammengetragen, was treiberseitig zu tun ist: (http://uracoli.nongnu.org/manual/dev/pgDevFTDI245.html) Kernpunkt ist, dass die FTDI245er mit nem Atmel Vendor ID versehen sind und somit der Standardtreiber nicht geladen wird. Ab Kernel 2.6.29 sollten alle bekannten STKxxx und sonstigen ID's im Treiber ftdi_sio.[hc] eingetragen sein. Um das zu pruefen: * Board anstecken * dmesg | grep USB usb 3-1: FTDI FT232BM Compatible converter now attached to ttyUSB0 oder ttyUSB1, ttyUSB2, .... * wenn die Zeile nicht da steht, wird der Chip nicht erkannt. Jetzt gibts folgende Wege: * Kernel Module patchen * Kernel 2.6.30 installieren * Mit dem Tool von FTDI die Atmel VID loeschen (Windowstool). * mit dem Loetkolben den ID-EEPROM IC8 entfernen (Wenn du einen der letzten beiden Punkte wählst, geht danach aber ein etwaiger Daintree-Sniffer nicht mehr) Fuer minicom musst du die Schnittstelle /dev/ttyUSB0 auswaehlen. (u.u. brauchst du root Rechte um ein Profil in /etc/minirc.usb0 anzulegen und wahrscheinlich brauchst du die Mitgleidschaft der Gruppe uucp, um auf die Schnittsttelle zugreifen zu koennen).
... achso als Firmware brauchst du sniffer_psk230.hex, an dem wurde definitiv repariert seit Februar.
Axel Wachtler schrieb:
> * mit dem Loetkolben den ID-EEPROM IC8 entfernen
Besser jedoch mit einem Fön. ;-) Mit einem Lötkolben kann man da
ziemlich schnell die Platine demolieren.
Ein Tool zum Konfigurieren des FTDI-EEPROMs gibt es auch in der
FreeBSD ports collection, allerdings ist es meines Wissens nicht
einfach auf Linux zu portieren, da es auf FreeBSD-syscalls aufsetzt
und nicht auf einer libusb.
Gut, also auch in meinem 2.6.28 Kernel hab ich die entsprechenden Codezeilen gefunden. Patches scheint also nicht notwendig. Werd also mit der neuen Version die von dir genannte sniffer_psk230.hex erstellen und dann mal angucken. Vielen Dank erstmal, ich gebe zu gegebener Zeit bescheid wie's ausging.
Kurzer Nachtrag: mit dem Kernel 2.6.29 (getestet mit Gentoo) funktionierte die Erkennung von STK541 und Sensor Terminalboard von Dresden Elektronik als serielle Schnittstelle problemlos out of the box, also anstecken und mit
1 | |
die Portnummer herausfinden, danach
1 | |
2 | |
3 | |
4 | |
(XX der Kanal der beobachtet werden soll) und "Ctrl-E" im wireshark druecken, fertig.
Hallo Axel, Ich danke dir vielmals! Mit der neuen Version klappt es und ich muss sagen, bin echt glücklich! Werd sicherlich nochmal ne Rückmeldung geben, wenn ich mir alles bisschen näher angeguckt hab. Vielen Dank nochmal! :)
So, hier also die versprochene Rückmeldung: Nach netto etwa einem Tag rumprobieren und austesten muss ich sagen, dass alles wunderbar funktioniert. Die Daten kommen problemlos in Wireshark an, die Displayfilter funktionieren wie gewünscht und dass es keinen Capturefilter gibt ist somit auch zu verkraften (liegt ja eh an Wireshark). Das einzige was etwas stört ist die Tatsache, dass es wohl keinen errorfreien Weg gibt, die Aufnahme zu stoppen und zu einem späteren Zeitpunkt eine neue zu starten. Soll heißen, nach Stop Capture in Wireshark muss das Python-Programm beendet und dannach wieder neu gestartet werden. Kann aber auch sein, dass ich mich bei der Bedienung einfach zu holprig anstelle ;) Ist aber auch nur ein ganz kleiner Wermutstropfen.
> Soll heißen, nach Stop Capture > in Wireshark muss das Python-Programm beendet und dannach wieder neu > gestartet werden. Hm, das stimmt, da ist die Bedienung noch etwas unschoen. Ich muss mal etwas ausholen, warum das so ist. ieee802154.{exe,py} verwendet eine "named pipe" um die Daten zu wireshark zu senden. Im Prinzip wird diese named pipe wie ein File angesehen, d.h. wireshark muss zuerst einen PCAP header darin lesen koennen. Dieser PCAP header wird von ieee802154.{exe,py} mit dem Kommando"reopen" erzeugt. Der Ablauf eines Capture-Restart waere dann wie folgt: 1 wireshark capture session schliessen 2 capture save dialog beantworten 3 neue wireshark capture session oeffnen 4 in ieee802154.{exe,py} das Kommando "reopen" eintippen, danach zeichnet wireshark wieder Pakete auf. Falls es zu einem Fehler kommt, dann die Schritte 3 und 4 nochmal wiederholen. Ich weiss das die Methode etwas unbequem ist, ich habe aber keine bessere Idee im Moment. Falls sich mal ein Wireshark-Interna-Kenner hierher verirrt: Ich suche noch eine plattformuebergreifende Methode (Linux, Windows), um wireshark von einem externen Programm aus zu steuern (so aehnlich wie bei den MP3 Playern amarok oder winamp, wo man die Titel per Kommando wechseln kann).
Seit der Version 1.2.0 sind in Wireshark auch die ZigBee-Schichten bzw. der entsprechende Filter implementiert => http://www.wireshark.org/docs/dfref/#section_z Konnte es aber noch nicht ausprobieren, da es in den Ubuntu-Quellen erst mit der 9.10 in die universe-Quellen aufgenommen wird und es außerdem an der Zeit mangelt. Trotzdem sehr schön und es macht immer wieder Spaß die Entwicklung zu verfolgen :)
Christoph P. schrieb: > Seit der Version 1.2.0 sind in Wireshark auch die ZigBee-Schichten bzw. > der entsprechende Filter implementiert => > http://www.wireshark.org/docs/dfref/#section_z Danke für den Hinweis, habe lange nicht mehr bei Wireshark reingesehen. Weil wir gerade darüber sprechen: seinerzeit, als ich mir den 15.4- Support noch selbst ins Wireshark patchen musste, wurde die Korrektheit der FCS immer ordentlich ermittelt. Mit dem offiziellen Wireshark 1.0 dagegen behauptet er immer "FCS OK", egal, was da drin ist. Ich vermute mal, dass das irgendwie mit dem CC2420-Modus zusammenhängt, der ja im Normalmodus gar keinen FCS mit hoch geliefert hat, sondern nur ein "FCS OK"-Flag. Hat sich das mal jemand angesehen, kann man das ggf. irgendwie konfigurieren?
Jörg Wunsch schrieb: > Weil wir gerade darüber sprechen: seinerzeit, als ich mir den 15.4- > Support noch selbst ins Wireshark patchen musste, wurde die Korrektheit > der FCS immer ordentlich ermittelt. Mit dem offiziellen Wireshark 1.0 > dagegen behauptet er immer "FCS OK", egal, was da drin ist. Ich > vermute mal, dass das irgendwie mit dem CC2420-Modus zusammenhängt, > der ja im Normalmodus gar keinen FCS mit hoch geliefert hat, sondern > nur ein "FCS OK"-Flag. Hat sich das mal jemand angesehen, kann man > das ggf. irgendwie konfigurieren? Das Problem unter der 1.0 kann ich bestätigen. Hab nun gestern doch mal fix die Windows-Version ausprobiert und festgestellt, dass dieses Problem behoben wurde. Nun erklärt sich auch das ein oder andere Problem, bei dem man sich vorher gewundert hat sagte "ist doch alles i.O.". Im Anhang hab ich mal nen Bildschirmdruck angehängt.
Angehängte Dateien:
-
Wireshark_Router_Win.PNG
(57 KB)
Danke, dann werde ich wohl auch demnächst mal einen Upgrade machen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.