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

[badjules]

Hallo liebes Forum ich bräuchte mal eure Hilfe.

Ich habe hier mehrere Fritzboxen alle mit aktueller FW.
- 7590 als Master (192.168.178.1)
- 7530 als IP-Client-Modus (192.168.178.2) (Anschluss an 7590 per Lankabel an Lan1)

Telefonie bei beiden Boxen 1und1, unverschlüsselt und G.711.

Folgendes wurde von mir schon in der fritzcap.conf geändert:

start_str       = ?capture=Start&snaplen=1600&filter=
stop_str        = ?iface=internet&minor=17&type=3&capture=Stop

capture_monitor.py Zeile 264 abgeändert in:

url_stop = self.base_url + '/cgi-bin/capture_notimeout' + self.stop_str + "&ifaceorminor="

Die batch sieht wie folgt aus:

@echo off
start D:\FritzRecorder\fritzcap-master\fritzcap.py --capture_files --decode_files --monitor_calls --cap_interface 3-17  --box_name 192.168.178.1 --username xxx --password xxx
start D:\FritzRecorder\fritzcap-master\fritzcap.py --capture_files --decode_files --monitor_calls --cap_interface 1-eth0 --box_name 192.168.178.2 --username xxx --password xxx

Nun zum Problem:
Bei der 7590 wird nur eine capture_.cap Datei erstellt, diese lässt sich mit Wireshark abspielen, man hört beide parteien.
Außerdem wird jeder anruf aufgenommen solange die batch läuft.

Bei der 7530 werden folgende Dateien erstellt: capture_.cap, capture__0_.wav, capture__1_.wav, capture__mix_0_1.wav,
Nur leider hört man beim capture__0_.wav und capture__mix_0_1.wav nur die eigene Stimme.
Die des Gespächspartners fehlt.
Die capture__1_.wav lässt sich nicht öffnen

Und bei der capture_.cap Datei kommt beim öffnen folgende Fehlermeldung:
The capture file appears to have been cut short in the middle of a packet.
Zudem habe ich festgestellt, dass nur der erste Anruf teilweise aufgenommen wird, danach muss man die batch neustarten.


Wo ist der Fehler, wie kann ich bei der 7530 auch funktionierende Aufnahmen durchführen?

 

[duffy6]

Hallo zusammen,

ich habe das Problem, dass meine Fritzbox 7590 (v7.57) die cap-Dateien aufzeichnet (startet und stoppt), jedoch überhaupt keine WAV-Dateien erstellt werden - auch nicht mit Dateigröße 0kb oder Ähnliches.
Allerdings ist die cap-Datei mit Wireshark lesbar bzw. enthält zwei abspielbare Audio-RTP-streams.
Ich habe den ganzen Thread gelesen und gesehen, dass @K.Mauser (Beitrag 498, https://www.ip-phone-forum.de/threa...udiodaten-extraktion-v2-0.232682/post-2512522) das selbe Problem hatte.

Anbieter: Telekom, Telefonie unverschlüsselt

fritzcap.conf

start_str       = ?capture=Start&snaplen=1600&filter=
stop_str        = ?iface=internet&minor=17&type=3&capture=Stop

log_debug_fritzcap.txt:

Telnet:'15.12.23 19:06:32;CALL;1;11;XXXXXXXXXXXX;XXXXXXXXXXXX;SIP2;'
Call       (ID:1, ActiveCalls.:1, Caller:XXXXXXXXXXXX, DialedNumber:XXXXXXXXXXXX, LinePort:SIP2)
There is at least 1 active call. Send start_capture event to the CaptureMonitor.
start_capture called.
Wait for call monitor status change.
pre_capture wait() finished.
pre_capture release lock.
pre_capture release lock finished.
Login attempt to the the FritzBox (box_name:192.168.178.1)
Call the challange token url (url:'http://192.168.178.1/login_sid.lua')
SID HTTP result:200
Call the read seed token url (url:'http://192.168.178.1/login_sid.lua?username=XXXXXX&response=blabla', data:'login:command/response=blabla&getpage=../html/login_sid.xml').
Login HTTP result:200
Login OK (SID: XXX_SID_XXX)
data_map:{'tstart': datetime.datetime(2023, 12, 15, 18, 38, 9, 335042), 'tocall': time.struct_time(tm_year=2023, tm_mon=12, tm_mday=15, tm_hour=19, tm_min=6, tm_sec=32, tm_wday=4, tm_yday=349, tm_isdst=-1), 'tcall': datetime.datetime(2023, 12, 15, 19, 6, 35, 136004), 'tconn': datetime.datetime(2023, 12, 15, 18, 38, 19, 206652), 'toconn': time.struct_time(tm_year=2023, tm_mon=12, tm_mday=15, tm_hour=18, tm_min=38, tm_sec=16, tm_wday=4, tm_yday=349, tm_isdst=-1), 'todisc': time.struct_time(tm_year=2023, tm_mon=12, tm_mday=15, tm_hour=18, tm_min=38, tm_sec=30, tm_wday=4, tm_yday=349, tm_isdst=-1), 'tdisc': datetime.datetime(2023, 12, 15, 18, 38, 32, 914064), 'tcaps': datetime.datetime(2023, 12, 15, 19, 6, 35, 973506), 'tcape': datetime.datetime(2023, 12, 15, 18, 38, 46, 113415), 'pbook_number.8556694': 'ZuHause', 'pbook_name.ZuHause': '0448556694', 'pbook_number.0448556694': 'ZuHause', 'pbook_number.0177111222'
Initialize capture file (folder:captures/2023-12-15/190635/, file:capture_20231215190635.cap).
Destination folder:'captures/2023-12-15/190635/' not exists. Create.
Start capture (capture_file:'captures/2023-12-15/190635/capture_20231215190635.cap').
Send capture start request to the box          (url:'http://192.168.178.1/cgi-bin/capture_notimeout?capture=Start&snaplen=1600&filter=&ifaceorminor=3-17&sid=XXX_SID_XXX', capture_file:'captures/2023-12-15/190635/capture_20231215190635.cap').
Send capture start request to the box finished (url:'http://192.168.178.1/cgi-bin/capture_notimeout?capture=Start&snaplen=1600&filter=&ifaceorminor=3-17&sid=XXX_SID_XXX', capture_file:'captures/2023-12-15/190635/capture_20231215190635.cap').
Trace started  (url:'http://192.168.178.1/cgi-bin/capture_notimeout?capture=Start&snaplen=1600&filter=&ifaceorminor=3-17&sid=XXX_SID_XXX', filename:'captures/2023-12-15/190635/capture_20231215190635.cap')
post_capture acquire lock.
post_capture acquire lock finished.
post_capture wait().
Telnet:'15.12.23 19:06:35;CONNECT;1;11;XXXXXXXXXXXX;'
Connect    (ID:1, ActiveCalls.:1, Caller:XXXXXXXXXXXX, DialedNumber:XXXXXXXXXXXX, LinePort:SIP2)
Wait for call monitor status change.
Telnet:'15.12.23 19:06:48;DISCONNECT;1;11;'
Disconnect (ID:1, ActiveCalls.:0, Caller:XXXXXXXXXXXX, DialedNumber:XXXXXXXXXXXX, LinePort:SIP2)
There is no more active calls. Send stop_capture event to the CaptureMonitor.
stop_capture called.
Wait for call monitor status change.
post_capture wait() finished.
post_capture wait(9.999002).
post_capture wait(9.999002) finished.
post_capture release lock.
post_capture release lock finished.
Login attempt to the the FritzBox (box_name:192.168.178.1)
Call the challange token url (url:'http://192.168.178.1/login_sid.lua')
SID HTTP result:200
Call the read seed token url (url:'http://192.168.178.1/login_sid.lua?username=XXXXXX&response=yyy, data:'login:command/response=zzz&getpage=../html/login_sid.xml').
Login HTTP result:200
Login OK (SID: XXX_SID_XXX)
Send capture stop request to the box           (url:'http://192.168.178.1/cgi-bin/capture_notimeout?iface=internet&minor=17&type=3&capture=Stop&ifaceorminor=&sid=XXX_SID_XXX', capture_file:'captures/2023-12-15/190635/capture_20231215190635.cap').
Trace finished (url:'http://192.168.178.1/cgi-bin/capture_notimeout?capture=Start&snaplen=1600&filter=&ifaceorminor=3-17&sid=XXX_SID_XXX', filename:'captures/2023-12-15/190635/capture_20231215190635.cap')
Send capture stop request to the box finished  (url:'http://192.168.178.1/cgi-bin/capture_notimeout?iface=internet&minor=17&type=3&capture=Stop&ifaceorminor=&sid=XXX_SID_XXX', capture_file:'captures/2023-12-15/190635/capture_20231215190635.cap').
Capture finished (capture_file:'captures/2023-12-15/190635/capture_20231215190635.cap').
Add captured file 'captures/2023-12-15/190635/capture_20231215190635.cap' to the decoding work queue.
pre_capture acquire lock.
pre_capture acquire lock finished.
pre_capture wait().
Decode process started  (worker_id:0, file:'captures/2023-12-15/190635/capture_20231215190635.cap')
Decode process finished (worker_id:0, file:'captures/2023-12-15/190635/capture_20231215190635.cap')

Mein Startbefehl:

python D:\FritzRecorder\fritzcap-master\fritzcap.py --capture_files --decode_files --monitor_calls --cap_interface 3-17  --box_name 192.168.178.1 --username xxx --password xxx

capture_monitor.py Zeile 264 abgeändert in:

url_stop = self.base_url + '/cgi-bin/capture_notimeout' + self.stop_str + "&ifaceorminor="

Wie kann ich dem Problem auf die Spur kommen bzw. hat es jemand lösen können?


Gruß
duffy6

 

[PeterPawn]

Mir fehlen da alle Informationen, die mit dem Aufbau der Datei beim Mitschnitt zu tun haben ... wenigstens die Parameter/Eigenschaften der beiden Streams sollten schon drin sein (reinhören will da bei 13 Sekunden vermutlich auch niemand).

Denn die denkbaren Fehlerquellen sind nach wie vor Legion - angefangen beim falschen Codec für das Telefonat, denn fritzcap dekodiert m.W. nur G.711-kodierte Streams und Wireshark würde (wieder nur m.W.) die RTP-Streams auch bei Verwendung von anderen Codecs erkennen und dekodieren können. Nachdem heutzutage die Standardeinstellungen häufig automatisch auf "HD-Telefonie" gesetzt werden, muß/sollte man auch das zuerst mal überprüfen.

Ansonsten braucht man (für gezielte Suche und nicht nur "educated guessing") eben auch mal den Mitschnitt ... einfach mal irgendetwas aufnehmen (lassen) und hier vorzeigen.

 

[duffy6]

Ich bin kein Programmierer.
Du musst mir genau beschreiben, was du brauchst.
Das cap-file?
Da stehen aber alle Telefonnummern, oder?
Kann man das irgendwie anonymisieren?

Edit: Codec wird von Wireshark als g711a erkannt, HD-Telefonie ist abgeschaltet.

 

[PeterPawn]

Da stehen aber alle Telefonnummern, oder?

Wenn man da ein internes Gespräch mitschneidet (ggf. das Interface anpassen), dann sollte das "Potential des Geheimnisverrats" durchaus überschaubar bleiben und wenn man nur die Pakete der von Wireshark erkannten Audiostreams exportieren läßt (aber immer noch als Netzwerkdaten und nicht nur den Payload der Pakete), dann stehen da auch keine Telefonnummern mehr drin, solange die niemand im "Gespräch" vorliest.

Andere Frage: Was passiert denn (Debug-Log zeigen), wenn man fritzcap nachträglich (mit gesondertem Aufruf) auf die aufgezeichneten Capture-Files ansetzt und was wird zu dem aufgezeichneten Telefonat in der Box unter "Sprachübertragung" angezeigt?

EDIT:
Ich habe noch einmal in die Quellen geschaut:

fritzcap/core/g711_decoder.py at 6203498daf42ecd87cc8e542fcec9a05d683f4fe · jpluimers/fritzcap

Fork of elpatron68/fritzcap which was previously automatically exported from code.google.com/p/fritzcap - jpluimers/fritzcap

github.com

Da der Decoder die Pakete nicht wirklich zerlegt, sondern nur auf bestimmte Paketlängen abstellt und dann die Daten an davon abhängigen Offsets erwartet, dürfte er auch gegen die Wand laufen, wenn die Pakete IPv6 anstelle von IPv4 enthalten, weil dann die Paket-Header größer sind und die Daten erst "später" in den Paketen kommen bzw. die Pakete insgesamt länger werden.

Das wäre also auch noch ein "Verdacht", der zu überprüfen wäre, wenn das Extrahieren von Audio-Streams nicht funktioniert.