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

[ctiemann]

Mein Problem momentan ist, dass die Logfiles log_info_fritzcap.txt und log_debug_fritzcap.txt irgendwann den Speicher sprengen.

Hallo the Surfer, erstaunlich. Bei mir sind die Logfiles nicht wirklich groß und ich finde auch auf den ersten Blick keine Konfigurationsmöglichkeit der Logs.
Daher würde ich die Logfiles einfach mit LogRotate oder einem Cronjob regelmäßig rotieren lassen bzw. löschen, das geht schneller als in den Pythonscripten irgendwelche Fehler einzubauen.

P.S: Mist, jetzt sehe ich, dass die Wav Files im falschen Ordner landen, nämlich immer bei den script und nicht auf dem USB-Geräte.Da muss ich auch noch schauen...

Das kannst du in der fritzcap.conf erledigen (Syntax hab ich auch hier im Thread irgendwo beschrieben):

cap_folder            = captures/%(tcaps.Y-m-d/HMS)/
cap_file                 = capture_%(caller.number).cap

ggf. auch hier mit Cronjob die wav-Files irgendwo anders hin sortieren lassen. Die wav-Files landen immer da, wo sich auch das cap-File befindet.

Grüße aus dem Allgäu, bei Fragen einfach melden.

Beste Grüße
Chris

 

[The_Surfer]

Danke Dir für die schnelle Antwort. Das mit dem cronjob dachte ich auch, vor allem da ich es mitgebaut habe bei freetz. Werde das auch so machen.
Hab mir mir eclipse mit Pydev runtergeladen, aber naja.. lange her als ich da was mit c gemacht und mit python gar nicht.

Die Wavfiles landen aber bei mir im order wo sich das script befindet und nicht bei den cap-files.
Liegt wahrscheinlich an meinen spziellen Einstellungen in der conf ? Wahrscheinlich verträgt sich das nicht mit den Punkten, wo ich eine Verzeichniseben höher gehe.. (musste ich so machen, weil der stick fat32 ist und von avm nie mit exec gemountet wird)

Habe diese EInstellungen und deine python anpassung funktionieren auch.
cap_folder = ../usbstick/Anrufe/%(tcaps.Y-m-d/H-M-S)/
cap_file = %(callevent.name)_%(caller.number)_%(dialed.number).cap

Muss schauen ob ich vorerst ohne decoding arbeite und es später auf einer perfomanteren Maschine umwandle.

 

[ctiemann]

Die Wavfiles landen aber bei mir im order wo sich das script befindet und nicht bei den cap-files.

Von welchem Script sprichst du? Von scripten im Fritzcap Verzeichnis oder der Ergänzung cap2wav von mir
https://www.ip-phone-forum.de/threads/fritzcap-tool-für-etherreal-trace-und-audiodaten-extraktion-v2-0.232682/page-15#post-2357440?
Wenn du das externe script verwendest, musst du das fritzcap/core/capfile_worker.py File ggf. anpassen:

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))

os.system('cap2wav -z ' + filename + ' ' + os.path.dirname(filename) + '/audio')

Usage:
cap2wav [opts] filename.cap [target filename]

Den aktuellen Pfad solltest du im LOG finden
(self.logger.debug('Ausführen: cap2wav -z ' + filename + ' ' + os.path.dirname(filename) + '/audio')).

Grüße

 

[The_Surfer]

Ich meinte die pythondateien eigentlich. Dein script habe ich mir schon kopiert. Da ich auf der Fritte kein tshark und sox habe muss ich später die Anrufdateien per cronjobs kopieren und auf einer ubuntu-machschine umwandeln.
Ich muss da einfach mehr Zeit reinstecken... um das Ganze stabil und einfach hinzubekommen.

Danke für die Anapssungen im capfile_worker.py ich blicke bei dem python echt nicht durch.

 

[hhw147]

Hallo zusammen,

bislang lief fritzcap einwandfrei bei mir, doch seit dem Update der FritzBox 7490 auf FritzOS 7.29 funktioniert es nicht mehr.
Zuerst wurden keine .wav Dateien erzeugt. Dies konnte ich durch Anpassen der Parameter "PacketLength, AudioChunkLength, Offset" in der g711_decoder.py mit Hilfe von Wireshark lösen.

Hier meine aktuellen Werte: {'len': 236, 'chunk': 170, 'offs': 66, 'encap' : 'VDSL' },

Nun werden auch wieder die .wav Dateien erzeugt, aber leider ist nur noch ein Rauschen wahrzunehmen. Auch in Wireshark wird mir nur ein Rauschen wiedergegeben. Voip Verschlüsselung in der FritzBox ist deaktiviert.

Hat jemand vllt. nach dem Update ähnliche Probleme oder kann unterstützen?

Vielen Dank im Voraus.

Grüße

 

[ctiemann]

Nun werden auch wieder die .wav Dateien erzeugt, aber leider ist nur noch ein Rauschen wahrzunehmen. Auch in Wireshark wird mir nur ein Rauschen wiedergegeben. Voip Verschlüsselung in der FritzBox ist deaktiviert.

Lies mal hier: https://www.ip-phone-forum.de/threads/fritzcap-tool-für-etherreal-trace-und-audiodaten-extraktion-v2-0.232682/post-2386085

hier: https://www.ip-phone-forum.de/threa...udiodaten-extraktion-v2-0.232682/post-2405486

hier: https://www.ip-phone-forum.de/threads/fritzcap-tool-für-etherreal-trace-und-audiodaten-extraktion-v2-0.232682/post-2357235

und ggf. hier: https://downloads.avaya.com/elmodocs2/s8700/cnet/NW_Ref_Ch72.html um den Offset zu ermitteln.
Zudem, welche Verbindung du hast unter Fritzbox > DSL-Informationen > Übersicht

Grüße
Chris

 

[hhw147]

Lies mal hier: https://www.ip-phone-forum.de/threads/fritzcap-tool-für-etherreal-trace-

Hallo Chris,

vielen Dank für deine Antwort. HD ist in den betroffenen DECT Endgeräten deaktiviert, auch schon als es noch funktionierte. Codec ist daher G.711.
das Skript cap2wav habe ich ebenfalls ausprobiert und es unterstützt auch G.722, jedoch gleiches Fehlerbild. Nur Rauschen beim anhören der .wav Dateien.

Hat keiner von euch das aktuelle FritzOs 7.29 drauf und ähnliche Probleme bzw. kann das Gegenteil bestätigen?

 

[ctiemann]

Hat keiner von euch das aktuelle FritzOs 7.29 drauf und ähnliche Probleme bzw. kann das Gegenteil bestätigen?

Ich hab die 7590 mit 7.29 drauf und stelle gerade mit erschrecken fest: Bei mir geht gerade auch nix.... *seufz
Na ich schau es mir mal an....

Meine Fehlermeldungen:

tshark: The file "capture_xxxxx.cap" appears to have been cut short in the middle of a packet.
tshark: The file "capture_xxxxx.cap" appears to have been cut short in the middle of a packet.
Target files to create:
audio_1.G722 and audio_1.wav
audio_2.G722 and audio_2.wav

Stream 1 ssrc / port: 0x61895404 / 7078
Stream 2 ssrc / port: 0x65b746ad / 45504

Extracting payloads 1 from 0x61895404...
/usr/local/bin/cap2wav: Zeile 161: audio_1.G722: Befehl nicht gefunden
Extracting payloads 2 from 0x65b746ad...
/usr/local/bin/cap2wav: Zeile 161: audio_2.G722: Befehl nicht gefunden
Combining 2 streams into a single wav file for convenience
soxi FAIL formats: can't open input file `audio_1.wav': No such file or directory
soxi FAIL formats: can't open input file `audio_2.wav': No such file or directory
/usr/bin/sox FAIL formats: can't open input file `audio_1.wav': No such file or directory
/usr/bin/sox FAIL formats: can't open input file `audio_2.wav': No such file or directory

 

[ctiemann]

Oh man, ja - du hast recht, mit der Version 7.29 scheint sich wieder mal irgendwas geändert zu haben.
Die Fritzbox stellt G722 zum Einen automatisch ein, d.h. wieder HD-Telefonie deaktivieren.
Dann sind die Streams zwar wieder in G711, aber mit folgender Fehlermeldung:

Checking capture_0176xxxxx.cap for RTP streams...
tshark: The file "capture_0176xxxxx.cap" isn't a capture file in a format TShark understands.

Ich muss gestehen, ich bin wohl raus. Eher schreibe ich ein neues Programm als fritzcap nochmal anzupassen. Mal sehen - vielleicht hab ich ja mal Langeweile.

 

[hhw147]

Oh man, ja - du hast recht, mit der Version 7.29 scheint sich wieder mal irgendwas geändert zu haben.
Die Fritzbox stellt G722 zum Einen automatisch ein, d.h. wieder HD-Telefonie deaktivieren.

Vielen Dank für deine Rückmeldung. Ich war schon echt am zweifeln, ob ich der einzige bin mit den Problemen.

Bzgl. der Fehlermeldung, dass TShark das capture-file nicht lesen kann habe ich festgestellt, dass die vermeidlichen RTP-Pakete nicht als solche im Wireshark angezeigt werden, sondern als normale UDP Pakete..
Dies konnte ich fixen, in dem ich beim Aufruf, wo Tshark die .cap Datei durchsucht, ich die UDP Parameter mit Portangabe mitgeliefert habe. Dadurch erkennt TShark wieder die Pakete in der .cap Datei, aber es bleibt bei mir weiterhin leider beim Rauschen.

Auszug aus der cap2wav:
"payload_type=`tshark -n -r $CAPFILE -d udp.port==7078-7083,rtp -T fields -e rtp.p_type | grep -P '\d+' | head -n 1`"

 

[Bowf]

nach Update auf 9.29 waren bei mir alle Verbindungen verschlüsselt, obwohl verschlüsselung von mir nicht aktiviert war. Hab dann über ftp den Bootsektor auf andere Partition booten lassen und 9.28 funktioniert noch. Allerdings findet Wireshark auch jetzt nur udp Pakete und keine RTP Strems.

 

[The_Surfer]

Du meinst 7.29 und 7.28 oder?
Was meinst Du mit verschlüsselt? Die VoIP Pakete werden doch nicht verschlüsselt oder irre ich mich da? Welcher Anbieter, welche Fritzbox?

 

[Bowf]

ja, ich meine 7.29 und 7.28. (tschuldigung) FB ist 4790 an Deutsche Telekom. Verschlüsselung wird gemeldet unter Telfonie-Eigene Rufnummern-Sprachübertragung. Dort steht in der letzten Spalte der jeweiligen Verbindung verschl.... Bei Verbindungen die nicht verschlüsselt sind, ist dort eine Sprechblase, hinter der man die Verbindung bewerten kann.



Vollbild(er) gemäß Boardregeln als Vorschau eingebunden by stoney

 

[The_Surfer]

Oh, wusste gar nicht, dass die großen Anbieter so etwas benutzen. Es gibt ja Möglichkeiten die Gespräche zu verschlüsseln, aber das so etwas Anwendung findet wusste ich nicht. Die Frage wäre, lässt sich so etwas dann entschlüsseln, liegt das Zertifikat dann auf der Box, wird es bei dem Gespräch neu ausgehandelt? Evtl. weiß PeterPawn etwas. Wenn Du nicht an den Parametern gedreht hast, scheint Deine Box dies manchmal zu benutzen, manchmal nicht. evtl. konnte sie keine sichere Verbindung aushandeln, dann hat sie eine normale geholt?
Und wenn man es nicht deaktivieren kann, wäre auch schlecht.

Bei den Changelogs steht ja drin:

• Verbesserung - Interoperabilität bei Nutzung von verschlüsselter Telefonie erhöht
• Verbesserung - Verschlüsselte Telefonie robuster gegen Verbindungsverluste

heisst, dass es da wohl noch Probleme gibt, dachte aber nicht, das Telekom und Co so etwas einsetzen. Wie sehen da die Pakete in Wireshark aus? Fragen über Fragen.

Im Netz findet man eigene Hinweise einiges, das Telekom soetwas einsetz, wusste ich wirklicht nicht.

 

[ctiemann]

Hier von mir neue Erkenntnisse:
Ein manuell aufgezeichneter Stream (1. Internetverbindung) mit http://fritz.box/html/capture.html wird von cap2wav wunderbar extrahiert.
Dabei stieß ich auf die fritzcap-interfaces-table.md im fritzcap-Verzeichnis.
Jetzt die Interface auslesen und fritzcap richtig konfigurieren:

/etc/fritzcap/fritzcap.py --show_interfaces --username xxxxx --password xxxxxxxx

key | Name
2-1 = 1. Internetverbindung

Aufruf fritzcap:

/etc/fritzcap/fritzcap.py --capture_files --decode_files --monitor_calls --cap_interface 2-1 --username xxxxxx --password xxxxxx

und siehe da: Die Audiofiles werden wie gewünscht (siehe Anlage) wieder korrekt aufgezeichnet, ohne die Änderung von hhw 147 am cap2wav File.

Probiert es mal und schreibt, ob ihr den gleichen Erfolg melden könnt.

 

[The_Surfer]

Bezüglich Verschlüsselung habe ich das gefunden:

SRTP Voice verschlüsselt

Hallo, wir sind über einen VDSL Deutschland IP Voice/Data Anschluss mit dem Internet verbunden. SIP über TLS funktioniert aber kein SRTP. Auch ankommende INVITE schlagen nur RTP vor. Ab wann wird SRTP von der Telekom unterstütz? Mfg Dersch

telekomhilft.telekom.de

Soweit ich es rausfinden konnte, hat die Telekom ab 2015 gesagt, sie würde so etwas anbieten, 2018 war es da halbwegs soweit, aber wohl kann nicht jeder Server dies verarbeiten. Wie jetzt der Stand ist keine Ahnung.

Archiviert | Telekom hilft Community

Ihre Anlaufstelle für spannende Diskussionen, interessante Blogbeiträge, Vorschläge, Produkttests und gesammeltes Knowhow zu Telekom-verwandten

telekomhilft.telekom.de

Alles sehr interessant, mit SRTP usw.

Seit FritzOS 7.19 wurden dieses Sachen seitens AVM integriert, da aber das Thema ja wohl bei allen beteiligten nicht so einfach bzw. standardisiert ist, ist es wohl eine "never endig Story".

Auf fritzcap bezogen, sollte man es soweit möglich deaktivieren, da man ja sonst den verschlüsselten Traffic noch zusätzlich entschlüsseln müsste.

 

[ctiemann]

Auf fritzcap bezogen, sollte man es soweit möglich deaktivieren, da man ja sonst den verschlüsselten Traffic noch zusätzlich entschlüsseln müsste.

Verschlüsselt mit einer FRITZ!Box telefonieren | easybell

Hier finden Sie verschiedene Anleitungen zur Einrichtung der FRITZ!box an einem easybell-Telefonanschluss.

www.easybell.de

Somit auch die Möglichkeit, es zu deaktivieren.
Bei mir steht es ähnlich, Artikel bezieht sich vermutlich auf eine "EasyBell" gebrandete Fritzbox.

 

[Bowf]

Der Wechsel zwischen verschlüsselt und nicht verschlüsselt hängt bei mir mit der Softwareversion zusammen. Bei 7.29 war immer verschlüsselt, nach Wechsel auf 7.28 nicht mehr verschlüsselt.

 

[ctiemann]

Der Wechsel zwischen verschlüsselt und nicht verschlüsselt hängt bei mir mit der Softwareversion zusammen. Bei 7.29 war immer verschlüsselt, nach Wechsel auf 7.28 nicht mehr verschlüsselt.

Hast du mal ein Screenshot von deinen Einstellungen bei der FB? Ist deine "gebrandet"? Ggf. TR-064 abschalten.
So sieht es bei mir aus (FB 7590 Software 07.29):

Bild gemäß Boardregeln als Vorschaubild eingebunden by stoney

 

[The_Surfer]

Könnte man das Ganze mit Mehraufwand doch decodieren?

Frequently Asked Questions :: Zoiper

Zoiper

www.zoiper.com

und

GitHub - cisco/libsrtp: Library for SRTP (Secure Realtime Transport Protocol)

Library for SRTP (Secure Realtime Transport Protocol) - GitHub - cisco/libsrtp: Library for SRTP (Secure Realtime Transport Protocol)

github.com

Puhh, gut das bei mir noch alles onle RTP ist.

Soweit es verstanden habe, ist SRTP nur solange sicher, wenn die Masterkyes nicht im Klartext übertragen werden, und dazu bedarf es noch TLS/SSL, wenn das nicht so ict, kann man einen SRTP Stream entschlüsseln, wenn der INVITE per Klartext erfolgt.