Problem mit uracoli sniffer / Python-Skript bleibt vermutlich hängen

[Dennis H. (dennis_h)]

Hallo zusammen,
um in einem ZigBee-Netzwerk nach Fehlern zu suchen verwende ich 
Wireshark und uracoli sniffer (http://www.nongnu.org/uracoli/).
Wenn in dem Netzwerk wenig Verkehr ist, funktioniert dies auch eine Zeit 
lang sehr gut. Nach einiger Zeit bzw. bei einem höheren Datenaufkommen 
bricht das Python-Skript aber mit einer Fehlermeldung ab.
Genau diese Netzwerkverkehrsspitzen möchte ich aber gern aufzeichnen.

Fehlermeldung:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 525, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.6/threading.py", line 477, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/carsten/Entwicklung/SnifferExt/PacketCapture_ext/ieee802154_io.py", line 240, in __rx__
    self.state,frm = self.packetizer(frm)
  File "/home/carsten/Entwicklung/SnifferExt/PacketCapture_ext/ieee802154_io.py", line 322, in packetizer
    ticks = struct.unpack('LL',ticks)
error: unpack requires a string argument of length 8

Daraufhin habe ich in die Funktion "packetizer" in der Datei 
ieee802154_io.py etwas ergänzt um zu verhindern, dass "unpack" mit einem 
zu kurzen String aufgerufen wird:

(...)
if (pktlen) < 13:
    # length is to short
    state = self.UNSYNC
    break
if frm[pktlen+2] != '\x04':
(...)

Die 13 habe ich gewählt, da ich in die Nachrichten vom ZigBee-Modul 
(uracoli, sniffer.c) 5 zusätzliche Bytes vor dem EOT eingefügt habe. Ein 
Paket besteht also immer aus dem Timestamp und mindestens diesen fünf 
Bytes.

Diese Variante funktionierte bei geringem Datenaufkommen auch. Bei hohem 
Datenaufkommen bleibt die Protokollierung in Wireshark aber stehen (das 
Skript läuft aber weiter).
Nach meinen bisherigen Untersuchungen sieht es so aus, dass sich das 
Skript gelegentlich neu synchronisieren muss. Dies scheint dann 
irgendwann nicht mehr zu gelingen.

Ich kenne mich leider nicht mit Python aus, deshalb gestaltet sich die 
Fehlersuche etwas schwierig.
Ich hoffe, dass mir jemand einen Tipp geben kann.

Bei den verwendeten ZigBee-Modulen handelt es sich um die 900 
MHz-Version von Meshnetics. Deshalb habe ich das uracoli-Projekt für den 
mnb900 kompiliert.
Vielen Dank im Voraus!

[A. W. (uracolix)]

Hallo Dennis,

kannst du mal das Python Skript mit -v starten und den Output angucken.

Das MNB900 verwendet einen UART zum Kommunizieren und derzeit ist noch
keine RC OScilator Kalibrierung fuer den AVR im µracoli implementiert.
Ich vermute dass du die Zeichen auf der seriellen Schnittstelle 
verlierst.

Mit welcher Datenrate betreibst du den Transceiver, 40kbit/s (BPSK)
order 250kbit/s (OQPSK) ?

Habe bisher nur mit den Sensor Terminal Boards von DE und dem
entsprechenden RCB gesnifft, es kann also sein, dass der UART nicht 
hinterherkommt.

Zweiter Punkt ist das OS, d.h. die Named Pipe zu wireshark.
Ich hatte erhebliche Probleme unter Windows und es bleibt heute noch
immer ein Paket in der Pipe stecken.

Ich wuerde mal eine Option -o logfile implementieren, damit kann man
dann in ein file dumpen, anstelle auf ein Fifo.

[A. W. (uracolix)]

Habe das Problem mit einem Testprogramm das fortwährend Rahmen mit 
ACK_REQUEST erzeugt und mit jedem Rahmen die Rahmenlänge erhöht
nachgestellt (Gegenstelle ist ein Knoten im RX_AACK mode).
Ab Rahmenlänge 66 gehen die Acks verloren, Vermutlich liegt der Fehler 
in der Firmware, ich geh dem Problem mal nach.

https://savannah.nongnu.org/bugs/index.php?28796

(edit: fehlerhaften Link zum Bug korrigiert)

[Dennis H. (dennis_h)]

Hallo Axel,
Vielen Dank für Deine schnelle Antwort.
Leider komme ich erst jetzt dazu mich wieder zu melden.
Der Tipp mit dem -v war hilfreich.
Durch die Ausgaben habe ich den Fehler mit der stehenbleibenden 
Protokollierung in Wireshark lösen können.
Das Problem war hier meine Erweiterung im Python-Skript um zu kurze 
Strings vor dem .unpack abzufangen.
Ich habe das Problem gelöst, in dem ich auch in sync_search die Länge 
überprüfe.

Danach hatte ich allerdings immernoch Probleme mit verlorenen Packeten / 
Bytes.
Eine genauere Untersuchung hat dann ergeben, dass die Daten bereits beim 
Senden auf dem Controller verloren gehen.
Es scheint dort ein Problem mit der Funktion "hif_put_blk" zu geben 
(Vielleicht beim Zugriff auf den Puffer).
Ich habe das Problem durch 2 Maßnahmen gelöst.
1. Ein Puffer für 40 Nachrichten
Dieser Puffer wird in der ISR gefüllt und in der Main-Funktion geleert.
Neue Nachrichten werden nur dann in den Puffer übernommen, wenn dieser 
noch nicht voll ist.
2. Anstelle der Funktion "hif_put_blk" wird die Funktion "hif_putc" in 
einer For-Schleife zum Senden der Daten verwendet.
Mit diesen Änderungen hatte ich keine Probleme mehr.
Die Betriebsart ist bei mir übrigens "OQPSK100".
Viele Grüße
Dennis

[A. W. (uracolix)]

Habe ein neues Pufferkonzept im Sniffer eingebaut, siehe
Kommentar zu obigen Bug. Die Quellen sind im CVS verfuegbar.