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

JohnDoe42 · 30 Jun 2014

Ich denke, dass Du zuerst mal herausfinden solltest, warum die Daten in G723 kodiert sind; Standard für VoIP wäre beispielsweise PCMA und/oder PCMU ( s. RTP-PAyload-Typ 0 oder 8 ). Seit wann klappt denn das Dekodieren nicht mehr ?
Hat es mit Daten aus der gleichen Quelle und der gleichen Fritzcap-Version jemals jeklappt ?
Außerdem scheint die Paketlänge für G723.1 78 Bytes zu sein .....

RainerKeim · 30 Jun 2014

Evtl. wird das ja auch nur von dem Script falsch gezeigt mit Payload type 4. Folgendes sagt Wireshark:
Payload: g711A (G.711)
Frame length: 298 bytes

Ich kann das cap-file sonst auch hier mal anhängen, wenn das hilft.

Das Dekodieren hat noch nie funktioniert bisher.

JohnDoe42 · 30 Jun 2014

Auf welchem Gerät läuft denn das Script ?
Das das Script den Payload-Typ direkt aus dem (12 Byte langen) Header jedes Paketes liest, würde ich eher davon ausgehen, dass Wireshark hier etwas falsches liefert ...

RainerKeim · 30 Jun 2014

JohnDoe42 schrieb:
Auf welchem Gerät läuft denn das Script ?

Auf einem Raspberry Pi

JohnDoe42 · 30 Jun 2014

Kannst Du Fritzcap testweise mal auf einem anderen Gerät (NAS, Laptop etc.) laufen lassen, um den Fehler etwas einzugrenzen ?
Entsteht Dein o.g. Fehler, wenn Du ein Capture-File per Hand dekodieren willst ?

RainerKeim · 30 Jun 2014

Habs jetzt auf nem Windows-Rechner probiert mit dem gleichen Ergebnis. Wenn ich das Capture File einfach mit -d dekodieren will, klappt es auch nicht. Es passiert einfach nichts, keine wav Datei wird geschrieben.

Edit: Wie gesagt: Wireshark bekommt einen "glasklaren" Ton hin. Mit sämtlichen anderen Command-KLine Tools bekomme ich nur etwas sehr verrauschtes hin. Mit Fritzcap zur Zeit leider gar nichts :-( Ich glaube aber, dass es nur ene Kleinigkeit ist... nur welche...

JohnDoe42 · 30 Jun 2014

Dann kann es nur an dem Dekodier-Modul liegen bzw. einem nicht zu den Audio-Daten passenden Codecs.
Dann mußt Du Dich wohl mit genau diesem Modul ein wenig auseinandersetzen und ggfs. den Code erweitern.

Edit:
Als ersten Ansatz würde ich mir für ein ganz kurzes File nach dieser Zeile

Code:

(streamsetup, payloadtype, seqnr, timestamp, ssi) = struct.unpack('>BBHLL', packet[candidate['offs']-12 : candidate['offs']])

mal den Inhalt des Structs ausgeben lassen und schauen, ob wirklich Payload-Typ = 4 ist.

RainerKeim · 30 Jun 2014

Ich habe ja oben die lenmap erweitert, allerdings habe ich bei offs einfach mal 54 eingetragen, weil ich es nicht besser wusste. Wie bekomme ich denn heraus, welcher Wert da rein muss. Da der Wert ja in der Zeile, die du erwähnt hast, berücksichtigt wird, könnte das ja schon die Ursache für den Fehler sein.

JohnDoe42 · 30 Jun 2014

Ich meinte eigentlich, daß Du das unmodifierte Script laufen lassen sollst und die g711_decoder.py um die eine Debug-Zeile erweitern solltest um zu schauen, welchen Payload-Typ Deine gecaptureten Daten haben ...

RainerKeim · 30 Jun 2014

Wenn ich das Script nicht modifiziere, komme ich dort nie an, denn diese Bedingung davor liefert immer false:
if len == candidate['len']:

Die Länge meiner Pakete beträgt 298 bytes und den Eintrag gibt's in der lenmap nicht.

JohnDoe42 · 30 Jun 2014

Wie wär' 's mit Auskommentieren von dem If-Statement ... ?

RainerKeim · 30 Jun 2014

JohnDoe42 schrieb:
Wie wär' 's mit Auskommentieren von dem If-Statement ... ?

Dann fehlt mir der passende candidate:
(streamsetup, payloadtype, seqnr, timestamp, ssi) = struct.unpack('>BBHLL', packet[candidate['offs']-12 : candidate['offs']])

Ich stoße dann auf das gleiche Problem: Welchen offs-Wert muss ich angeben?

JohnDoe42 · 30 Jun 2014

Wie ist die Box angebunden, über ADSL oder VDSL ?
Für den Fall DSL über PPPoE scheint der Offset 72 zu sein ...

RainerKeim · 30 Jun 2014

Ist kein DSL, habe eine Glasfaserverbindung. Die FritzBox hängt über LAN1 an einem externen Modem bzw. Router.

JohnDoe42 · 30 Jun 2014

Dann könnte hier das Problem liegen. Wenn Du Dir die Definition von lenmap anguckst (insbesondere die Kommentare)

Code:

lenmap = [
          # PacketLength, AudioChunkLength, Offset of audio data, descriptive text
          {'len': 306, 'chunk': 240, 'offs': 66, 'encap' : 'VDSL' },        # VDSL
          {'len': 226, 'chunk': 160, 'offs': 66, 'encap' : 'VDSL' },        # VDSL
                                                                            # VDSL ComfortNoise ?? not seen yet
                                                        
          {'len': 232, 'chunk': 160, 'offs': 72, 'encap' : 'DSLPPPoE' },    # DSL (PPPoE)
          {'len': 312, 'chunk': 240, 'offs': 72, 'encap' : 'DSLPPPoE' },    # DSL (PPPoE)
          {'len': 73,  'chunk': 0,   'offs': 72, 'encap' : 'DSLPPPoE' },    # DSL (PPPoE) ComfortNoise
          
          {'len': 214, 'chunk': 160, 'offs': 54, 'encap' : 'DSLETH'  },     # DSL (ETH)
          {'len': 294, 'chunk': 240, 'offs': 54, 'encap' : 'DSLETH'  },     # DSL (ETH)
          {'len': 55,  'chunk': 0,   'offs': 54, 'encap' : 'DSLETH'  },     # DSL (ETH) ComfortNoise
    ]

siehst Du, dass die Payload-Types der Codecs scheinbar für DSL "hardcoded" sind (0,8,13). Du müßtest also versuchen herauszufinden, welcher Codec zu Deiner mit Wireshark ermittelten Paketlänge gehört und den Dekoder entsprechend erweitern.
Dann wäre interessant zu wissen, ob jemand im Forum unterwegs ist, der fritzcap erfolgreich an einem Kabelanschluss betreibt.

RainerKeim · 30 Jun 2014

Es geht!

Habe jetzt folgendes eingetragen:
{'len': 298, 'chunk': 240, 'offs': 58, 'encap' : 'SWNNET' }, # SWNNET

Sehr schön! Vielen, vielen Dank für deine Hilfe. Am Ende war es im Prinzip nur das Offset, das ich korrekt setzen musste. Dabei hat mir diese Sete geholfen: https://downloads.avaya.com/elmodocs2/s8700/cnet/NW_Ref_Ch72.html

Jetzt habe ich nur noch ein kleines weiteres Problem: Das gemixte wav enthält nur den Ton von meinem AB und nicht den Ton vom Anrufer. Das reine Anrufer-wav enthält aber den Ton des Anrufers (das ist ja auch das wichtigste). Idee, woran das noch liegen könnte?

JohnDoe42 · 30 Jun 2014

Wieviele Dateien liegen denn am Ende eines Dekodiervorgangs insgesamt vor ?
Es sollten vier sein: Jeweils ein WAV für Anrufer, Angerufenen und beide gemixt und das Capture-File.
Falls eines fehlt, könnte das auch noch ein Kollateralschaden von den ehemals "falschen" Codecs sein ....

RainerKeim · 1 Jul 2014

JohnDoe42 schrieb:
Wieviele Dateien liegen denn am Ende eines Dekodiervorgangs insgesamt vor ?
Es sollten vier sein: Jeweils ein WAV für Anrufer, Angerufenen und beide gemixt und das Capture-File.
Falls eines fehlt, könnte das auch noch ein Kollateralschaden von den ehemals "falschen" Codecs sein ....

Ich habe sogar vier wav Files:
capture_20140630162630_0_.wav
capture_20140630162630_1_.wav
capture_20140630162630_2_.wav
capture_20140630162630_mix_0_1.wav

JohnDoe42 · 1 Jul 2014

Okay, was genau ist in dem *mix_0_1.wav zu hören ?

rhb5 · 2 Jul 2014

Hallo zusammen!
ich bin neu hier und habe schon einiges durch gelesen. Die Möglichkeit Gespräche aufzuzeichnen finde ich sehr gut und ich brauche es auch sehr dringend!
Gibt es denn irgendwo eine Schritt für Schritt Anleitung, wie man das ganze zu erst mal installiert und dann auch benutzt? Für alle, die sich mit PC nicht so gut auskennen.
Dafür wären auch andere Neulinge bestimmt sehr dankbar und man hätte deutlich weniger Beiträge im Forum.

Mit vielen Dank schon mal im Voraus und Gruß,

rhb5.

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

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Statistik des Forums