Wer sich dann noch etwas intensiver mit "DNS-SRV" und dem "STUN-Mist" beschäftigen möchte, findet hier und hier etwas Lesestoff für lange Winterabende. Wer weniger Zeit hat und sich nur für STUN interessiert, sollte sich dieses Kapitel des zweiten Links auf keinen Fall entgehen lassen.
HOW-TO: VoIP/SIP-Konfiguration von NOKIA-Handys mit VoIP-Client, an FRITZBox anmelden
- Ersteller imagomundi
- Erstellt am
jochen
Mitglied
- Mitglied seit
- 9 Jul 2004
- Beiträge
- 249
- Punkte für Reaktionen
- 0
- Punkte
- 0
Warum STUN nicht funktioniert
Warum STUN nicht funktioniert
Abhängig vom NAT-Typ kann STUN funktionieren oder auch versagen. An einem Beispiel von Linux Masquerading will ich zeigen warum STUN bei SIP nicht funktioniert.
Da wir nur eine öffentliche IP haben kann der Router bei ankommenden UDP-Paketen nur anhand des Ports entscheiden zu welchem Gerät er die weiterleiten muss. Der Port muss also eindeutig sein. Der Router führt dazu interne Tabellen in denen er jede Portverwendung mit dem dazugehörigen Endgerät festhält. Anhand dieser Tabelle kann er dann ankommende Pakete dem richtigen Gerät zuordnen.
Bei einem SIP-Telefonat werden die Sprachdaten per UDP direkt zwischen den beiden Teilnehmern ausgetauscht. Der SIP-Server übernimmt lediglich die Vermittlung und teilt den beiden Endgeräten die nötigen Daten mit, damit sie miteinander kommunizieren können (über RTP).
Nehmen wir an Telefon A will die RTP-Daten auf Port 9000 empfangen. Um das dem Telefon B mitzuteilen wird es zunächst über STUN ermitteln wie seine öffentliche IP und der öffentliche Port ist (der muss nicht 9000 sein, der kann vom NAT geändert werden). Nehmen wir weiter an der Port 9000 sei momentan nicht in Verwendung. Der STUN-Client wird jetzt also unter Verwendung des Port 9000 (der soll ja nachher für RTP genutzt werden) den STUN-Server befragen wie die öffentliche IP und der öffentliche Port sind. Da Port 9000 momentan frei ist wird 9000 auch der öffentliche Port sein. Die öffentliche IP sei in diesem Beispiel 1.2.3.4.
Das Telefon A teilt nun über den SIP-Server dem Telefon B mit, dass es die RTP Daten an die IP 1.2.3.4 und Port 9000 schicken soll.
Ebenso teilt Telefon B dem Telefon A mit wo es seine Daten hinsenden soll.
Beide Telefone beginnen nun per RTP die Sprachdaten zu senden.
Telefon A sendet mit dem Absenderport 9000 die Daten an Telefon B. Der Router stellt nun fest dass Port 9000 bereits in Verwendung ist (durch die STUN-Abfrage) und ändert den Port jetzt um, z.B. auf 9001. Telefon B müsste die Daten jetzt eigentlich an Port 9001 senden, aber davon weiss es nichts. Es wird die Daten wie befohlen an Port 9000 senden. Dieser ist zwar durch die STUN-Abfrage immer noch dem Telefon A zugeordnet, da aber die Daten diesmal von einer anderen IP kommen, werden die Pakete am Router verworfen. Ergebnis: wir hören unser Gegenüber nicht.
Dieses Szenario funktioniert nur wenn STUN-Server und Telefon B (bzw. PSTN-Gateway) die gleiche IP haben. Das würde klappen wenn STUN-Server und PSTN-Gateway des Providers auf dem gleichen Rechner (gleiche IP) laufen. Gespräche ins Festnetz wären dann möglich, aber direkte Gespräche zwischen 2 SIP-Telefonen funktionieren nicht.
STUN ist kein Allheilmittel für SIP-Telefonie. Das einzige was zuverlässig funktioniert: festes Portforwarding der RTP-Ports am Router, oder dynamisches Forwarding über uPnP.
Warum STUN nicht funktioniert
Abhängig vom NAT-Typ kann STUN funktionieren oder auch versagen. An einem Beispiel von Linux Masquerading will ich zeigen warum STUN bei SIP nicht funktioniert.
Da wir nur eine öffentliche IP haben kann der Router bei ankommenden UDP-Paketen nur anhand des Ports entscheiden zu welchem Gerät er die weiterleiten muss. Der Port muss also eindeutig sein. Der Router führt dazu interne Tabellen in denen er jede Portverwendung mit dem dazugehörigen Endgerät festhält. Anhand dieser Tabelle kann er dann ankommende Pakete dem richtigen Gerät zuordnen.
Bei einem SIP-Telefonat werden die Sprachdaten per UDP direkt zwischen den beiden Teilnehmern ausgetauscht. Der SIP-Server übernimmt lediglich die Vermittlung und teilt den beiden Endgeräten die nötigen Daten mit, damit sie miteinander kommunizieren können (über RTP).
Nehmen wir an Telefon A will die RTP-Daten auf Port 9000 empfangen. Um das dem Telefon B mitzuteilen wird es zunächst über STUN ermitteln wie seine öffentliche IP und der öffentliche Port ist (der muss nicht 9000 sein, der kann vom NAT geändert werden). Nehmen wir weiter an der Port 9000 sei momentan nicht in Verwendung. Der STUN-Client wird jetzt also unter Verwendung des Port 9000 (der soll ja nachher für RTP genutzt werden) den STUN-Server befragen wie die öffentliche IP und der öffentliche Port sind. Da Port 9000 momentan frei ist wird 9000 auch der öffentliche Port sein. Die öffentliche IP sei in diesem Beispiel 1.2.3.4.
Das Telefon A teilt nun über den SIP-Server dem Telefon B mit, dass es die RTP Daten an die IP 1.2.3.4 und Port 9000 schicken soll.
Ebenso teilt Telefon B dem Telefon A mit wo es seine Daten hinsenden soll.
Beide Telefone beginnen nun per RTP die Sprachdaten zu senden.
Telefon A sendet mit dem Absenderport 9000 die Daten an Telefon B. Der Router stellt nun fest dass Port 9000 bereits in Verwendung ist (durch die STUN-Abfrage) und ändert den Port jetzt um, z.B. auf 9001. Telefon B müsste die Daten jetzt eigentlich an Port 9001 senden, aber davon weiss es nichts. Es wird die Daten wie befohlen an Port 9000 senden. Dieser ist zwar durch die STUN-Abfrage immer noch dem Telefon A zugeordnet, da aber die Daten diesmal von einer anderen IP kommen, werden die Pakete am Router verworfen. Ergebnis: wir hören unser Gegenüber nicht.
Dieses Szenario funktioniert nur wenn STUN-Server und Telefon B (bzw. PSTN-Gateway) die gleiche IP haben. Das würde klappen wenn STUN-Server und PSTN-Gateway des Providers auf dem gleichen Rechner (gleiche IP) laufen. Gespräche ins Festnetz wären dann möglich, aber direkte Gespräche zwischen 2 SIP-Telefonen funktionieren nicht.
STUN ist kein Allheilmittel für SIP-Telefonie. Das einzige was zuverlässig funktioniert: festes Portforwarding der RTP-Ports am Router, oder dynamisches Forwarding über uPnP.
Klingt ja höchst beeindruckend und logisch - deshalb würde ich mich dem AMEN von Joel ohne nähere Überlegung anschliessen. Allerdings sagt mir die nähere Überlegung: Wieso funktioniert es dann im REGELFALL trotzdem mit STUN und ohne funktioniert es ebenso im Regelfall nicht?
Muß es nicht deshalb Gründe geben für ein Funktionieren, die nicht nur von der Art der NAT (des einen oder auch des anderen Teilnehmers) abhängig sind = kommen nicht -in der Praxis- andere Lösungen zum Tragen, die nicht "festes Portforwarding" oder dynamisches über "uPnP" voraussetzen (das wird ja eben gerade NICHT die Regel sein) ohne gleich Deine ganze logisch klingende Theorie hinterfragen zu müssen? Oder muß man das doch tun - z.B. die Annahme, daß der Port, über den die STUN-Anfrage erfolgt, besetzt bleibt?
Ich bin einerseits nicht genug Experte, um Deine Theorie mit fundierter Begründung in Frage stellen zu können, aber andererseits seit Jahren genug VoIP/SIP-Praktiker, um sie nicht unbesehen stehen zu lassen.
So, mit dem 1und1 gebe ich es auf.
Ich hatte mein Handy noch einmal neu aufsetzen müssen. Dabei habe ich dann als erstes das SIP konfiguriert und auch da ist es immer noch so gewesen, dass ich, wenn ich anrufe, bei manchen Telefonnummer nichts höre.
Ich hatte mein Handy noch einmal neu aufsetzen müssen. Dabei habe ich dann als erstes das SIP konfiguriert und auch da ist es immer noch so gewesen, dass ich, wenn ich anrufe, bei manchen Telefonnummer nichts höre.
jochen
Mitglied
- Mitglied seit
- 9 Jul 2004
- Beiträge
- 249
- Punkte für Reaktionen
- 0
- Punkte
- 0
@imagomundi:
Für ein "funktionieren" von STUN (falls man das überhaupt so bezeichnen kann) spielen eine Menge Faktoren mit:
1. (der wichtigste) welchen Typ von NAT verwendet der eingesetzte Router? Billige Router haben meist nur das unsichere Full cone NAT oder Adress-restricted cone NAT. Da funktioniert STUN. Beim symmetric NAT oder Masquerading NAT versagt es.
Eine Übersicht der NAT Typen findet man z.B. hier: http://www.jenkinssoftware.com/raknet/manual/nattypedetection.html
http://web.archive.org/web/20061029001038/www.suse.de/~mha/linux-ip-nat/diplom/node4.html
2. wo geht der Ruf hin? Die SIP-Provider setzen auf ihren PSTN-Gateways meist SBC oder andere Unterstüzung ein, die ein NAT beim Client erkennen und Gegenmassnahmen treffen können. Nicht umsonst rät Sipgate von der Verwendung von STUN ab. Grund: dann sendet der Client eine lokale IP die der SBC erkennt und ignoriert, stattdessen entnimmt er die IP einfach aus der Absenderadresse. Der RTP-Port kann dabei auch nicht vom STUN blockiert sein, sodaß das erste ausgehende UDP-Paket den gewünschten Port auf dem Router öffnet.
3. Wird ein Router mit integriertem ATA eingesetzt (z.B. Fritzbox)? Dann gibt es keine NAT Probleme, weil der ATA auf der WAN-Seite sitzt und mit der öffentlichen IP arbeiten kann.
4. Wann wird die STUN-Abfrage vom Client durchgeführt? Periodisch (z.B. einmal pro Stunde) oder direkt vor dem Call? Vergeht zwischen STUN-Abfrage und Call eine Zeit die länger ist als das UDP Timeout (oft 3 Minuten) dann ist der Port auf dem Router wieder frei und es klappt wie gewünscht. Das hat dann den Anschein als würde STUN helfen. Bei stündlichem STUN und 3 Minuten Timeout funktioniert es aber nur 57 Minuten in einer Stunde. Die restlichen 3 Minuten kommt es zu One-way-Audio. Man freut sich das auf den ersten Blick alles klappt, und wundert sich über gelegentliches One-way-Audio, welches man dann auf eine Fehlfunktion beim Provider schiebt. Je kürzer man das STUN-Intervall macht, umso häufiger kommt es zum Problem.
5. Für Linux gibt es diverse NAT-Helper-Module für Protokolle die eine zweite Verbindung benötigen (z.B. FTP). Hat der Router evtl. ein NAT-Helper-Modul für SIP drin?
Die SIP-Provider setzen auf ihren Gateways meist irgendeine Form von NAT-Unterstüzung ein, sodaß man hier nicht sagen kann ob das STUN wie gedacht funktioniert. Ob STUN funktioniert (oder auch nicht) sieht man am schnellsten bei direkten SIP-Calls ohne Provider-Beteilung (z.B. durch direkten Anruf einer Dyndns SIP-URI ohne Verwendung eines SIP-Proxy. Einfach einer Fritzbox eine Dyndns Adresse geben und versuchen die mit einem guten IP-Telefon welches keinen Proxy benötigt (z.B. Snom) anzurufen. Ich beschäftige mich schon seit 10 Jahren mit VoIP und habe die NAT-Probleme ausgiebig untersucht. Dabei bin ich zu dem Schluss gekommen dass STUN nichts taugt. Es gibt einen STUN Client in Python (hab die Adresse grad nicht parat, einfach mal danach googeln), mit dem lässt sich das sehr schön nachvollziehen.
Eine sehr gute Beschreibung (englisch) über die NAT-problematik findet man in diesem Dokument:
NAT Traversal in SIP
Für die Eiligen: Kapitel 4.3
The solution shown in Figure 5 (NAT probe or STUN server) will only work
for the first 3 types of NAT. The 4th case – symmetric NATs – will not allow
this scheme since they have different mappings depending on the target IP. So
the mapping that the NAT assigns between the client and the NAT probe is
different than that assigned between the client and the gateway.
Für ein "funktionieren" von STUN (falls man das überhaupt so bezeichnen kann) spielen eine Menge Faktoren mit:
1. (der wichtigste) welchen Typ von NAT verwendet der eingesetzte Router? Billige Router haben meist nur das unsichere Full cone NAT oder Adress-restricted cone NAT. Da funktioniert STUN. Beim symmetric NAT oder Masquerading NAT versagt es.
Eine Übersicht der NAT Typen findet man z.B. hier: http://www.jenkinssoftware.com/raknet/manual/nattypedetection.html
http://web.archive.org/web/20061029001038/www.suse.de/~mha/linux-ip-nat/diplom/node4.html
2. wo geht der Ruf hin? Die SIP-Provider setzen auf ihren PSTN-Gateways meist SBC oder andere Unterstüzung ein, die ein NAT beim Client erkennen und Gegenmassnahmen treffen können. Nicht umsonst rät Sipgate von der Verwendung von STUN ab. Grund: dann sendet der Client eine lokale IP die der SBC erkennt und ignoriert, stattdessen entnimmt er die IP einfach aus der Absenderadresse. Der RTP-Port kann dabei auch nicht vom STUN blockiert sein, sodaß das erste ausgehende UDP-Paket den gewünschten Port auf dem Router öffnet.
3. Wird ein Router mit integriertem ATA eingesetzt (z.B. Fritzbox)? Dann gibt es keine NAT Probleme, weil der ATA auf der WAN-Seite sitzt und mit der öffentlichen IP arbeiten kann.
4. Wann wird die STUN-Abfrage vom Client durchgeführt? Periodisch (z.B. einmal pro Stunde) oder direkt vor dem Call? Vergeht zwischen STUN-Abfrage und Call eine Zeit die länger ist als das UDP Timeout (oft 3 Minuten) dann ist der Port auf dem Router wieder frei und es klappt wie gewünscht. Das hat dann den Anschein als würde STUN helfen. Bei stündlichem STUN und 3 Minuten Timeout funktioniert es aber nur 57 Minuten in einer Stunde. Die restlichen 3 Minuten kommt es zu One-way-Audio. Man freut sich das auf den ersten Blick alles klappt, und wundert sich über gelegentliches One-way-Audio, welches man dann auf eine Fehlfunktion beim Provider schiebt. Je kürzer man das STUN-Intervall macht, umso häufiger kommt es zum Problem.
5. Für Linux gibt es diverse NAT-Helper-Module für Protokolle die eine zweite Verbindung benötigen (z.B. FTP). Hat der Router evtl. ein NAT-Helper-Modul für SIP drin?
Die SIP-Provider setzen auf ihren Gateways meist irgendeine Form von NAT-Unterstüzung ein, sodaß man hier nicht sagen kann ob das STUN wie gedacht funktioniert. Ob STUN funktioniert (oder auch nicht) sieht man am schnellsten bei direkten SIP-Calls ohne Provider-Beteilung (z.B. durch direkten Anruf einer Dyndns SIP-URI ohne Verwendung eines SIP-Proxy. Einfach einer Fritzbox eine Dyndns Adresse geben und versuchen die mit einem guten IP-Telefon welches keinen Proxy benötigt (z.B. Snom) anzurufen. Ich beschäftige mich schon seit 10 Jahren mit VoIP und habe die NAT-Probleme ausgiebig untersucht. Dabei bin ich zu dem Schluss gekommen dass STUN nichts taugt. Es gibt einen STUN Client in Python (hab die Adresse grad nicht parat, einfach mal danach googeln), mit dem lässt sich das sehr schön nachvollziehen.
Eine sehr gute Beschreibung (englisch) über die NAT-problematik findet man in diesem Dokument:
NAT Traversal in SIP
Für die Eiligen: Kapitel 4.3
The solution shown in Figure 5 (NAT probe or STUN server) will only work
for the first 3 types of NAT. The 4th case – symmetric NATs – will not allow
this scheme since they have different mappings depending on the target IP. So
the mapping that the NAT assigns between the client and the NAT probe is
different than that assigned between the client and the gateway.
Zuletzt bearbeitet:
Fritz!Box als sip-server
Servus,
abweichend von der Problemmatik N79 + 1und1 direkt habe ich auch ein Problem mit der Fritz!Box als sip-server.
Wenn ich sie entsprechend nutze, so wird das Gespräch im Zuge des Telefonierens immer abgehakter bis man schließlich garnichts mehr versteht.
Hatte jemand schon einmal ähnliche Problem?
MfG
Matthias
Servus,
abweichend von der Problemmatik N79 + 1und1 direkt habe ich auch ein Problem mit der Fritz!Box als sip-server.
Wenn ich sie entsprechend nutze, so wird das Gespräch im Zuge des Telefonierens immer abgehakter bis man schließlich garnichts mehr versteht.
Hatte jemand schon einmal ähnliche Problem?
MfG
Matthias
fye
Aktives Mitglied
- Mitglied seit
- 1 Sep 2009
- Beiträge
- 1,486
- Punkte für Reaktionen
- 0
- Punkte
- 0
@ mattberlin
So krass war es bei mir nicht, aber auch nicht optimal für mein Gegenüber.
Nachdem ich in den FritzBox Internettelefonie Einstellungen immer Sprachkodierung mit Festnetzqualität verwenden gewählt hatte, war es o.k.
So krass war es bei mir nicht, aber auch nicht optimal für mein Gegenüber.
Nachdem ich in den FritzBox Internettelefonie Einstellungen immer Sprachkodierung mit Festnetzqualität verwenden gewählt hatte, war es o.k.
In der Tat hochinteressantes Dokument. Wenngleich ich nicht alles in allen Einzelheiten blicke, sehe ich dort:
1. der STUN-Mist scheint sooo groß als Mist nicht zu sein
2. uPnP ist mindestens gleich grosser Mist - angereichert noch um zusätzliche Sicherheitsrisiken
3. ein brauchbarer Inhalt der SDP-message innerhalb von SIP ist Grundvoraussetzung, zumindest vermeidbare Probleme auch tatsächlich zu vermeiden
4. es sind technische Lösungen (einfache Version: TURN bis ziemlich komplette Version: MEDIA-RELAY) nicht nur denkbar, sondern im IETF "in der Mache". Mit der Verbreitung der mobilen Internet-Telefonie wird die Notwendigkeit solch kompletter und komplexer Lösungen der NAT-Problematiken immer drängender werden.
ÜBRIGENS: Welche Elemente beinhaltet denn das Paket "nokia.stun"-Protokoll ??
Zuletzt bearbeitet:
jochen
Mitglied
- Mitglied seit
- 9 Jul 2004
- Beiträge
- 249
- Punkte für Reaktionen
- 0
- Punkte
- 0
In Anbetracht der Tatsache dass heute jeder bessere Router ein sicheres NAT vom Typ "symetric" oder ähnliches hat, behaupte ich das STUN in der heutigen Zeit völlig unbrauchbar ist.
Ich hatte noch keine Probleme mit uPnP, welcher Art sollen die sein?
Und das mit den "Sicherheitsrisiken": uPnP wird immer vorgeworfen, Trojaner könnten sich damit selbst die Ports öffnen. Das kann man aber doch nicht dem uPnP vorwerfen. Wenn ein Einbrecher durchs Fenster rein kommt kann er sich auch die Haustür von innen öffnen. In dem Fall sollte man eher die Fenster vergittern, nicht die Tür zumauern. Sowas würde man höchstens in Schilda machen.
Das würde mich auch mal interessieren. Und vor allem, was ist wenn man das leer lässt? Warum geht's dann trotz fester Portforwardings nicht? Und was ist an der Stelle noch möglich? Gibts auch "nokia.upnp"?
Ich habe verschiedene SIP-Profile mit verschiedenen Providern (s. Sig) auf meinem N86 am Laufen - alle problemlos und OHNE jemals bei einem das nokia.stun-Protokoll eingetragen zu haben. Portforwardings in der FB führen (Beiträge in diesem Forum und im TT) in aller Regel zu einem NICHT-Funktionieren dieser Dienste (Profile).
jochen
Mitglied
- Mitglied seit
- 9 Jul 2004
- Beiträge
- 249
- Punkte für Reaktionen
- 0
- Punkte
- 0
Ich befürchte auch dass das ein Bug im E72 ist. Laut Doku sollte nokia.stun ohnehin Default sein (wenn nichts eingetragen wird).
Fritzbox ist ein Spezialfall, weil die einen ATA integriert hat, der sitzt vor dem NAT (auf WAN-Seite) und man weiss nicht was der an den Firewallregeln "rumschraubt".
Das Verhalten der Fritzboxen würde ich jetzt nicht auf alle Router verallgemeinern.
Dann hat das N97 den selben Bug und Sipgate hat es in seiner SMS-Konfiguration nicht berücksichtigt: Ich habe in den letzten Tagen Telefon-Support geleistet für einen N97-Besitzer, der NUR mit Sipgate und EINGEHEND einseitig keinen Ton empfangen konnte. Direkt über URI klappte alles problemlos.
Nachdem "nokia.stun" im Sipgate-Profil eingetragen wurde, klappt es jetzt.
Daß "nokia-stun" default sein soll, mag richtig sein (oder auch nicht?)- Tatsache ist, daß es mit dem Installieren der VoIP/SIP-Settings von NOKIA nicht als default konfiguriert wird - zumindest mit den 3.x - ob das auch mit den S60 5 VoIP SIP 3.x (N97) so ist, weiß ich nicht.
Interessant wäre aber in der Tat, den Inhalt zu kennen (ist das Protokoll eine Art TURN im Sinne des von Dir verlinkten Dokuments zu NAT?).
jochen
Mitglied
- Mitglied seit
- 9 Jul 2004
- Beiträge
- 249
- Punkte für Reaktionen
- 0
- Punkte
- 0
Kein Ton heisst ja erstmal nur dass die UDP-Pakete nicht ankommen. Dass die IP nicht stimmt halte ich für unwahrscheinlich. Entweder steht da eine lokale IP drin, dann merkt das das Gateway, oder es steht die öffentliche drin, dann passt es sowieso.
Ich glaube eher dass es am Port liegt. Ist nur die Frage, welchen Port nimmt das Nokia im Falle mit "nokia.stun" und im Falle ohne? Irgendwo muss ja ein Unterschied sein.
Als RTP Start und End habe ich 9000-9020 eingetragen, und auch diesen kompletten Bereich am Router ans Nokia geforwardet. Trotzdem kommt ohne "nokia.stun" kein Ton an.
Warum? Es muss irgendeinen Grund geben, warum Sipgate die Daten nicht auf dem Port sendet auf dem das Nokia sie erwartet. Und der Grund muss irgendwo in dem Unterschied mit/ohne nokia.stun liegen.
Laut Sipgate-Support besteht das Problem angeblich nur dann, wenn man die "Advanced Voip Settings" von Nokia installiert hat.
jochen
Mitglied
- Mitglied seit
- 9 Jul 2004
- Beiträge
- 249
- Punkte für Reaktionen
- 0
- Punkte
- 0
Sehr aufschlussreich!
Da Du's offensichtlich wusstest, wäre es erfreulich gewesen, wenn Du uns allen das schon früher mitgeteilt hättest - aber immerhin wissen wir jetzt, daß die "Fritzdinger" für VoIP gar nicht so schlecht sind.
Schliesse mich der Frage meines Vor-Schreibers an: Und das wäre???
Halte ich für dummes Geschwafel auf Grund fehlender eigener Kenntnis der Sipgate-Support-Leute. Sipgate funktioniert auf meinem N86 mit der Version 3.x der NOKIA Advanced VoIP Settings problemlos. Und: womit, wenn nicht mit dem NOKIA-VoIP-Client = Advanced VoIP Settings soll man denn mit einem SIP-fähigen NOKIA-Handy SIP/VoIP-Telefonieren? Nur wenn Sipgate einen eigenen VoIP-Client oder ein Softphone für Handys zur Verfügung stellen würde, könnte ich diese Ausrede noch zähneknirschend akzeptieren.
Und auch hierzu die Frage: Und die wären?
Neueste Beiträge
-
FRITZ!Box 5590 - INHAUS - Smart24P1 - 7.90 - Sammelthema- Letzte: Master SaMMy
-
Selbständige Portfreigabe lässt sich nicht deaktivieren- Letzte: NDiIPP
-
FRITZ!Box 7590 - INHAUS - Smart24P1 - 7.90 - Sammelthema
- Letzte: gerstemann
-
Unsurpassed Сasual Dating - Actual Girls
- Letzte: dvdGonzo
-
AVM Geofencing - Smart Home: Fragen
- Letzte: sentry80
-
FRITZ!Box 5530 Fiber / FRITZ!OS 7.80 vom 30.01.2024
- Letzte: Erforderlich
-