www.mikrocontroller.net

Forum: HF, Funk und Felder µracoli 802.15.4 Packet Capturing with Wireshark Setup-Problem


Autor: Christoph P. (sirbundy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/pgCon...). 
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!

: Verschoben durch Moderator
Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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__grpApp...)

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.

Autor: Christoph P. (sirbundy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... achso als Firmware brauchst du sniffer_psk230.hex, an dem wurde 
definitiv repariert seit Februar.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph P. (sirbundy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
dmesg | grep ttyUSB
 die Portnummer herausfinden, danach
 cd uracoli-xxx
 wireshark -i foo & 
 python Contrib/PacketCapture/ieee802154.py -i foo -p /dev/ttyUSBx
 cmd: chan XX
 (XX der Kanal der beobachtet werden soll) und "Ctrl-E" im wireshark 
druecken, fertig.

Autor: Christoph P. (sirbundy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :)

Autor: Christoph P. (sirbundy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Christoph P. (sirbundy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christoph P. (sirbundy)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, dann werde ich wohl auch demnächst mal einen Upgrade machen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.