fritzcap: Tool für Etherreal Trace und Audiodaten-Extraktion v2.0

[leseratte10]

Es kann durchaus sein, dass die 06.50 da mit dem neuen Design irgendwas kaputt gemacht hat.

Anhand der Fehlermeldung würde ich aber mal schätzen, du hast den Callmonitor nicht aktiviert. Tipp mal #96*5* in ein angeschlossenes Telefon um den Dienst zu aktivieren.

 

[AndreasBocholt]

@leseratte10 Vielen vielen Dank das war die Lösung!!!! Es funktioniert wieder.

Wo ich gerade schon dabei bin....Gibt es auch noch die Möglichkeit die anrufer Nummer und die angerufene Nummer mit in den Dateinamen der Capture Datei zu schreiben? Und zweitens gibt es irgendwie ne einfache Möglichkeit die Audio Capture Dateien direkt auf eine an der Fritzbox angeschlossene Festplatte abzulegen.

- - - Aktualisiert - - -

@ at89c4051

ich habe deine alte Lösung zum einfügen der Telefon Nummern in die Cap Datei mal probiert aber irgendwie funktionert Sie nicht. Ist der Aufruf c:\python27\python fritzcap.py -c -d -m richtig oder muss ich das anders aufrufen....
LG

 

[HoPi`]

Hi Leute,
mein Plan ist, auf einem Raspberry per cron den Traffic der Fritzbox mitzuschneiden und auszuwerten. Sinn des ganzen ist das Bereitstellen von Infos à la "Down- und Upload pro IP zu Zeitpunkt x über einen Zeitraum von 10 Sekunden". Nachdem ich ein python-Skript für den Login zur Fritzbox geschrieben hab, bin ich auf fritzcap gestoßen und dachte mir "warum das Rad neu erfinden?"

Jedenfalls hab ich jetzt durch fritzcap einen Mitschnitt, den ich wiederrum in python verarbeiten möchte. Allerdings wirft dieses Skript

[COLOR=#000080][B]import [/B][/COLOR]dpkt
file = open("capture.cap", "r")
pcap = dpkt.pcap.Reader(file)

folgenden Fehler:

ValueError: invalid tcpdump header

Der Header der Datei liefert mir Hex a1b2cd34, gefordert ist aber entweder a1b2c3d4 oder a1b23c4d (je nach Timestamp). Wireshark kann die Datei problemlos öffnen und meint "modified tcpdump", ein "Speichern unter..." in verschiedenen Formaten scheint diesen Header aber nicht zu korrigieren.

Ich hab die Fritzbox gerade nicht zur Hand (steht zuhause und ich sitze im Büro ), kann also nichts über Modell/Version sagen (außer, dass wir sie vor 4 Monaten von MNet bekommen haben).

Ist fritzcap an dem falschen Header Schuld? Oder liefert die Box generell ein modifziertes Format? Hat jemand vielleicht 'n Tip, wie ich die Dateien trotz falschen Headers mit python verarbeiten kann? Was genau bringt eigentlich das Dekodieren des Mitschnitts?

Danke im Voraus

 

[AndreasBocholt]

Hi Kollegen,
es ist schon ne Zeit her da hatte at89c4051 hier eine Lösung entworfen mit der es möglich war die beiden Telefonnummern der Verbindung als Datei Name zu verwenden. Leider ist at89c4051 wohl schon seit 2014 hier nicht mehr aktiv und ich würde mich freuen wenn jemand hier weiss wie man das heute realisieren könnte. Es wäre sehr vorteilhaft für den Gebrauch wenn man anhand der Bezeichnung der wave dateien sehen könnte um welches Gespräch es geht. Leider funktionert die Lösung von at89c4051 heute so wohl nicht, mehr zumindest nicht bei mir (oder ich mache einen Fehler?).
Ich arbeite mit der aktuellen Fritzcap und einer AVM 7490.
LG Andreas

 

[jeroenp]

Sorry for doing this in English; I can read and speak German fine, but getting the writing bearable for readers is well...

I've tried finding if anyone is still maintaining fritzcap in a public repository, but couldn't.

I did find https://github.com/elpatron68/fritzcap which was an export of https://code.google.com/archive/p/fritzcap/ including the issues, but it has no further activity after march 2013.

Since I bumped into a few things while getting it to work, I've forked it to https://github.com/jpluimers/fritzcap and registered some of my own issues to https://github.com/jpluimers/fritzcap/issues, fixed a few and posted one matching issue as a pull request to https://github.com/elpatron68/fritzcap/pulls to see if it gets merged.

When not, I plan to keep my own repository for more fixes and keep the repository open for new issues and pull requests.

The current issues are all about hard coded entries:

1. fritz.box (fixed)
2. root username (fixed)
3. .gitignore (fixed)
4. Mac OS X support (fixed)
5. connection to capture when the Fritz!Box is not a router (not fixed)
6. dump of available connection (fixed)

As this forum does not show in an obviously way how to monitor threads with RSS/ATOM and e-mail notifications are a big-ball-of-mud to me (as each forum has their own email format), I will manually monitor this thread for a bout a week and then put another post with the pull request results.

After that I will stop monitoring this thread, but will react to new issues in my repository.

If you have ideas or want stuff fixed: post them as an issue in my repository as that allows for way more focus than me trying to walk through a linear 15-page forum thread spanning 6 years of history where I regularly get errors like "nicht angemeldet" and "500".

--jeroen

 

[jeroenp]

New version 2.3 in the below thread; please post bug reports and feature requests there:

http://www.ip-phone-forum.de/showthread.php?t=295776&p=2229799

 

[duffy6]

Hat jmd das skript erfolgreich mit der FB 7590 v7.0.1 laufen?

Grüße
Duffy6

 

[stoney]

Warum stellst Du die Frage nicht im über Deinem Post verlinkten Thread?

Bzw warum versuchst Du es nicht erst mal mit der dortigen v2.3?

 

[testtesttestdel]

Läuft der "Support" hier noch ?
Ich habe auch payload Probleme den Rest habe ich hinbekommen.
Nun bin ich mir aber nicht sicher was ich in die g711_decoder.py datei eintragen soll.
{'len': 298, 'chunk': 240, 'offs': 58, 'encap' : 'SWNNET' }, # SWNNET
hat nicht geklappt.

Ich bekomme eine .cap datei, weiß aber nicht, ob es die richtige ist. Ich habe schon zwischen beiden interfaces gewechselt. Also 3-17 und 3-18

Frage 1)
Wie bekomme ich heraus welches bei mir das richtige ist ?
Über capture direct von der Fritzbox und die eth datei klappt es nur mit der voip schnitstelle.

Frage 2)
Wie beomme ich mit wireshark die richtigen PacketLength, AudioChunkLength, Offset of audio data, descriptive text heraus. Zum eintragen in die g711_decoder.py datei

Danke

 

[AndreasBocholt]

Hallo zusammen,

wie bekomme ich durch die Änderung vom tcaps in der config Datei die Telefonnummer der beiden Gesprächsteilnehmer mit in den Namen der cap Datei.
Also so das die Datei so aussieht
capture_0546515555_0221564856116363_2019_11_13.cap

in der Zeile steht ja zurzeit nur:
cap_file = capture_%(tcaps.YmdHMS).cap

In einem anderen Bereich sagte jemand dazu:
Please add caller and dialledNumber to file name patterns.

Aber Wo und Wie?

 

[ctiemann]

Hallo Forum,

hier ein Bericht für die neue Fritzbox 7590 FRITZ!OS: 07.12 :
Sofern ich die g711_decoder.py modifiziere mit einem zusätzlichen Eintrag:

{'len': 246, 'chunk': 160, 'offs': 86, 'encap' : 'DSLPPPoE' }, # DSL (PPPoE)

werden zumindest mal die wav-Dateien erzeugt.
Sehr leider nicht die mix_...wav, aber zumindest mal einzelne Files mit Inhalt.



Aufruf des Programms mit:
/etc/fritzcap/fritzcap.py --capture_files --decode_files --monitor_calls --box_name 192.168.178.1 --username root --password blahbla &

[U]Fehlermeldungen:[/U]

2020-01-31 17:53:57,642 [  Thread-2::139888664966912] [INFO    ] [  capfile_worker Process           ] Decode process started  (worker_id:1, file:'captures/2020-01-31/175308/capture_20200131175308.cap')
2020-01-31 17:53:57,648 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 6
2020-01-31 17:53:57,649 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 6
2020-01-31 17:53:57,651 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 48
2020-01-31 17:53:57,655 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 136
2020-01-31 17:53:57,698 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 78
2020-01-31 17:53:57,788 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 78
2020-01-31 17:53:57,880 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 78
2020-01-31 17:53:57,920 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 78
2020-01-31 17:53:57,920 [  Thread-2::139888664966912] [DEBUG   ] [    g711_decoder::decode            ] Unsupported payload type 6
2020-01-31 17:53:57,924 [  Thread-2::139888664966912] [INFO    ] [  capfile_worker Process           ] Decode process finished (worker_id:1, file:'captures/2020-01-31/175308/capture_20200131175308.cap')

Hat Irgendjemand eine Idee? Oder mache ich einen Denkfehler?

Einen Auszug vom RTP Paket füge ich mal an, hab ich was falsch interpretiert, bezüglich der Paketlänge oder des Offset? Und wenn ja, wie kann ich die richtigen Daten erhalten?



Würde mich über Hilfe sehr freuen und die 7590 ist ja nunmehr ein aktuelles Modell.
Viele Grüße

[Edit Novize: Bilder auf lesefreundliche Vorschau reduziert und Log in Code-Tags geklammert]

 

[Yellow99]

Hallo...

hab mich in meiner verzweifelten Suche hier registriert... bei mir werden ebenfalls keine mixed WAV Files erzeugt (d.h. g711_decoder.py schreibt zwar zwei separate .WAV, aber eben kein zusammengemischtes aus WAV-File 0 und WAV-File 1.

Weiss IRGEND JEMAND hier eine Lösung, oder kann mir was raten? Ich hab keine Ahnung von Python, geschweige denn, wie man sowas debugged...

Sofern ich die g711_decoder.py modifiziere mit einem zusätzlichen Eintrag:

{'len': 246, 'chunk': 160, 'offs': 86, 'encap' : 'DSLPPPoE' }, # DSL (PPPoE)

werden zumindest mal die wav-Dateien erzeugt.
Sehr leider nicht die mix_...wav, aber zumindest mal einzelne Files mit Inhalt.

Bez. dieser Convertierung hab ich selbst schon tagelang rumgesucht und bin vor allem immer am 'Fach-Chinesisch' gescheitert, daher erklär ich meine abschließende Herangehensweise so simpel wie möglich (für Noobs wie mich halt):

Wenn ein .CAP File erzeugt wird, aber KEINE .WAV Files, dann liegt das vermutlich daran, dass die RTP-Pakete / Daten eine Länge haben, die in der g711_decoder.py unbekannt sind. Die simpelste Lösung für mich war wie folgt:

Ladet euch WireShark Portable herunter und installiert es ('richtiger' Install ist nicht nötig, das Ding ist eh nur was für echte Profis). Hinweis: die Portable Version lässt sich nicht unter 'Programme' installieren, da halt 'Portable'.

Startet WireShark und öffnet euer .CAP File (Datei - Öffnen - .CAP File auswählen).

Im oberen Bereich seht ihr dann einen Haufen hellblau unterlegter Zeilen. Scrollt so weit runter, bis ihr in der Spalte 'Protocol' nur noch 'RTP' seht. Das sind die Pakete, die der Decoder erkennen können muss. Dazu braucht er drei Werte: PacketLength, AudioChunkLength und Offset of Audio Data.

Gleich rechts neben der 'Protocol'-Spalte ist die Spalte 'Length'. Das ist die PacketLength.

Wählt eine der RTP-Zeilen aus, indem ihr mit der Maus draufklickt. Öffnet dann im mittleren Fenster 'Real-Time Transport Protocol' und wählt dort 'Payload'. Das, was jetzt unten blau hinterlegt wird, sollten die Audio-Daten sein (oder geht einfach mit der Maus im unteren Fenster über die Byte-Werte, bis ein großer Block blau hinterlegt wird, der bis zum Ende des Datensatzes reicht).

Die Anzahl Bytes im markierten Teil ist die AudioChunkLength, die Anzahl Bytes im nicht-markierten Teil ist der 'Offset'.

Bei mir war es z.B. eine Packet-Length von 256, ein Offset von 96 (5 Zeilen a 16 Byte), und ein Audio-Chunk von 160 Byte (256 minus 96).

Dann öffnet man die g711_decoder.py (ACHTUNG: Unix-kompatiblen Editor nutzen, z.B. Notepad++) und fügt wo die 'lenmap'-Definitionen sind (aktuell ab Zeile 45) eine zusätzliche Zeile mit den ermittelten Werten ein, bei mir war das

{'len': 256, 'chunk': 160, 'offs': 96, 'encap' : 'WHATEVER' },

Was man bei 'Descriptive Text' schreibt ist egal (ich hab da WHATEVER geschrieben, da ich keine Ahnung habe, was das jetzt speziell für Pakete sind)...

Danach sollten (hoffentlich) korrekte .WAV Files erzeugt werden.

Wer seine .CAP Files mit WireShark testen / mal reinhören möchte:

Telephonie - RTP - Stream auswählen, auf 'Analysieren' klicken, auf 'Streams abspielen' klicken, dann unten links auf den 'Play'-Button, und man sollte hoffentlich was hören.

Ja... klingt alles so simpel, aber ich hab dafür ECHT lang rumgesucht. Daher hab ich's hier noch mal zusammengefasst, für all die, die ne Sache einfach nur nutzen wollen, ohne vorher groß Kurse über Python, WireShark und Netzwerkprotokolle zu absolvieren.

 

[ctiemann]

Hallo Yellow99, hatte deinen Beitrag bereits gelesen, irgendwie ist er nicht mehr da?
Genauso hab ich es auch ermittelt, dennoch ist für die 7590 die Einstellung:

{'len': 246, 'chunk': 160, 'offs': 86, 'encap' : 'DSLPPPoE' }, # DSL (PPPoE)

wohl nicht richtig. Ich bekomme keine MIX...wav.




Ich benutze nunmehr vorläufig ein script, welches ich im Internet gefunden habe zum Umwandeln, dies funktioniert und erzeugt ein Mix-File.
Ich hab es mal als cap2wav.txt angehängt.
Es liegt ausführbar (chmod +x cap2wav) bei mir im "/usr/local/bin/" um es Systemweit verfügbar zu machen.
Aufruf per shell im Verzeichnis nach dem Schema: cap2wav <capture-filename> <name der zu erzeugenden wav-files> - also im Verz. wo die capture_2020020809xxxx.cap liegt,
mit: "cap2wav capture_20200208xxxxx.cap audio".
Der Aufruf mit "cap2wav -z capture_20200208xxxxx.cap audio" erzeugt ein Zip-Archiv, wo die Wav-files drin sind.

Beachte:
Dependencies:
apt-get install -y tshark sox
yum install wireshark sox
Usage:
cap2wav [opts] filename.pcap [target filename]

d.h. tshark und sox muss installiert sein.

Bild geschrumpft by stoney

 

[Yellow99]

Ich bekomme keine MIX...wav.

Das ist ja mein Problem! Der Eintrag ist vermutlich korrekt, denn es werden ja zwei gültige & abspielbare .WAV Files erzeugt, nur die zwei werden eben nicht zusammengemischt, und ich hab keine Ahnung, woran das liegen könnte ...

... und hab auch keine Ahnung, was ich da machen kann. Daher: HÜLFE!! Gibt's denn keinen hier, der Ahnung von Python hat und sich das mal anschauen kann? Oder Tipps geben / Lösungsvorschläge aufzeigen?

Natürlich könnte man auch z.B. mit FFMPEG mischen, z.B.

FFMPEG -i file1.wav -i file2.wav -filter_complex join=inputs=2:channel_layout=stereo output.wav

Aber das ist nicht dasselbe. Bei anderen geht es, warum nicht bei miiiiirrrr....?

 

[ctiemann]

Gibt's denn keinen hier, der Ahnung von Python hat und sich das mal anschauen kann?

Das ist ja das schlimme, ich kenne mich zwar mit Python recht gut aus, finde aber im Script derzeit keinen Fehler oder Anhaltspunkt, warum "zum Teufel" kein mix-file erzeugt wird.
Mit jeder anderen FB funktionierte es, nur mit der 7590 nicht!

 

[Yellow99]

Ich benutze nunmehr vorläufig ein script, welches ich im Internet gefunden habe zum Umwandeln, dies funktioniert und erzeugt ein Mix-File.

Öh... leider hab ich als Windows-User von sowas wenig Ahnung.

Wenn ich das sagen wir mal auf meinem vernetzten Linux Sat-Receiver nutzen will, wie müsste ich vorgehen, was müsste ich wie setzen / umbenennen, wohin müsste ich's kopieren, und kann man das auch irgendwie in die Python-Scripts integrieren, z.B. dass man guckt, ob das Python-Script eine Mixed WAV erzeugt hat, und wenn nicht, dann halt das andere Script starten...?

Man soll Python ja auch irgendwie Step-by-Step debuggen können, das wär evtl. ein Ansatz für die Suche, warum eben kein MIxed-WAV erzeugt wird. Aber wie schon erwähnt, Noob. Auch das krieg ich nicht hin.

 

[ctiemann]

Wenn ich das sagen wir mal auf meinem vernetzten Linux Sat-Receiver nutzen will, wie müsste ich vorgehen, was müsste ich wie setzen / umbenennen, wohin müsste ich's kopieren, und kann man das auch irgendwie in die Python-Scripts integrieren, z.B. dass man guckt, ob das Python-Script eine Mixed WAV erzeugt hat, und wenn nicht, dann halt das andere Script starten...?

Man soll Python ja auch irgendwie Step-by-Step debuggen können...

Du brauchst auf deinem Linux-Server Adminrechte, allerdings glaube ich nicht, dass ein Sat-Receiver dazu geeignet ist.
Ansonsten:

"apt update"
"apt install -y tshark sox"
fritzcap installieren wie beschrieben
das cap2wav-script in den ordner "/usr/local/bin/" kopieren bzw. erstellen (nano /usr/local/bin/cap2wave) um es Systemweit verfügbar zu machen
dann Befehl "chmod +x /usr/local/bin/cap2wave"
und weiter wie beschrieben. Eine Abfrage ob schon mix-files vorhanden sind kann man per script sicherlich erstellen, mir fehlte bisher nur die Zeit.
Ich nutze es in sofern, das ich derzeit nur .cap files mit fritzcap aufzeichne und bei Bedarf (wenn ich die Aufzeichnung benötige) mit cap2wav umwandel.
Nicht jede Aufzeichnung ist mir wichtig.
Bei Gelegenheit suche ich ausführlicher den möglichen Fehler in der g711_decoder.py - da muss nix debuggt werden, der Quelltext liegt ja offen da.
Aber ich war auch in der Hoffnung, dass vielleicht ein anderer User das Problem schon gefunden hat.

 

[ctiemann]

So, nunmehr mein Bericht zu FritzCap mit der Fritzbox 7590 unter IPv6 (DS-Lite-Tunnel) :

Ich habe den Verdacht, dass die .cap Datei unter IPv6 im DS-Lite-Tunnel nicht richtig aufgezeichnet wird, bzw. irgendwelche Daten beinhaltet, die bei Aufzeichnung über IPv4 nicht vorhanden sind, da selbst über wireshark das Telefonat bei mir nicht richtig wiedergegeben wird.
Meine Vermutung, warum das g711_decoder.py nicht mehr die Mix erzeugt: Unter IPv6 ist der Header vermutlich anders. Versuche von mir, die g711_decoder.py entsprechend zu ändern schlugen bisher fehl.

Was allerdings unter Linux bei mir funktioniert, ist das bash-script cap2wav.
Ich habe nunmehr folgendes getan:

• fritzcap installiert wie beschrieben
• apt update
• apt install -y tshark sox
• das cap2wav-script in den ordner "/usr/local/bin/" kopiert bzw. erstellt (nano /usr/local/bin/cap2wave) um es Systemweit verfügbar zu machen (komplettes script im Anhang)
• dann chmod +x /usr/local/bin/cap2wav
• /fritzcap/core/capfile_worker.py wie folgt geändert (komplettes script im Anhang):

Zufügen von

import os

und ändern von

    def process(self, filename):
        self.logger.info("Decode process started  (worker_id:%s, file:'%s')" % (self.worker_id,filename))
        # g711 = G711Decoder(filename, mix=1, linearize=1)
        # PcapParser(filename, g711.decode).parse()
        # g711.finalize()
        self.logger.debug('Ausführen: cap2wav -z ' + filename + ' ' + os.path.dirname(filename) + '/audio')
        os.system('cap2wav -z ' + filename + ' ' + os.path.dirname(filename) + '/audio')
        self.logger.info("Decode process finished (worker_id:%s, file:'%s')" % (self.worker_id,filename))

Damit wird nicht mehr die g711_decoder.py eingebunden, sondern cap2wav verwendet. Das Resultat nach dem Telefonat:



audio_mixed.wav beinhaltet das komplette Gespräch, das audio.tgz ist ein gezipptes File, wo die Audio-Files von beiden Gesprächspartnern und das zusammengefügte Gespräch enthalten sind.
Öffnen kann man dieses üblich unter Linux oder mit 7-zip unter Windows.
Wie man das ganze unter Python für Windows laufen lassen kann, kann ich nicht beantworten, ich würde wahrscheinlich auf Windows eine virtuelle Maschine mit Linux laufen lassen.

Bei Verwendung der angehängten Dateien, bitte jeweils umbenennen ohne das .txt, die Umbenennung auf .txt war nötig, da man die Dateien sonst nicht hier anhängen kann (unerlaubte Dateiendung).

Sofern FritzCap bei einem User mit der Fritzbox 7590 einwandfrei läuft, wäre die Info der Konfiguration in der g711_decoder.py interessant und ob IPv4/IPv6 verwendet wird.

Stürmische Grüße aus Bayern
Chris

 

[Yellow99]

Ich habe den Verdacht, dass die .cap Datei unter IPv6 im DS-Lite-Tunnel nicht richtig aufgezeichnet wird, bzw. irgendwelche Daten beinhaltet, die bei Aufzeichnung über IPv4 nicht vorhanden sind

Also ich hab ne FritzBox 7530, die verwendet auch nen DS-Lite Tunnel, und beide .WAV werden korrekt erzeugt, nur eben keine mixed .WAV.

Wird die mixed .WAV nicht aus den bereits fertig erstellten Einzel-WAVs generiert bzw. soll aus diesen generiert werden, d.h. das .CAP File spielt da schon gar keine Rolle mehr...? Warum sollte dann kein mix klappen?

 

[ctiemann]

Also ich hab ne FritzBox 7530, die verwendet auch nen DS-Lite Tunnel, und beide .WAV werden korrekt erzeugt, nur eben keine mixed .WAV.

Werden nur 2 .wav-Files erzeugt oder mehrere? Das war bei mir das Problem, ich hatte zum Teil 10 wav-files und diese wurden somit nicht zur mix_wav erstellt.
2 waren normal abspielbar, der rest einfach nur Datenschrott.
Da ist vermutlich das Problem.