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

[MPFG]

Stimmt, bei den Betas lief es bei mir auch nicht.
Wie findet man den Startstring heraus ?

 

[The_Surfer]

Ich weiß nicht, ob man die im Quelltext der Seite sieht, wahrscheinlich muss man tiefer in die sourcen rein. Gibt es da überhaupt schon den Sourcecode für 7.50 bzw. wäre der für die 7.39 wahrscheinlich eher verfügbar.

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Die scheinen alle in der caputure_notimeout zu sein. Kann mir jemand die per Pn schicken oder sonst wo hochladen, wenn er auf das System kommt?
Ist wahrscheinlich egal ob 7.50 oder 7.39, sollte unter /usr/www/cgi-bin/ liegen, evtl. kann ich etwas erkennen.

 

[PeterPawn]

Wie findet man den Startstring heraus ?

Zum Beispiel indem man mit einem (PC-)Browser erst einmal einen solchen Mitschnitt startet und dabei mit den Developer-Funktionen (bei den meistgenutzten Programmen mittels der Taste F12) die dabei ausgeführten Requests analysiert.

---

Allerdings kann/will/werde ich dabei höchstens mit allgemeinen Ratschlägen helfen, denn diese Software hat - so sie denn schon bei eingehenden Telefonaten aktiv ist - einen "Geburtsfehler" ... sie zeichnet bereits OHNE die Zustimmung aller Teilnehmer Daten auf und sie ist - anders als andere Tools, die auch noch weitere Verwendungszwecke haben - nur bzw. deutlich überwiegend auf diese Aufgabe ausgerichtet.

Nur ist das Aufzeichnen in D ohne die Einwilligung ALLER Teilnehmer nur in sehr begrenzten Ausnahmefällen gestattet: https://www.heise.de/hintergrund/Te...-des-Datenschutz-und-Strafrechts-4671424.html (es gibt den Artikel auch noch in der Spiegel Netzwelt, wo er nicht hinter einer Paywall versteckt ist - ich würde grundsätzlich kein heise+ abonnieren) und die vorliegende Software bzw. die aktuelle Implementierung von fritzcap bietet für mich keinerlei ersichtliche Vorkehrungen (mal abgesehen von einem "Warnhinweis" im GitHub-Repo), etwas gegen einen rechtswidrigen Einsatz der Software zu unternehmen. Gerade dann, wenn schon beim Aufbau einer Verbindung (durch das "Lauschen" an der CallMonitor-Schnittstelle) auch eine Aufzeichnung gestartet wird, halte ich es für äußerst unwahrscheinlich, daß der Gesprächspartner schon VOR der Aufzeichnung informiert werden und seine Zustimmung erteilen kann.

Die Aufzeichnung eines Gesprächs auf dem AB der Box (die man mit einem passenden FRITZ!Fon starten kann) erfolgt ja nicht ohne Grund auch erst NACH der Frage (auf dem Display des Gerätes), ob alle Teilnehmer der Aufzeichnung zugestimmt haben.

DAS macht dann aber die Software zu einem eher riskanten Projekt im Hinblick auf §202c Abs. 1 Nr. 2 StGB - und da passe ich immer sehr genau auf, daß ich zu solchen Projekten nichts (Relevantes) beitrage. Sorry, ist aber nun mal so ... das mag in den Niederlanden schon wieder anders aussehen (da kenne ich mich zu wenig aus), zumal es den "Hackerparagraphen" dort m.W. nicht gibt.

---

Ansonsten kann ich aber bestätigen, daß beim Start im Request die Parameter sid (mit der Session-ID), capture=Start, snaplen=1600, filter=<hier käme jetzt ein Filter-Ausdruck, wie ich weiter vorne bzw. irgendwo in einem weiter vorne auch verlinkten Thread zu einer Laborversion schon geschrieben hatte> und ifaceorminor=<interface> enthalten sind, während in einem Request zum Beenden der (asynchronen) Aufzeichnung neben der SID noch die Parameter iface=<interface-name>, minor=<interface-id>, type=1 (wohl für Ethernet-Interfaces) und capture=Stop enthalten sind, wobei zwei weitere Parameter (useajax und xhr) nur der Tatsache zuzuschreiben sind, daß dieser Stop-Request über XmlHttpRequest() asynchron gesendet wird.

Im ersten Moment war ich auch der Ansicht, das Fehlen des filter-Parameters bei Start des Mitschnitts könnte ein Problem sein (mehr hat sich ggü. älteren Versionen beim Start gar nicht geändert) ... wenn ich mich nicht vertan habe, stört sich das capture_notimeout daran aber nicht. Am Ende haben sich die Requests beim Starten und Beenden der Aufzeichnung (mit Ausnahme des filter-Parameters) gegenüber einer 07.29 nicht wirklich verändert und - wenn ich mir die "Standardkonfiguration" (https://github.com/jpluimers/fritzcap/blob/master/fritzcap.conf#L20) so ansehe - schon bei der 07.29 dürfte ohne geänderte Einstellungen (oder Änderungen am Code) NICHTS mehr funktioniert haben (oder ich verstehe das Programm gar nicht erst).

Nun habe ich allerdings auch gar keine Lust, mir in diesem Thread erst mühsam zusammenzustoppeln, wer da welche Konfigurationsdatei verwendet und wie letztlich die erzeugten Requests aussehen. Das alles gehört zu einer vernünftigen(!) Fehlermeldung/-beschreibung dazu (zumindest wenn es definitiv geändert wurde ggü. dem Stand im Repo) und es gibt ja ganz offensichtlich auch ein Debug-Log, was hier (zumindest ab Seite 24) auch noch niemand "gezeigt" hat und wo man ja vieles sehen würde, was man jetzt nur "raten" muß.

---

Man muß für Experimente mit den richtigen Parametern für einen Request auch nichts an den Python-Files ändern ... immerhin steht mit start_str und stop_str eine Konfigurationsoption bereit (Link s.o.), bei der man zusätzliche Parameter (wie das capture=Start) auch angeben kann und selbst filter sollte auf diesem Weg funktionieren, wenn man den Ausdruck korrekt als URL-Bestandteil aufbereitet.

Für den Start-Request gibt es - neben der start_str - noch ifaceorminor und die sid, die automatisch hinzugefügt werden (https://github.com/jpluimers/fritzc...fcec9a05d683f4fe/core/capture_monitor.py#L247) und daß der Stop-Request nicht mehr zu dem paßt, was AVM da aktuell verwendet, sieht man (mit den oben stehenden Erläuterungen, was beim Stoppen im Request angegeben wird) auch auf den ersten Blick: https://github.com/jpluimers/fritzc...fcec9a05d683f4fe/core/capture_monitor.py#L264 - anstelle von ifaceorminor werden dort jetzt zwei (bzw. vermutlich sogar drei) getrennte Werte verwendet.

Das mag u.a. damit zusammenhängen, daß AVM diese Requests jetzt jeweils in einem IFRAME-Element innerhalb ihrer SPA ausführen läßt - immerhin sind (ggf. funktionierte das früher auch schon) damit dann auch mehrere parallele Aufzeichnungen möglich.

Ein "überflüssiges" ifaceorminor sollte beim Stoppen aber nicht stören und zum Testen kann man die beiden getrennten Parameter (iface und minor, ggf. auch noch type) auch erst einmal in der stop_str fest verdrahten, bevor man sich (bei erfolgreichem Test) dann ans Werk macht, den ifaceorminor-Wert im Python-Code in getrennte Werte zu zerlegen (erst mal ermitteln, was denn nun 1-wan genau bedeuten soll ... ich tippe ja mal darauf, daß die 1 hier eigentlich der type-Parameter wäre).

Das war's dann auch erst mal ... ich werde selbst an dieser Stelle nicht tätig werden, da muß sich schon jemand anderes berufen fühlen und auch eine "lobende Erwähnung":

PeterPawn ist da topfit in diesen Sachen.

ändert daran nichts.

 

[MPFG]

Hi,

wie viel Arbeit ist es denn eine Aufzeichnen-Funktion per Tastendruck einzubauen?
Ich denke, das wäre im Interesse vieler.

Und welche Schnittstelle ist jetzt die voip Schnittstelle ?
https://github.com/jpluimers/fritzcap/blob/master/fritzcap-interfaces-table.md

Neuere Firmwares bekommen immer mehr Schnittstellen, aber meist nur 2-1und 1-lan sind die ersten,
die sich an der Erfassung von VoIP-Gesprächen versuchen.

url_start = self.base_url + '/cgi-bin/capture_notimeout' + '?sid=' +self.SID + '&capture=Start&snaplen=1600&filter=&ifaceorminor=2-1'
if self.SID != '':
url = url_start # + "&sid=%s" % self.SID
else:
url = url_start

Mit 1-lan wird eine cap Datei mit Inhalt erzeugt. -----> Seems, there is no valid PCAP file
Mit 2-1 wird eine leere cap Datei mit 0 kb erzeugt

Hat schon jemand andere Erfahrungen ?

 

[Erik72]

7590 auf 7.29 zurückgeschraubt ...läuft !
Also liegt es definitiv an der Version 7.5

 

[MPFG]

@ Erik72, muss man dann die ganze Box einrichten ? Oder bleiben die Daten erhalten ?

 

[Erik72]

Leider alles neu einrichten. Schade, dass niemand in der Lage ist fritzcap unter 7.5 lauffähig zu machen. Ich fand die 7.5 gar nicht mal so schlecht. Warten wir mal ab, bis die Könner aus dem Skiurlaub zurückkehren

 

[PeterPawn]

Ich bin ja nur verblüfft, daß sich so gar niemand berufen fühlt, die Tipps aus #483 (dritter Abschnitt + die ersten drei Absätze im vierten) einfach einmal auszuprobieren. Dazu muß man - wie schon geschrieben - NICHTS an den (unveränderten - im Vergleich zum von mir verlinkten Repo) Python-Quellen ändern, es reicht bereits, die passenden Werte in start_str und stop_str zu konfigurieren.

Aber weder finde ich in diesem Thread (in den letzten Monaten, wo er sich um die 07.50 dreht) etwas zu einem eigenen Versuch (von irgendjemandem), das über die Konfigurationsdatei anzupassen (und das ist dann deutlich smarter, als irgendwelche (auch noch unterschiedlichen) Patches der Python.-Quellen, die hier immer mal wieder verstreut sind), noch kann ich IRGENDEIN Protokoll sehen, in dem wenigstens mal ansatzweise versucht wurde, die diversen Aufrufe der Log-Funktionen, die in den Quellen verteilt sind, auch wirklich zu aktivieren (https://github.com/jpluimers/fritzcap/blob/master/logging.conf).

Das Ergebnis solcher Bemühungen müßte man dann natürlich auch noch hier "vorzeigen" wollen ... aber wenn das Thema für diejenigen, die diese Software weiterhin nutzen wollen, nicht wichtig genug ist für eine eigene Initiative: Warum sollte das bei anderen, welche die Software gar nicht selbst benötigen oder verwenden wollen, irgendwie anders sein?

Keiner verlangt von Laien, sich selbst an die Änderung von Quelltexten zu machen ... aber als Minimum kann/sollte man zumindest die Bereitschaft zu eigener Initiative beim Testen erwarten können.

 

[Fritzchen9]

Zwischen den Versionen 07.29 und 07.50 gibt es folgenden Unterschied:
In Der Version 07.29 wird beim Starten des Mitschnitts eine Datei *.cap angelegt. Diese wird dann im weiteren Verlauf gefüllt. In der Version 07.50 wird beim Starten des Mitschnitts zwar auch eine Datei *.cap angelegt, die aber sofort wieder geschlossen wird. Wenn man den Paketmitschnitt über das Menü in der Fritzbox startet, wird zunächst eine Datei *.cap angelegt und sofort wieder geschlossen. Anschließend wird eine Datei mit weitgehend gleichem Namen und der Endung .part angelegt. Nach dem Stoppen des Mitschnitts wird die Datei *.part in die *.cap kopiert.

Die Start- und Stop-Strings lauten im Moment:
start_str = ?start=1&start1=Start
stop_str = ?stop=1&stop1=Stop
Zum Starten des Mitschnitts wird folgender String an die Fritzbox gesendet (aus der log_debug.txt):
2023-01-09 14:01:07,033 [ Thread-3::5704 ] [DEBUG ] [ tracer::run_logic ] Trace started (url:'http://192.168.148.1/cgi-bin/capture_notimeout?start=1&start1=Start&ifaceorminor= &sid=41c4e8dcfb2dbdb5', filename:'captures/2023-01-09/140107/capture_20230109140107.cap')
An welcher Stelle und in welcher Form müsste ich jetzt weitere Parameter angeben, damit es sich um einen gültigen String handelt? In dem Punkt bin ich ziemlich unbedarft.
Schönen Tag noch
Fritzchen

 

[PeterPawn]

Die gesamte, im ersten Absatz in #489 beschriebene, Behandlung von Downloads ist Sache des Browsers, darauf hat weder das FRITZ!OS einen Einfluß, noch muß es ein anderer "Client" ebenso machen. Die Box liefert (aus ihrer Sicht) einen ständigen (ggf. noch - als Vorschlag - benannten) Strom von Daten, bis sie (asynchron) zum Stoppen des Mitschnitts aufgefordert wird und dann ihrerseits das Ende des Downloads signalisiert - anders als bei simplen "Datei-Downloads" ist hier nämlich auch die Datenlänge am Beginn noch unklar, daher gibt es auch keine "Sonderfunktionen", die auf bekannter Länge basieren, wie z.B. die "Wiederaufnahme" von nur teilweise geladenen Dateien.

Und wie ich hier: https://www.ip-phone-forum.de/threads/fritzcap-tool-für-etherreal-trace-und-audiodaten-extraktion-v2-0.232682/post-2497336 schon schrieb (im dritten Absatz), wären beim aktuellen FRITZ!OS die Parameter:

• sid
• capture=Start
• snaplen=1600
• filter= und
• ifaceorminor=<interface>

erforderlich, was dann - da die sid automatisch hinzugefügt wird im Python-Code (https://github.com/jpluimers/fritzc...fcec9a05d683f4fe/core/capture_monitor.py#L249) - zu einem start_str mit ?capture=Start&snaplen=1600&filter= führen sollte, wobei der ifaceorminor-Parameter ebenfalls automatisch hinzugefügt werden sollte (https://github.com/jpluimers/fritzc...fcec9a05d683f4fe/core/capture_monitor.py#L247) mit der passenden Interface-ID. Wobei die in der bisherigen Konfiguration offenbar aber auch fehlt, wenn man sich die erzeugte URL ansieht (ifaceorminor ist leer). Die Reihenfolge der Parameter in der URL ist egal, sie werden anhand des Namens verarbeitet.

Da der Interface-Name aber aus den beim Erstellen des Objekts angegebenen Parametern erzeugt wird, stimmt schon vorher etwas nicht beim Instanziieren des CaptureMonitor-Objekts: https://github.com/jpluimers/fritzc...2fcec9a05d683f4fe/core/capture_monitor.py#L69 - da ich mir nicht vorstellen kann, daß der Request auch ohne gültige Interface-Angabe funktioniert, würde mich schon interessieren, ob das o.g. Protokoll mit diesem Request (der dann auch noch funktionierte) gegen eine Box mit 07.29 erzeugt wurde oder gegen eine 07.50.

Ebenso habe ich im weiter oben stehenden Beitrag schon gezeigt/erzählt, daß der Request zum Stoppen der Aufzeichnung (und erst dann werden auch alle Daten, die sich eventuell in einem Puffer im FRITZ!OS noch angesammelt haben, "geflusht" und das Ende des Datenstroms an den Endpunkt signalisiert, der die Datei mit dem Mitschnitt "empfängt") ebenfalls anders aussehen muß. Darin sind die Parameter:

• sid
• capture=Stop
• iface=<interface-name>
• minor=<interface-id> und
• type=1

anzugeben, wobei sid ebenso automatisch hinzugefügt wird (https://github.com/jpluimers/fritzc...fcec9a05d683f4fe/core/capture_monitor.py#L266), wie der veraltete Parameter ifaceorminor (https://github.com/jpluimers/fritzc...fcec9a05d683f4fe/core/capture_monitor.py#L264), der aber nicht weiter stören sollte, solange stop_str für die beiden (getrennten) Parameter iface und minor jeweils die richtigen Werte enthält. Welche das konkret sind, hängt auch vom Modell der jeweils verwendeten Box ab und von den im FRITZ!OS vorhandenen Interfaces. Aber DASS da eine korrekte Angabe erforderlich ist, ergibt sich schon aus der Tatsache, daß eben mehr als ein Mitschnitt parallel erfolgen könnte und dann unklar wäre, welcher nun zu stoppen ist. Alternative ist wohl der "Alle stoppen"-Button am unteren Ende der Capture-Seite - welche Parameter dabei gesendet werden, habe ich aber nicht ermittelt.

Wenn Du weitere Tests machen solltest und deren Ergebnisse hier einstellst, gib bitte jeweils die Konfiguration (mind. start_str und stop_str) und die FRITZ!OS-Version in der verwendeten Box an ... dann bleiben keine weiteren Unklarheiten, wie das oben leider der Fall ist.

EDIT: Wenn unmittelbar nach dem Start des Mitschnitts schon wieder EOF signalisiert wird (was dann zu einer leeren Datei führt), dann stimmt schon mit dem Start des Mitschnitts etwas nicht.

 

[NDiIPP]

@Fritzchen9
Bitte die Logs in Code-Blocks setzen. Oder als Anhang. Aber nicht direkt so in den Text! Und dabei am besten auch gleich neu aus der Quelle einfügen denn durch das direkte reinkopieren ohne Code-Tags wurde die Logs durch die Forensoftware bereits modifiziert (BBCode).

 

[Fritzchen9]

Hallo PeterPawn

1. Im start_str führst du den Parameter ifaceorminor auf. Beim stop_str schreibst du von den Parametern iface und minor. Ist das richtig, dass start_str und stop_str in diesem Punkt unterschiedlich sind?

2. Wenn ich in der Datei fritzcap.conf start_str und stop_str um die von dir genannten Parameter ergänzen will, muss ich wohl auch im Code eingreifen und dafür sorgen, dass die Parameter ifaceorminor, iface und minor nicht ergänzt werden, richtig?

3. Ist es richtig, dass die Parameter lückenlos zusammengepackt werden - ohne Komma ohne Blank?

4. Den Interface-Namen und die Interface-Id habe ich noch nicht ermittelt. Ich vermute, dass es sich beim Namen um eth0 handeln könnte. Dann würden die Strings z.B. so aussehen:
start_str = ?start=1&start1=Startcapture=Startsnaplen=1600ifaceorminor=eth0filter=
stop_str = ?stop=1&stop1=Stopcapture=Stopiface=eth0minor=0type=1
Was kann bzw. sollte man bei filter= angeben oder bleibt das leer?
Woher weiß das System z.B. bei iface=eth0minor=0, dass der Interface-Name nicht eth0minor ist?
Was bedeutet so eine Angabe wie &stop1 (also das &-Zeichen)?

5. Von 2 Mitschnitten füge ich die beiden Dateien
log_debug_07_29.txt und log_debug_07_50.txt hinzu.
Dabei habe ich bislang noch nichts verändert. Die Strings lauten:
start_str = ?start=1&start1=Start
stop_str = ?stop=1&stop1=Stop
Bei beiden Boxen handelt es sich um das Modell 7590.
Ich hoffe, dass ich jetzt keine Angabe vergessen habe.

Schönen Tag noch
Fritzchen

 

[PeterPawn]

Ist das richtig

Ja, einfach zu überprüfen, indem man mal mit den Developer-Tools des eigenen Browsers nachsieht, was beim Starten und Stoppen eines Mitschnitts übermittelt wird.

dass die Parameter ifaceorminor, iface und minor nicht ergänzt werden, richtig?

Nein, vollkommen falsch. Wie kommst Du darauf? Du mußt nur dafür sorgen, daß da jeweils RICHTIGE Werte verwendet werden und "überzählige" Angaben, die derzeit im Python-Code automatisch ergänzt werden, sollten nicht weiter stören.

Aber ich dachte, ich hätte das in #483 und #490 schon zweimal geäußert ... hast Du denn BEIDE Beiträge gelesen und auch verstanden?

ohne Komma ohne Blank?

Ja. https://de.wikipedia.org/wiki/Uniform_Resource_Locator

Ich vermute, dass es sich beim Namen um eth0 handeln könnte.

Wie kommst Du darauf?

eth0 ist das (interne) Synonym für den LAN1-Port - solange Du da nicht irgendein IP-Telefon angeschlossen hast, dessen Traffic Du mitschneiden willst, dürfte das (und zwar unabhängig vom "Betriebsmodus" der Box, denn die 7590 hat einen dedizierten WAN-Port und der hat dann auch - selbst beim Betrieb als Router über genau diesen Port - den internen Namen wan) eher das falsche Interface sein.

Wenn es um Internet-Traffic geht, dann sollte man auch das Interface internet verwenden (so, wie ich es oben bei den Screenshots gemacht habe) ... nur dann, wenn die Telefonie über eine gesonderte Verbindung abgewickelt werden sollte, wäre ein anderes Interface (das dann üblicherweise auf den Namen voip getauft wurde) das richtige.

Was kann bzw. sollte man bei filter= angeben oder bleibt das leer?

Bitte LIES einfach, was ich zuvor dazu geschrieben habe ... und zwar mindestens ab #472 und auch der dort stehende Link (auf einen anderen Thread in diesem Board) sollte von Dir nicht ignoriert werden.

Was bedeutet so eine Angabe wie &stop1 (also das &-Zeichen)?

S.o. beim Link zum Aufbau einer URL.

Ich hoffe, dass ich jetzt keine Angabe vergessen habe.

Ja und nein.

Die von Dir in den Beitrag eingefügten Protokolle waren leider "Fließtext" und nicht korrekt in passende Tags eingeschlossen. Daher bat ich (einen Moderator) per "Melden" darum, diese Zeilen in CODE-Tags einzuschließen ... dabei ist offenbar etwas schief gelaufen.

Aber das, was @NDiIPP Dir oben dazu geschrieben hat, kann ich nur unterstreichen ... das MUSST Du aber mit den alten Daten jetzt nicht erneut probieren.

Bei dem, was man dennoch in der Bleiwüste erkennen konnte, fällt auf, daß auch beim Funktionieren des Mitschnitts bei der 07.29 KEINE gültige Interface-Parametrierung erfolgt(e) und damit ist es wohl eher "Glück", wenn vorhergehende FRITZ!OS-Versionen auch bei fehlendem ifaceorminor-Parameter irgendwelche sinnvollen Mitschnitte geliefert haben - bei der 07.29 sieht der Code in den Lua-Dateien so aus:

229 if box.post.start then
230 box.post.start = fix_ie7(box.post.start)
231 http.redirect("/cgi-bin/capture_notimeout?ifaceorminor="..box.post.start.."&snaplen="..box.post.len.."&capture=Start")
232 end
233 if box.post.stop then
234 box.post.stop = fix_ie7(box.post.stop)
235 local t, m, n = string.match(box.post.stop, "(.*);(.*);(.*)")
236 http.redirect("/cgi-bin/capture_notimeout?iface="..n.."&minor="..m.."&type="..t.."&capture=Stop")
237 end
238 if box.post.stopall then
239 http.redirect("/cgi-bin/capture_notimeout?iface=stopall&capture=Stop")
240 end

Schon DA wird also direkt der Parameter start (aus dem Request für die capture.lua, der aber von fritzcap gar nicht genutzt wird) in den Request für capture_notimeout als Parameter ifaceorminor(!) übernommen und in den AVM-Requests (für capture_notimeout) gibt es gar keine Parameter start und start1 mehr - und damit verläßt man sich bei AVM selbst auch nicht darauf, daß ein fehlender Wert für ifaceorminor schon IRGENDWIE dazu führen wird, daß das Interface internet für den Mitschnitt genutzt wird. Aber hier sieht man auch gleich, daß beim oben auch erwähnten "Alle stoppen"-Button dann stopall als iface verwendet wird und daß auch an DIESER Stelle schon (und zwar auch in der 07.29) beim Stop-Request eine Aufteilung der Parameter für die Angabe des Interfaces erfolgt(e).

Putzigerweise hat sich diese Stelle im Lua-Code auch bei der 07.50 kaum verändert (oder auch gar nicht, er ist nur etwas "verschoben" in der Datei):

237 if box.post.start then
238 box.post.start = fix_ie7(box.post.start)
239 http.redirect("/cgi-bin/capture_notimeout?ifaceorminor="..box.post.start.."&snaplen="..box.post.len.."&capture=Start")
240 end
241 if box.post.stop then
242 box.post.stop = fix_ie7(box.post.stop)
243 local t, m, n = string.match(box.post.stop, "(.*);(.*);(.*)")
244 http.redirect("/cgi-bin/capture_notimeout?iface="..n.."&minor="..m.."&type="..t.."&capture=Stop")
245 end
246 if box.post.stopall then
247 http.redirect("/cgi-bin/capture_notimeout?iface=stopall&capture=Stop")
248 end

- damit dürfte es noch deutlich MEHR Glück gewesen sein, wenn jemand mit fritzcap (bei ungepatchten Quellen) überhaupt etwas aufzeichnen konnte und eigentlich deutet das am Ende sogar darauf hin, daß AVM da einigermaßen schlampig bei der Überprüfung von Parametern im Request arbeitet(e).

Nur klappt das vielleicht mit der 07.50 nicht länger ... mein Vorschlag wäre es daher, daß Du (bzw. auch alle anderen, die das mal RICHTIG benutzen wollen) den Aufruf einfach um die korrekte Interface-ID ergänzt (und das wäre immer noch 3-17 bei der 7590 - nur würde ich die explizit angeben und mich nicht darauf verlassen, daß das schon das Standard-Interface sein wird) und die richtigen Parameter beim Request für das Stoppen der Aufzeichnung zunächst mal statisch in der Konfiguration hinterlegst.

Ich mach's vielleicht doch mal extra plakativ und sicher gegen "Mißverständnisse" ... wie die Angabe bei start_str aussehen sollte, habe ich zuvor schon EXAKT aufgeschrieben ... das, gepaart mit einem Aufruf mit korrektem --cap_interface-Parameter (nämlich 3-17, wie man im ersten Screenshot sehen kann), sollte schon mal zum erfolgreichen Start einer Aufzeichnung führen. Nimmt man dann noch einen Wert von ?iface=internet&type=3&minor=17&capture=Stop für stop_str, sollte auch das Beenden der Aufzeichnung wieder funktionieren - allerdings stimmt meine Angabe von type=1, die ich irgendwoanders mal gemacht habe, wohl nicht, denn die Vermutung, daß die 1 für ein Ethernet-Interface stehen könnte, stimmt ja offensichtlich nicht bzw. internet ist dann ja kein "reines Ethernet-Interface", sondern ein virtuelles auf dev dsl.

Für das Ermitteln der korrekten Interface-Namen auf der eigenen Box hat (a) fritzcap einen passenden Parameter (--show-interfaces), wobei dort die Daten aus der HTML-Ausgabe der capture.lua wieder herausgepolkt werden (https://github.com/jpluimers/fritzc...cec9a05d683f4fe/core/interfaces_dumper.py#L53), was m.E. aber (b) auch einfacher geht, wenn man auf die query.lua von AVM zurückgreift - allerdings ist die ebenso "undokumentiert" wie der Aufbau des HTML-Codes:

http://<name_or_address>/query.lua?sid=<sid>&q=capture:settings/iface/list(name,minor,type,if_nr)

ergibt dann folgendes als JSON-Daten:

{"q":[{"_node":"iface0","type":"2","name":"wan","minor":"1","if_nr":"1"},{"_node":"iface1","type":"4","name":"WLAN Management Traffic","minor":"128","if_nr":"0"},{"_node":"iface2","type":"3","name":"all","minor":"0","if_nr":"-1"},{"_node":"iface3","type":"1","name":"cpunet0","minor":"-1","if_nr":"-1"},{"_node":"iface4","type":"1","name":"eoam","minor":"-1","if_nr":"-1"},{"_node":"iface5","type":"1","name":"eth0","minor":"-1","if_nr":"-1"},{"_node":"iface6","type":"1","name":"eth1","minor":"-1","if_nr":"-1"},{"_node":"iface7","type":"1","name":"eth2","minor":"-1","if_nr":"-1"},{"_node":"iface8","type":"1","name":"eth3","minor":"-1","if_nr":"-1"},{"_node":"iface9","type":"1","name":"ing0","minor":"-1","if_nr":"-1"},{"_node":"iface10","type":"3","name":"internet","minor":"17","if_nr":"0"},{"_node":"iface11","type":"1","name":"lan","minor":"-1","if_nr":"-1"},{"_node":"iface12","type":"1","name":"ppptty","minor":"-1","if_nr":"-1"},{"_node":"iface13","type":"1","name":"traceDH0","minor":"-1","if_nr":"-1"},{"_node":"iface14","type":"1","name":"traceDL0","minor":"-1","if_nr":"-1"},{"_node":"iface15","type":"1","name":"traceN0","minor":"-1","if_nr":"-1"},{"_node":"iface16","type":"1","name":"traceV0","minor":"-1","if_nr":"-1"},{"_node":"iface17","type":"1","name":"tunl0","minor":"-1","if_nr":"-1"},{"_node":"iface18","type":"5","name":"usb1","minor":"201","if_nr":"0"},{"_node":"iface19","type":"5","name":"usb2","minor":"202","if_nr":"0"},{"_node":"iface20","type":"5","name":"usb3","minor":"203","if_nr":"0"},{"_node":"iface21","type":"5","name":"usb4","minor":"204","if_nr":"0"},{"_node":"iface22","type":"1","name":"wan","minor":"-1","if_nr":"-1"},{"_node":"iface23","type":"1","name":"wifi0","minor":"-1","if_nr":"-1"},{"_node":"iface24","type":"1","name":"wifi1","minor":"-1","if_nr":"-1"},{"_node":"iface25","type":"1","name":"xfrm","minor":"-1","if_nr":"-1"}]}

bei einer 7590, was (etwas schöner formatiert) dann so aussieht:

{
  "q": [
    {
      "_node": "iface0",
      "type": "2",
      "name": "wan",
      "minor": "1",
      "if_nr": "1"
    },
    {
      "_node": "iface1",
      "type": "4",
      "name": "WLAN Management Traffic",
      "minor": "128",
      "if_nr": "0"
    },
    {
      "_node": "iface2",
      "type": "3",
      "name": "all",
      "minor": "0",
      "if_nr": "-1"
    },
    {
      "_node": "iface3",
      "type": "1",
      "name": "cpunet0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface4",
      "type": "1",
      "name": "eoam",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface5",
      "type": "1",
      "name": "eth0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface6",
      "type": "1",
      "name": "eth1",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface7",
      "type": "1",
      "name": "eth2",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface8",
      "type": "1",
      "name": "eth3",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface9",
      "type": "1",
      "name": "ing0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface10",
      "type": "3",
      "name": "internet",
      "minor": "17",
      "if_nr": "0"
    },
    {
      "_node": "iface11",
      "type": "1",
      "name": "lan",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface12",
      "type": "1",
      "name": "ppptty",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface13",
      "type": "1",
      "name": "traceDH0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface14",
      "type": "1",
      "name": "traceDL0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface15",
      "type": "1",
      "name": "traceN0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface16",
      "type": "1",
      "name": "traceV0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface17",
      "type": "1",
      "name": "tunl0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface18",
      "type": "5",
      "name": "usb1",
      "minor": "201",
      "if_nr": "0"
    },
    {
      "_node": "iface19",
      "type": "5",
      "name": "usb2",
      "minor": "202",
      "if_nr": "0"
    },
    {
      "_node": "iface20",
      "type": "5",
      "name": "usb3",
      "minor": "203",
      "if_nr": "0"
    },
    {
      "_node": "iface21",
      "type": "5",
      "name": "usb4",
      "minor": "204",
      "if_nr": "0"
    },
    {
      "_node": "iface22",
      "type": "1",
      "name": "wan",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface23",
      "type": "1",
      "name": "wifi0",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface24",
      "type": "1",
      "name": "wifi1",
      "minor": "-1",
      "if_nr": "-1"
    },
    {
      "_node": "iface25",
      "type": "1",
      "name": "xfrm",
      "minor": "-1",
      "if_nr": "-1"
    }
  ]
}

- das sollte einfacher zu zerlegen sein (nichts anderes macht ja ein "Parser") und "stabiler" im Aufbau, als der HTML-Code, der aus einer Lua-Datei erzeugt wurde.

---

Also: Viel Spaß bei Deinen Tests ... allerdings wäre ich Dir WIRKLICH dankbar, wenn Du (vor der "nächsten Runde") erst einmal die erwähnten/verlinkten Beiträge liest und erst wenn dann IMMER NOCH Fragen offen bleiben, diese hier stellst.

 

[Fritzchen9]

Hallo PeterPawn,
wie ich darauf komme, den Parameter ifaceorminor nicht automatisch ergänzen zu lassen? Wenn der String z.B. von links nach rechts abgearbeitet wird und dabei ein bestimmter Parameter mehrfach gefunden wird, kann man damit auf verschiedene Weise umgehen:
- Es wird ein Fehler zurückgemeldet.
- die erste Angabe wird verwendet und alle weiteren werden ignoriert.
- der Parameter wird bei jedem Fund übernommen und damit gilt der letzte Eintrag.
Um sicherzustellen, dass der von mir gewollte Eintrag zum Zuge kommt, dachte ich, dass man die zweite Angabe vermeiden muss.

Die älteren Beiträge habe ich gelesen. Ok, du hast geschrieben, dass ein weiterer Parameter ifaceorminor nicht stören sollte. Diesen Satz hatte ich offenbar nicht auf dem Schirm. Tut mir leid. Ich weiß, dass man schnell den Eindruck gewinnt, dass die Leute nur die Hälfte gelesen haben. Aber warum warst du da so zuversichtlich? Ist das allgemein bei den Entwicklern so üblich, dass das erste Vorkommen gilt?

NDiIPP hat mich ja mit Recht gerügt, als ich meine Log-Dateien in den Text meines Beitrags kopiert habe. Den Beitrag habe ich gelöscht, neu eingestellt und die Log-Dateien hochgeladen. Aber anscheinend war ich zu langsam.

In #492 habe ich gefragt, ob die verschiedenen Parameter in start_str und stop_str ohne jegliche Trennung hintereinander geschrieben werden und was es mit dem &-Zeichen auf sich hat. In #493 hat PeterPawn den Artikel
https://de.wikipedia.org/wiki/Uniform_Resource_Locator
verlinkt. Das hat mir die Erkenntnis gebracht, dass das &-Zeichen der Trennung von mehreren Parametern dient. Das Zeige ich gleich noch.

Ich habe heute 2 Versuche gemacht. Dabei habe ich mich noch nicht um den Inhalt von filter= gekümmert. Das muss ich noch mal nachlesen. Beim ersten Versuch wurde die Datei unmittelbar nach dem Start sofort wieder geschlossen. Dabei habe ich meine neue Erkenntnis zum &-Zeichen ausgeblendet und mit
start_str = ?capture=Startifaceorminor=3-17snaplen=1600filter=
gearbeitet.

Den zweiten Versuch habe ich mit
start_str = ?capture=Start&ifaceorminor=3-17&snaplen=1600&filter=
stop_str = ?capture=Stop&iface=internet&type=3&minor=17
gemacht. Übrigens: Auch die Parameter, die automatisch hinzugefügt werden, beginnen mit einem &-Zeichen.
Es wurde eine cap-Datei mit Inhalt erstellt. Eine Fehlermeldung, wonach die cap-Datei ungültig sei, gab es nicht. Eine wav-Datei allerdings auch nicht.

Zu guter Letzt noch etwas zur Erklärung:
PeterPawn hat an mehreren Stellen auf Screenshots verwiesen. Ich bin blind und arbeite am PC mit einem so genannten Screenreaderprogramm. Damit kann mir der Inhalt des Bildschirms entweder mit synthetischer Sprache vorgelesen oder Zeile für Zeile in Brailleschrift auf einer mechanischen Zeile dargestellt werden. Das funktioniert aber natürlich nur mit Text. Mit Bildern, also Screenshots, kann ich absolut nichts anfangen. Vielleicht hätte ich schon früher nachfragen sollen. Damit habe ich auch ein Problem, einen Gesprächsmitschnitt nach Rücksprache am Telefon zu starten. Es gibt dafür keine eigene Taste. Man muss das Menü lesen können. Ich habe bei AVM schon mal angeregt, im Menü der Fritzbox eine Startmöglichkeit zu schaffen, was bislang aber nicht passiert ist. Allerdings gehe ich davon aus, dass der Bedarf hierfür sehr klein ist.

Schönen Tag noch
Fritzchen9

 

[PeterPawn]

Aber anscheinend war ich zu langsam.

Ich sehe die Anhänge aber immer noch nicht ... zu langsam war/ist also kein Grund.

dachte ich, dass man die zweite Angabe vermeiden muss.

Da, wo der Parameter automatisch ergänzt wird, soll/muß man für einen (einzelnen) korrekten Wert sorgen (mehrfach auftretende Namen führen tatsächlich i.d.R. zu einem "Array" von Parametern) und da, wo er bei AVM GAR NICHT im Request genutzt wird, muß man ihn auch nicht angeben, schon gar nicht mehrfach. Da sich dabei die Angaben aus ifaceorminor in drei UNTERSCHIEDLICHE Parameter mit abweichenden Namen aufteilen (und keiner davon ifaceorminor lautet), sehe/verstehe ich aber gar nicht erst, was dabei Dein Problem mit DOPPELT angegebenen Werten sein könnte.

Ob ein überzähliges ifaceorminor beim Stop-Request nun Probleme bereitet oder nicht, werden wir ohne die Quellen - also nur "in der Theorie" - ohnehin nicht feststellen können, denn im Gegensatz zu dem, was Du oben beschrieben hast, geht es hier ja gar nicht darum, ob zu verarbeitende Parameter-Namen MEHRFACH angegeben werden oder nicht und damit sind auch Deine drei "Fehlerbehandlungsoptionen" obsolet.

Übrig bleibt die Situation, wo ein zu verwendender Parameter GEZIELT in den übergebenen Daten gesucht wird (die Angaben aus der Query-String einer URL landen bei einem CGI ja im Environment für das aufgerufene Binary in einer Variablen QUERY_STRING: https://en.wikipedia.org/wiki/Common_Gateway_Interface) und dieser ggf. fehlt oder die Alternative, daß man ALLE übergebenen Werte durchgeht und auch auf "unbekannte Werte" prüft.

Dazu zerlegt man die Parameter im Query-String üblicherweise auch erst mal in ein Array aus KV-Sets (Key-Value-Set), wobei key halt der Name und value der Wert des Parameters ist, der dann - bei mehrfacher Angabe - auch wieder ein Array sein kann.

Allerdings wäre so ein Vorgehen schon einigermaßen ungewöhnlich und nur bei sehr, sehr hohen Anforderungen an die Sicherheit gerechtfertigt ... bei AVM würde ich das u.a. auch deshalb bezweifeln, weil ein Stop-Request mit useajax, xhr und einem weiteren Parameter, der in seinem Namen auch noch einen Unix-Timestamp (mit Auflösung von 1/1000 Sekunden) hat und der sich damit naturgemäß jede Sekunde 1000x ändert (t<epoch><ttt>) auch noch andere Angaben enthält, deren Vorhandensein oder Fehlen sich aber offensichtlich nicht auswirkt (diese drei sind eigentlich nur für die Kommunikation zwischen GUI und (GUI-)Server erforderlich). Daher erscheint es EXTREM unwahrscheinlich, daß überflüssige Angaben zu einem Fehler führen - sie werden wohl schlicht ignoriert.

BTW: Der Parameter t1673448275466 im Screenshot (und mittlerweile auch im Alt-Text) bedeutet, daß ich diesen Request am Wed Jan 11 15:44:35 CET 2023 (+ ein paar tausendstel Sekunden, nämlich 466) ausgeführt habe - DAS ist der Parameter, dessen Name sich schon ständig ändert.

Aber wie erwähnt ... endgültigen Aufschluß wird hier nur ein Test mit einer entsprechenden URL geben.

Auch die Parameter, die automatisch hinzugefügt werden, beginnen mit einem &-Zeichen.

Was Dich ja mittlerweile - da Du nun den Aufbau einer URL besser kennst - eigentlich auch nicht mehr verwundern sollte ... sofern etwas an die URL "anzuhängen" ist und sie noch nicht mit einem & endet (was im Nachgang schwerer zu ermitteln ist, als einfach JEDES Anhängen mit einem & zu beginnen), MUSS da eben ein solches Zeichen als Trenner stehen ... und auch das ? als Trennzeichen zwischen Seite und Query-String wurde bei fritzcap vom Autoren halt in die start_str und stop_str übernommen, obwohl man das problemlos (sofern man sicher ist, daß da eine Query-String folgen wird) auch direkt in den Python-Code hätte einbauen können.

arbeite am PC mit einem so genannten Screenreaderprogramm

Und daß Dir Screenshots damit dann nichts bringen (oder nur dann, wenn auch deren Alt-Text einigermaßen aussagekräftig ist), hättest Du ja auch schon mal vorher "erwähnen" können (ich habe lange genug auch Software programmiert, die mit einem Screen-Reader kompatibel sein mußte, damit auch Benutzer mit einer Braille-Zeile damit umgehen konnten) ... die zwei, die ich hier verwendet habe (denn üblicherweise hasse ich die auch, weil man in ihnen auch nichts suchen kann), hätte ich natürlich auch mit alternativen Texten versehen können - was ich mittlerweile auch getan habe.

EDIT:
Da Du ja eigentlich auch den Mitschnitt (bei Bedarf) durch den direkten Start von fritzcap beginnen könntest, bräuchtest Du ja vermutlich eher ein paar kleine Änderungen, die für den Start der Aufzeichnung NICHT erst am CallMonitor-Port auf ein eingehendes Gespräch lauschen (denn diese Benachrichtigung wird natürlich nicht wiederholt), sondern direkt den Mitschnitt von der Box beginnt (keine Ahnung, ob das als Option auch (jetzt schon) machbar ist, schaue ich bei Gelegenheit noch einmal nach), wenn Du (ja, wo eigentlich genau?) eine Aufzeichnung starten willst. Dazu muß dann halt erst einmal die Datenaufzeichnung auch wieder (sicher) funktionieren ... immerhin bist Du mit der gespeicherten Datei ja schon auf einem guten Weg, auch wenn die Umwandlung in eine WAV-Datei noch nicht funktionieren will. DAS wäre sogar wieder rechtlich OK, wenn Du "versicherst", daß Du die Teilnehmer solcher Gespräche um die Erlaubnis zum Mitschnitt gebeten hast und die ihre Zustimmung erteilten - da ist es dann auch plausibel, daß zumindest die Option besteht, die Teilnehmer zu informieren, BEVOR die Aufzeichnung begonnen wird.

EDIT2:
Die im Moment vorhandene Logik funktioniert so, daß ENTWEDER das Monitoring am Port 1012 verwendet werden kann (dann startet ein RING/CALL die Aufzeichnung und ein DISCONNECT beendet sie) oder es erfolgt direkt beim Start eine Aufzeichnung, wobei dann aber ein Gesprächsende (DISCONNECT am Monitor-Port) auch nicht mehr erkannt wird (https://github.com/jpluimers/fritzcap/blob/6203498daf42ecd87cc8e542fcec9a05d683f4fe/fritzcap.py#L276). Das könnte/müßte/sollte man ggf. noch um eine Option ergänzen, die Aufzeichnung SOFORT zu starten und dann aber auch bei Gesprächsende wieder (automatisch) zu beenden - ansonsten müßte man den Abbruch der Aufzeichnung noch gesondert anordnen.

EDIT3:

start_str = ?capture=Start&ifaceorminor=3-17&snaplen=1600&filter=

Wenn Du beim Aufruf gleich noch --cap_interface=3-17 angibst, brauchst Du das in start_str ja nicht machen, denn das wird dann (automatisch) wieder hinzugefügt im Python-Code. SO, wie Du das jetzt gemacht hast, sollten tatsächlich ZWEI Angaben für ifaceorminor in der resultierenden URL stehen und offenbar hat nicht einmal das gestört, wenn die Aufzeichnung funktionierte.

 

[Fritzchen9]

In #491 habe ich Am Mittwoch, 11.01.2023, um 14:47 Uhr die Rüge von NDiIPP bekommen, weil ich den Inhalt der Log-Dateien in den Beitrag kopiert habe.

Daraufhin habe ich meinen kompletten Beitrag gelöscht und um 15:24 Uhr unter #492 neu eingestellt. Ich habe mit Sicherheit die Log-Dateien auch hochgeladen. Denn eine davon habe ich probehalber angeklickt und auch wieder heruntergeladen. Aber dann habe ich vermutlich den Schalter "speichern" vergessen.

Was die Verarbeitung von Parametern betrifft ...
Ich habe auch viele Jahre Software entwickelt. Allerdings komme ich aus der Großrechnerwelt und habe dort fast ausschließlich mit Assembler und ein wenig mit Cobol gearbeitet. Steueranweisungen wurden meist Zeilenweise in eine Textdatei geschrieben bzw. innerhalb einer Zeile durch Komma getrennt. Die Steueranweisungen und deren Parameter wurden meist sehr genau geprüft. Eine Anweisung bzw. ein Parameter, den das Programm nicht kannte, wurde nicht ignoriert sondern führte zu einer Fehlermeldung. Das gleiche galt, wenn ein Parameter fehlte oder mehrfach, womöglich mit unterschiedlichen Werten, angegeben wurde. Nach dem Ende der Großrechnerzeit habe ich mich in Perl und AWK auf einem Linux-System eingearbeitet. Aber CGI, PHP und Client-Server-Kommunikation sind mir weitgehend fremd. Die Sprachen, bei denen alles in geschlossenen Blöcken geschrieben wird und objektorientierte Sprachen erfordern doch eine ganz andere Denkweise.

Wenn ich mich in einem Forum anmelde, will ich nicht gleich damit anfangen: "Ich bin blind. Nun nehmt mal alle Rücksicht auf mich, was z.B. Screenshots angeht." Das Schreiben von aussagekräftigen Alternativtexten macht ja auch wieder einen gewissen Aufwand. In vielen Fällen ist es auch nicht unbedingt erforderlich, wenn man in einem Forum mitliest. Wenn es aber, wie in diesem Fall, wichtig ist, hätte ich mich vielleicht schon früher outen sollen.

Soweit ich weiß, sieht die Auswertung unterschiedlich aus, je nachdem, ob die Aufzeichnung vor Gesprächsanfang startet oder mitten drin.

Die Idee mit dem Parameter --cap_interface=3-17 finde ich gut. Das werde ich ausprobieren.

Schönen Tag noch
Fritzchen

 

[voipjunkie]

Ich steige hier mal ein weil ich gerade auch feststelle, dass unter 7.50 (7590) nur eine leere .cap Datei erstellt wird. Stand ist, also, es geht aktuell noch nichts unter FritzOS 7.50? Oder gibt es noch konkret etwas auszuprobieren? Das würde ich gerne tun, da muss mir aber jemand einen Hinweis geben, sonst springe ich hier von einer Erwähnung zur nächsten und verbringe Stunden damit. Wenn aktuell sowieso nichts geht, muss ich den Aufwand auch nicht machen. Ich nutze das Ganze unter Ubuntu, aber das sollte ja sowieso keine Rolle spielen.

 

[K.Mauser]

Hallo zusammen,
ich habe mich jetzt hier durch alle Beiträge gelesen, da mich dises Thema auch interessiert.
Zunächst vielen Dank an @PeterPawn für die wertvollen Hinweise zu den Start- und Stopp-Parametern der neuen FW 7.50, die mich dazu veranlasst haben die Datei fritzcap.conf entsprechend anzupassen:

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

Bei dem Aufruf von fritzcap muss zwingend das Interface 3-17 angegben werden:

fritzcap.py --capture_files --decode_files --monitor_calls --cap_interface 3-17 --box_name 192.xxx.xxx.1 --user xxxxxxx --password xxxxxxxx

Ergänzend habe ich auch noch im Modul capture_monitor.py in Zeile 264 die Ergänzung des Parameters ifaceorminor entfernt bzw. als Kommentar definiert.

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

Mit diesen Anpassungen startet fritzcap anstandslos und erzeugt bei Anruf auch eine cap-Datei die nicht leer ist. Diese enthält auch die RTP-Streams, die sich z.B. mit WireShark problemlos ansehen bzw. anhören lassen. Der g711-Decoder von fritzcap kann mit der cap-Datei aber in fast allen Versuchen nichts anfangen, er startet erst gar nicht. Ein einziges Mal wurde eine wav-Datei erstellt, die aber außer einem kurzen Geräusch still war.

Die erzeugte cap-Datei muss sich also irgendwie vom Format oder Inhalt von denen, die bei der früheren FW der FritzBox erstellt wurden, unterscheiden. Hat da noch jemand eine Idee, an welcher Stelle ich da suchen kann?

Vielen Dank und Grüße aus dem Norden
Kurt.

 

[voipjunkie]

Ich korrigiere meine Antwort noch einmal nach einem Test mit der Standardkonfiguration und den Änderungen von Kurt:
Die Capture-Datei wird erstellt, diese enthält laut Wireshark aber kein Audio (Telephonie - VoIP Anrufe), sondern ist ein reiner Paketmitschnitt auf Netzwerkebene.

Die erzeugten .wav Dateien sind mit 58 Bytes faktisch leer. Also grundsätzlich sind wir weiter, aber es funktioniert noch nicht wirklich etwas, da ich ja nicht einmal im Wireshark Audio abspielen kann. Das Problem scheint der Unsupported Payload Type 24 zu sein.

Die Meldungen auf der Kommandozeile und im Debug Log:

Code:

2023-04-20 23:33:53,946 - Start capture (capture_file:'captures/2023-04-20/233353/capture_20230420233353.cap').
2023-04-20 23:33:54,022 - Connect (ID:1, ActiveCalls.:1, Caller:02211234, DialedNumber:08001, LinePort:SIP0)
2023-04-20 23:34:01,280 - Disconnect (ID:1, ActiveCalls.:0, Caller:02211234, DialedNumber:08001, LinePort:SIP0)
2023-04-20 23:34:13,190 - Capture finished (capture_file:'captures/2023-04-20/233353/capture_20230420233353.cap').
2023-04-20 23:34:13,190 - Decode process started (worker_id:0, file:'captures/2023-04-20/233353/capture_20230420233353.cap')
2023-04-20 23:34:13,196 - Decode process finished (worker_id:0, file:'captures/2023-04-20/233353/capture_20230420233353.cap')

2023-04-20 23:39:54,656 [ Thread-4::139880461338176] [DEBUG ] [ call_monitor::run_logic ] Wait for call monitor status change.
2023-04-20 23:39:54,657 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::run_logic ] post_capture wait() finished.
2023-04-20 23:39:54,657 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::run_logic ] post_capture wait(9.999445).
2023-04-20 23:40:04,657 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::run_logic ] post_capture wait(9.999445) finished.
2023-04-20 23:40:04,657 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::run_logic ] post_capture release lock.
2023-04-20 23:40:04,657 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::run_logic ] post_capture release lock finished.
2023-04-20 23:40:04,657 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::init_login ] Login attempt to the the FritzBox (box_name:192.168.178.1)
2023-04-20 23:40:04,657 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::init_login ] Call the challange token url (url:'http://192.168.178.1/login_sid.lua')
2023-04-20 23:40:05,044 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::init_login ] SID HTTP result:200
2023-04-20 23:40:05,044 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::init_login ] Call the read seed token url (url:'http://192.168.178.1/login_sid.lua?username=Frank&response=5fa1e83a-999a0856c29b0679de5b4f24ace04da4', data:'login:command/response=5fa1e83a-999a0856c29b0679de5b4f24ace04da4&getpage=../html/login_sid.xml').
2023-04-20 23:40:05,375 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::init_login ] Login HTTP result:200
2023-04-20 23:40:05,375 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::init_login ] Login OK (SID: 297dfbc017f6abf2)
2023-04-20 23:40:05,375 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::sub_stop_capture ] Send capture stop request to the box (url:'http://192.168.178.1/cgi-bin/captur...r=17&type=3&capture=Stop&sid=297dfbc017f6abf2', capture_file:'captures/2023-04-20/233948/capture_20230420233948.cap').
2023-04-20 23:40:05,632 [ Thread-5::139880357156416] [DEBUG ] [ tracer::run_logic ] Trace finished (url:'http://192.168.178.1/cgi-bin/captur...ilter=&ifaceorminor=3-17&sid=d60d08dbe87d7899', filename:'captures/2023-04-20/233948/capture_20230420233948.cap')
2023-04-20 23:40:06,648 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::sub_stop_capture ] Send capture stop request to the box finished (url:'http://192.168.178.1/cgi-bin/captur...r=17&type=3&capture=Stop&sid=297dfbc017f6abf2', capture_file:'captures/2023-04-20/233948/capture_20230420233948.cap').
2023-04-20 23:40:06,648 [ Thread-3::139880452683328] [INFO ] [ capture_monitor::sub_stop_capture ] Capture finished (capture_file:'captures/2023-04-20/233948/capture_20230420233948.cap').
2023-04-20 23:40:06,649 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::sub_stop_capture ] Add captured file 'captures/2023-04-20/233948/capture_20230420233948.cap' to the decoding work queue.
2023-04-20 23:40:06,649 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::run_logic ] pre_capture acquire lock.
2023-04-20 23:40:06,649 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::run_logic ] pre_capture acquire lock finished.
2023-04-20 23:40:06,649 [ Thread-2::139880373941824] [INFO ] [ capfile_worker: process ] Decode process started (worker_id:1, file:'captures/2023-04-20/233948/capture_20230420233948.cap')
2023-04-20 23:40:06,650 [ Thread-3::139880452683328] [DEBUG ] [ capture_monitor::run_logic ] pre_capture wait().
2023-04-20 23:40:06,653 [ Thread-2::139880373941824] [DEBUG ] [ g711_decoder::decode ] Unsupported payload type 24
2023-04-20 23:40:06,654 [ Thread-2::139880373941824] [INFO ] [ capfile_worker: process ] Decode process finished (worker_id:1, file:'captures/2023-04-20/233948/capture_20230420233948.cap')

 

[K.Mauser]

Die Capture-Datei wird erstellt, diese enthält laut Wireshark aber kein Audio (Telephonie - VoIP Anrufe), sondern ist ein reiner Paketmitschnitt auf Netzwerkebene.

Bei mir enthält die cap-Datei immer einen RTP-Stream. (WireShark -> Telefonie -> RTP -> RTP Streams