Ich nerve schon wieder. Hat leider auch nichts gebracht. Kannst du mal die bei dir eingesetzte g711_decoder.py hier 'reinstellen? Nur, um sicher zu gehen, dass es nicht daran liegt. Die cap enthält jede Menge UDP-Pakete, die möglicherweise Telefonie-Inhalte sind?
fritzcap: Tool für Etherreal Trace und Audiodaten-Extraktion v2.0
- Ersteller bor2tom
- Erstellt am
Hey, jetzt funktioniert es.
Es lag ganz offensichtlich am Aufruf von fritzcap.py. Aufgrund eines anderen Lösungsversuchs hier habe ich das Interface mit übergeben:
Das war offensichtlich falsch.
Vielen Dank für deine Hilfe.
Es lag ganz offensichtlich am Aufruf von fritzcap.py. Aufgrund eines anderen Lösungsversuchs hier habe ich das Interface mit übergeben:
Code:
fritzcap.py (...) --cap_interface 2-1 (...)Das war offensichtlich falsch.
Vielen Dank für deine Hilfe.
Zuletzt bearbeitet:
Hallo,
habe die Fritzbox gestern auf 07.39-94022 BETA geupdatet.
Die cap Datei bleibt 0 KB groß.
Hat jemand eine Idee?
MfG
habe die Fritzbox gestern auf 07.39-94022 BETA geupdatet.
Die cap Datei bleibt 0 KB groß.
Hat jemand eine Idee?
MfG
jeroenp
Neuer User
- Mitglied seit
- 24 Jun 2017
- Beiträge
- 9
- Punkte für Reaktionen
- 4
- Punkte
- 3
I am looking for people to maintain and document fritzcap.
Having for now survived metastasised rectum cancer, but still recovering from all the treatments (energy is about 25% of what I used to have), i need to tell you my further health future does not look bright. I have passed the moment of being sad about that and now face it as a fact of life: 90% of my peer group gets back metastases within 10 years time the chance I will make it to age 60 is slim.
It means I am preparing for when things get worse. If in the end things might still continue OK, it means I can have ease of mind instead of being in critical paths of things. Since the only guarantees in life are to die and to pay taxes, that is a good general approach anyway
Since my English is far better than my German writing (reading and speaking is OK, so feel free to respond in German), I have kept current documentation in English despite most of the Frtiz!Box users being in D-A-CH. That need to change to become more balanced.
So in short I am looking for people:
A. extending the current English documentation (mainly in direction of examples, capture interfaces
B. translating current English documentation into German and keep up with changes
C. act as a liaison between this forum and the fritzcap GitHub repository
D. maintain and expand the current code base
Documentation wise, the capture interface - used with the --cap_interface parameter - is kind of important, as in this thread quite a few people bumped into getting that correct. In that respect, I was quite surprised to find zero response to [Wayback/Archive] [Frage] - Looking for input on Fritz!Box capture interfaces | IP Phone Forum. I know you can better given this thread is already 24 pages in size.
Even on the GitHub: jpluimers/fritzcap: Fork of elpatron68/fritzcap which was previously automatically exported from code.google.com/p/fritzcap repository, many people had trouble:
1. finding fritzcap/fritzcap-interfaces-table.md
2. interpreting the information in fritzcap/fritzcap-interfaces-table.md
It means that documentation-wise, that needs to be better so it is easier for people to get started. That will help forum members too.
In addition documentation about configuring encoding in the Fritz!Box correctly (only unencrypted G.711 is supported by fritzcap, and even sometimes that goes wrong) and explaining the why is important. Note that encryption won't be supported as that is impossible without the private key of the VoIP server (even with that, it is kind of hard todo, just search for people that have done it in Wireshark). Other encodings might be possible given the cap2wav shell script floating around this thread.
Both from a code and documentation perspective, it is important to get the GitHub - jpluimers/fritzcap: Issues list synced with this thread.
As I don't have enough energy to get through all the 24 pages, I need help with that.
It would be cool if a few of the regulars in this thread would be so kind to split the pages among them and verify on each page if things asked there are covered in the issues and/or documentation and if not: add a new issue (or update an existing issue) linking to the messages here.
I know the syntax on this forum is vastly different from Markdown used on GitHub, but the issues do not need to be perfectly adhere to the GitHub flavoured Markdown: basic writing and formatting syntax, just plain text is OK (note the The Ultimate Guide to Markdown is easier to get started with Markdown than the GitHub documentation: feels a bit like the AVM documentation where blog posts and forums often are easier to get started with).
For me, I am fine with issues starting with a short broken English introduction section, then continuing the details in German both in rudimentary text. Maybe some volunteers then can help translating those parts in more proper English or Markdown.
Code wise, I am thinking about for instance:
- getting changed postulated in the forum into the fritzcap codebase (for instance there seems to be a fix around for making the capture directories and filenames more descriptive).
- command-line switch to go from internal G.711 support to cap2wav
- compressing to mp3, flac, ogg, aac or other lossy or lossless audio formats
- running fritzcap as a Windows or Linux service
- making fritzcap more robust (autostart features upon failure - needs good failure detection! - or restart after a certain time of inactivity with the chance of missing a call)
I am mainly interested to keep things centered around the GitHub repository as the organisation there is much more suited to link code/documentation/issues than the forum is.
As an intermediate I could start a complete new thread that is only used as liaison between this forum and the GitHub repository.
Please let me know your inputs on that.
A blog post on https://wiert.me asking for maintainers will follow in a few weeks time.
Regards,
--jeroen
Having for now survived metastasised rectum cancer, but still recovering from all the treatments (energy is about 25% of what I used to have), i need to tell you my further health future does not look bright. I have passed the moment of being sad about that and now face it as a fact of life: 90% of my peer group gets back metastases within 10 years time the chance I will make it to age 60 is slim.
It means I am preparing for when things get worse. If in the end things might still continue OK, it means I can have ease of mind instead of being in critical paths of things. Since the only guarantees in life are to die and to pay taxes, that is a good general approach anyway
Since my English is far better than my German writing (reading and speaking is OK, so feel free to respond in German), I have kept current documentation in English despite most of the Frtiz!Box users being in D-A-CH. That need to change to become more balanced.
So in short I am looking for people:
A. extending the current English documentation (mainly in direction of examples, capture interfaces
B. translating current English documentation into German and keep up with changes
C. act as a liaison between this forum and the fritzcap GitHub repository
D. maintain and expand the current code base
Documentation wise, the capture interface - used with the --cap_interface parameter - is kind of important, as in this thread quite a few people bumped into getting that correct. In that respect, I was quite surprised to find zero response to [Wayback/Archive] [Frage] - Looking for input on Fritz!Box capture interfaces | IP Phone Forum. I know you can better given this thread is already 24 pages in size.
Even on the GitHub: jpluimers/fritzcap: Fork of elpatron68/fritzcap which was previously automatically exported from code.google.com/p/fritzcap repository, many people had trouble:
1. finding fritzcap/fritzcap-interfaces-table.md
2. interpreting the information in fritzcap/fritzcap-interfaces-table.md
It means that documentation-wise, that needs to be better so it is easier for people to get started. That will help forum members too.
In addition documentation about configuring encoding in the Fritz!Box correctly (only unencrypted G.711 is supported by fritzcap, and even sometimes that goes wrong) and explaining the why is important. Note that encryption won't be supported as that is impossible without the private key of the VoIP server (even with that, it is kind of hard todo, just search for people that have done it in Wireshark). Other encodings might be possible given the cap2wav shell script floating around this thread.
Both from a code and documentation perspective, it is important to get the GitHub - jpluimers/fritzcap: Issues list synced with this thread.
As I don't have enough energy to get through all the 24 pages, I need help with that.
It would be cool if a few of the regulars in this thread would be so kind to split the pages among them and verify on each page if things asked there are covered in the issues and/or documentation and if not: add a new issue (or update an existing issue) linking to the messages here.
I know the syntax on this forum is vastly different from Markdown used on GitHub, but the issues do not need to be perfectly adhere to the GitHub flavoured Markdown: basic writing and formatting syntax, just plain text is OK (note the The Ultimate Guide to Markdown is easier to get started with Markdown than the GitHub documentation: feels a bit like the AVM documentation where blog posts and forums often are easier to get started with).
For me, I am fine with issues starting with a short broken English introduction section, then continuing the details in German both in rudimentary text. Maybe some volunteers then can help translating those parts in more proper English or Markdown.
Code wise, I am thinking about for instance:
- getting changed postulated in the forum into the fritzcap codebase (for instance there seems to be a fix around for making the capture directories and filenames more descriptive).
- command-line switch to go from internal G.711 support to cap2wav
- compressing to mp3, flac, ogg, aac or other lossy or lossless audio formats
- running fritzcap as a Windows or Linux service
- making fritzcap more robust (autostart features upon failure - needs good failure detection! - or restart after a certain time of inactivity with the chance of missing a call)
I am mainly interested to keep things centered around the GitHub repository as the organisation there is much more suited to link code/documentation/issues than the forum is.
As an intermediate I could start a complete new thread that is only used as liaison between this forum and the GitHub repository.
Please let me know your inputs on that.
A blog post on https://wiert.me asking for maintainers will follow in a few weeks time.
Regards,
--jeroen
Deutsch:
Hallo Jeroen,
zum Einen danke ich dir für die lobenden Worte, des weiteren wünsche ich dir gute Besserung und alles Glück welches man bei einer solchen Erkrankung brauchen kann. Mein Englisch ist leider nicht mehr das Beste, seit ich seit 30 Jahren nicht mehr im Ausland war.
Nun zu deiner Anfrage:
Gerne bin ich bereit, am Projekt mit-/weiter zu arbeiten. Leider bin ich allerdings noch beruflich wie auch privat sehr eingebunden, so dass ich mich derzeit nicht 100% dem Projekt widmen kann.
Vielleicht sollten wir hier einen neuen Thread öffnen, als Projektgruppe "Entwicklung Fritzcap". Hier schiele ich einfach mal die Moderatoren an, vielleicht haben sie ja eine Idee wie man dies umsetzen kann. Hier macht es dann Sinn, zusammenzuarbeiten um keine doppelte Arbeit zu erledigen.
Weiterhin den Quelltext im GitHub-Repository zu halten, halte ich auch für wichtig. Leider ist es nicht jedermanns Sache, sich Informationen aus dem Repository zu beschaffen, selbst ich als Programmierer tue mich manchmal schwer.
Wie dem auch sei, ich würde an dem Projekt gerne mitarbeiten - nur bitte nicht unter Zeitdruck. Wo ich helfen und etwas verbessern kann bin ich gerne mit dabei.
Hier im Forum gibt es weitere Spezialisten, vielleicht finden wir uns ja irgendwie konkret zusammen.
Viele Grüße aus dem stürmischen Allgäu
Chris
Englisch:
Hello Jeroen,
Firstly, thank you for the words of praise, and secondly, I wish you a speedy recovery and all the luck one could need with such an illness. Unfortunately, my English is no longer the best since I haven't been abroad for 30 years.
Now to your request:
I would be happy to work on the project. Unfortunately, I am still very busy at work and in my private life, so I cannot devote 100% of my time to the project at the moment.
Maybe we should open a new thread here, as a project group "Development Fritzcap". I'll just ask the moderators if they have any ideas on how to implement this. Here it makes sense to work together to avoid duplication of work.
I also think it's important to keep the source code in the GitHub repository. Unfortunately, it's not everyone's cup of tea to get information from the repository, even I as a programmer sometimes find it difficult.
Anyway, I would like to work on the project - but please not under time pressure. Where I can help and improve something, I'm happy to participate.
There are other specialists here in the forum, so maybe we'll get together somehow.
Many greetings from stormy Allgäu
Chris
Hallo Jeroen,
zum Einen danke ich dir für die lobenden Worte, des weiteren wünsche ich dir gute Besserung und alles Glück welches man bei einer solchen Erkrankung brauchen kann. Mein Englisch ist leider nicht mehr das Beste, seit ich seit 30 Jahren nicht mehr im Ausland war.
Nun zu deiner Anfrage:
Gerne bin ich bereit, am Projekt mit-/weiter zu arbeiten. Leider bin ich allerdings noch beruflich wie auch privat sehr eingebunden, so dass ich mich derzeit nicht 100% dem Projekt widmen kann.
Vielleicht sollten wir hier einen neuen Thread öffnen, als Projektgruppe "Entwicklung Fritzcap". Hier schiele ich einfach mal die Moderatoren an, vielleicht haben sie ja eine Idee wie man dies umsetzen kann. Hier macht es dann Sinn, zusammenzuarbeiten um keine doppelte Arbeit zu erledigen.
Weiterhin den Quelltext im GitHub-Repository zu halten, halte ich auch für wichtig. Leider ist es nicht jedermanns Sache, sich Informationen aus dem Repository zu beschaffen, selbst ich als Programmierer tue mich manchmal schwer.
Wie dem auch sei, ich würde an dem Projekt gerne mitarbeiten - nur bitte nicht unter Zeitdruck. Wo ich helfen und etwas verbessern kann bin ich gerne mit dabei.
Hier im Forum gibt es weitere Spezialisten, vielleicht finden wir uns ja irgendwie konkret zusammen.
Viele Grüße aus dem stürmischen Allgäu
Chris
Englisch:
Hello Jeroen,
Firstly, thank you for the words of praise, and secondly, I wish you a speedy recovery and all the luck one could need with such an illness. Unfortunately, my English is no longer the best since I haven't been abroad for 30 years.
Now to your request:
I would be happy to work on the project. Unfortunately, I am still very busy at work and in my private life, so I cannot devote 100% of my time to the project at the moment.
Maybe we should open a new thread here, as a project group "Development Fritzcap". I'll just ask the moderators if they have any ideas on how to implement this. Here it makes sense to work together to avoid duplication of work.
I also think it's important to keep the source code in the GitHub repository. Unfortunately, it's not everyone's cup of tea to get information from the repository, even I as a programmer sometimes find it difficult.
Anyway, I would like to work on the project - but please not under time pressure. Where I can help and improve something, I'm happy to participate.
There are other specialists here in the forum, so maybe we'll get together somehow.
Many greetings from stormy Allgäu
Chris
skyynet
Neuer User
- Mitglied seit
- 28 Jan 2008
- Beiträge
- 74
- Punkte für Reaktionen
- 3
- Punkte
- 8
Thanks @jeroenp for your work so far. It's a good idea to lay your baby into safe hands while you can do it. Of course, I wish you the very best for your health, but to be realistic, cancer is an asshole and chances are, you might make it, but also there's a chance, you won't.
I'm also quite occupied with family and my own stuff. Thus, I would offer to translate English docs into German if there's a maintainer for the docs to cooperate with.
I won't be able to check every aspect in the English docs for validity.
I'm also quite occupied with family and my own stuff. Thus, I would offer to translate English docs into German if there's a maintainer for the docs to cooperate with.
I won't be able to check every aspect in the English docs for validity.
Hallo zusammen,
ich habe folgendes Problem:
Auf PC 1 Python 2.7.14 und die aktuelle Fritcap installiert. Läuft nach einigen Anlaufschwierigkeiten inzwischen einwandfrei.
Das gleiche auf PC 2 gemacht und bekomme im CMD die Meldung
C:\Users\Shakkar\fritzcap>fritzcap.py --capture_files --decode_files --monitor_calls --box_name 192.168.xx.xxx -u xxxxxxxxxxxxxx --password xxxxxxxxxxxxx
2022-09-16 18:53:23,190 - FritzCap version 2.3.1 started.
2022-09-16 18:53:23,190 - Nothing to do. Exiting.
2022-09-16 18:53:23,190 - FritzCap version 2.3.1 finished.
Bei PC 1 läuft wie gesagt alles ziemlich tadellos. Jedoch habe ich einige Aussetzer bei den WAV Dateien. Ich vermute einen zu schwachen Prozessor. Es ist ein etwas älterer Intel NUC.
Deshalb wollte ich auf meinem i7 testen, ob es mit der Systemauslastung zusammenhängt.
Irgendwelche Ideen, woran es liegen kann?
ich habe folgendes Problem:
Auf PC 1 Python 2.7.14 und die aktuelle Fritcap installiert. Läuft nach einigen Anlaufschwierigkeiten inzwischen einwandfrei.
Das gleiche auf PC 2 gemacht und bekomme im CMD die Meldung
C:\Users\Shakkar\fritzcap>fritzcap.py --capture_files --decode_files --monitor_calls --box_name 192.168.xx.xxx -u xxxxxxxxxxxxxx --password xxxxxxxxxxxxx
2022-09-16 18:53:23,190 - FritzCap version 2.3.1 started.
2022-09-16 18:53:23,190 - Nothing to do. Exiting.
2022-09-16 18:53:23,190 - FritzCap version 2.3.1 finished.
Bei PC 1 läuft wie gesagt alles ziemlich tadellos. Jedoch habe ich einige Aussetzer bei den WAV Dateien. Ich vermute einen zu schwachen Prozessor. Es ist ein etwas älterer Intel NUC.
Deshalb wollte ich auf meinem i7 testen, ob es mit der Systemauslastung zusammenhängt.
Irgendwelche Ideen, woran es liegen kann?
Bist Du sicher, dass Deine Kommandos vollständig sind? Bei mir steht noch ein --cap_interface drin. Jedenfalls scheint es mit der Auswertung der Kommandozeile zu tun zu haben.
Das Debug file sollte Auskunft geben. Man kann das Interface ja auch in der fritzcap.conf angeben. Dort gebe ich eigenlich alle Parameter an, ausser die Worker, die gebe ich in der Kommandozeile ein, also -c -d -m.
@Offf-Topic: Hoffe Joeren geht es besser, Gesundheit geht schliesslich vor.
@Alle: Ich glaube bei den neueren FritzOS ist der Capfile-Aufruf in der Firmware anders. Ich weiß nicht mehr ab welcher Version das kam, könnte die 7.29 gewesen sein. Deswegen gibts dann bei manchen 0kB Capfiles.
@Offf-Topic: Hoffe Joeren geht es besser, Gesundheit geht schliesslich vor.
@Alle: Ich glaube bei den neueren FritzOS ist der Capfile-Aufruf in der Firmware anders. Ich weiß nicht mehr ab welcher Version das kam, könnte die 7.29 gewesen sein. Deswegen gibts dann bei manchen 0kB Capfiles.
Falls ihr mal viel Traffic auf der Box habt und die CaptureDateien bei langen Gesprächen zu groß werden. Fügt in der capture_monitor.py in der url_start Variable folgendes hinzu
+ '&snaplen=300'
bzw. was ihr da so braucht.
Damit werden zwar die Pakete mit der richtigen Länge aufgezeichnet, aber der Inhalt wird nach 300 abgeschnitten.
+ '&snaplen=300'
bzw. was ihr da so braucht.
Damit werden zwar die Pakete mit der richtigen Länge aufgezeichnet, aber der Inhalt wird nach 300 abgeschnitten.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,149
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Mit 07.50 führt AVM beim Capture einen Aufzeichnungsfilter ein (https://www.ip-phone-forum.de/threa...serie-07-39-–-sammelthema.312181/post-2492906), über den man dann die gesammelten Pakete auch auf die RTP-Verbindungen beschränken kann (notfalls mit einer Port-Range, die alle in Frage kommenden Ports umfaßt).
Das muß man dann halt nur korrekt in den Start der Aufzeichnung (https://github.com/jpluimers/fritzc...fcec9a05d683f4fe/core/capture_monitor.py#L247) einbauen und dann sollte es auch keine Probleme mit dem Umfang eines solchen Mitschnitts geben.
Das sollte eigentlich die bessere Alternative zur Begrenzung des Umfangs einer Aufzeichnung sein. Aber wie geschrieben ... erst ab 07.39 bzw. 07.50, wie die Release-Version ja heißen soll.
Das muß man dann halt nur korrekt in den Start der Aufzeichnung (https://github.com/jpluimers/fritzc...fcec9a05d683f4fe/core/capture_monitor.py#L247) einbauen und dann sollte es auch keine Probleme mit dem Umfang eines solchen Mitschnitts geben.
Das sollte eigentlich die bessere Alternative zur Begrenzung des Umfangs einer Aufzeichnung sein. Aber wie geschrieben ... erst ab 07.39 bzw. 07.50, wie die Release-Version ja heißen soll.
Danke für die Infos. Ja nach so etwas habe ich gesucht.
Ich weiß auch nicht, ob jemand jetzt an dem fritzcapscript weiterarbeitet oder wer es in welchem Land verwendet. Habe mich da ein wenig eingelesen, gibt hier und da wo man noch einiges machen könnte, auch bezüglich G722 Aufzeichnung.
Ich weiß auch nicht, ob jemand jetzt an dem fritzcapscript weiterarbeitet oder wer es in welchem Land verwendet. Habe mich da ein wenig eingelesen, gibt hier und da wo man noch einiges machen könnte, auch bezüglich G722 Aufzeichnung.
Zuletzt bearbeitet:
Hallo, gleiches Ergebnis wie Erik72.
Seit dem update auf 7.5 Seems, there is no valid PCAP file
Seit dem update auf 7.5 Seems, there is no valid PCAP file
Welche Version hattet ihr denn vorher mit der es funktionierte? Ich meine man muss am Startstring etwas ändern. Leider habe ich keine Fritzbox mit 7.50 zum Testen
Ich weiß nicht ob das hilft, aber versuche mal das zu dem startstring hinzuzufügen:
+ "&capture=Start"
github.com
also so sollte es aussehen
url_start = self.base_url + '/cgi-bin/capture_notimeout' + self.start_str + "&ifaceorminor=" + self.cap_interface + "&capture=Start"
und beim Stoppen dann, noch den stop hinzufügen
github.com
+ "&capture=Stop"
Wenn das nicht hilf, muss ich warten, bis ich auf meiner 6591 die 7.50 bekomme, die ist aber vom Provider das kann ewig dauern.
Evtl. kan Peter die richtigen String rausfinden. Das mit der Captureaufzeichnung auf nur bestimmte ports bzw. Längen wäre dann Zukunftsmusik.
+ "&capture=Start"
fritzcap/core/capture_monitor.py at 6203498daf42ecd87cc8e542fcec9a05d683f4fe · jpluimers/fritzcap
Fork of elpatron68/fritzcap which was previously automatically exported from code.google.com/p/fritzcap - jpluimers/fritzcap
github.com
also so sollte es aussehen
url_start = self.base_url + '/cgi-bin/capture_notimeout' + self.start_str + "&ifaceorminor=" + self.cap_interface + "&capture=Start"
und beim Stoppen dann, noch den stop hinzufügen
fritzcap/core/capture_monitor.py at 6203498daf42ecd87cc8e542fcec9a05d683f4fe · jpluimers/fritzcap
Fork of elpatron68/fritzcap which was previously automatically exported from code.google.com/p/fritzcap - jpluimers/fritzcap
github.com
Wenn das nicht hilf, muss ich warten, bis ich auf meiner 6591 die 7.50 bekomme, die ist aber vom Provider das kann ewig dauern.
Evtl. kan Peter die richtigen String rausfinden. Das mit der Captureaufzeichnung auf nur bestimmte ports bzw. Längen wäre dann Zukunftsmusik.
Hi, bei mir hat es leider nichts gebracht.
Immer noch Seems, there is no valid PCAP file
Die Datei wird erzeugt. Leider ohne größe. 0KB
Immer noch Seems, there is no valid PCAP file
Die Datei wird erzeugt. Leider ohne größe. 0KB
ok, das ist natürlich Mist und danke für die Rückmeldung.
Irgendjemand der die 7.50 hat müsste dann die Startstrings rausfinden in der capture_timeout.
PeterPawn ist da topfit in diesen Sachen.
Da ja die 7.50 auf den inhouse 7.39 aufbaut, müsste es doch da auch schon Probleme gegeben habe?
Ich hab bei mir die 7.29 und da funktioniert es noch. Ich muss mal schauen ob ich da etwas rausfinden kann.
Irgendjemand der die 7.50 hat müsste dann die Startstrings rausfinden in der capture_timeout.
PeterPawn ist da topfit in diesen Sachen.
Da ja die 7.50 auf den inhouse 7.39 aufbaut, müsste es doch da auch schon Probleme gegeben habe?
Ich hab bei mir die 7.29 und da funktioniert es noch. Ich muss mal schauen ob ich da etwas rausfinden kann.
Neueste Beiträge
-
Selbständige Portfreigabe lässt sich nicht deaktivieren- Letzte: NDiIPP
-
Prime Сasual Dating - Real Women
- Letzte: dtuda
-
Deutsche Glasfaser - Telefonnr. nicht registrierbar
- Letzte: HerzogIgzorn
-
[Problem] GELÖST - Weiterleitung funktioniert nur bei einer anderen Handynummer?- Letzte: Rangierdraht
-
[Problem] Freevoipdeal und Anruf bei Drillisch-Sim- Letzte: Jstessi
-
Festlegen bei welchen Repeater sich ein Gerät anmelden darf
- Letzte: zorro0369
-
4G-Empfang statt 2G/Edge
- Letzte: neuber18