VoIP mit WLAN Telefon (T-One) geht nicht

jo2080

Mitglied
Mitglied seit
7 Jan 2006
Beiträge
321
Punkte für Reaktionen
0
Punkte
0
Hallo,

habe ein Problem mit VoIP per WLAN Telefon mit dem Telekom T-One (TC300)

Habe GMX als VoIP Provider eingestellt.
Bei der Konfiguration ist Port 5060 eingestellt

Eingehende Gespräche funktionieren nicht( werden nicht weitergeleitet), und ausgehende werden nach 20 sekunden abgebrochen.

Vermute es liegt an der Konfiguration Fritz box T-One, da mit meiner T-Online
Nummer das Problem identisch ist.

Was ist falsch ? Habe gehört es kann mit den Ports zusammenhängen.

Konfiguration TC 300
Oberbegriff SIP EINSTELLUNGEN
Benutzername: 49807172XXXX
Passwort: (ist klar)
E-Mailadresse: leer lassen sonst geht nix mit GMX
Domänenname:sip.gmx.net
Lokaler Port: (vorgabe 5060)
Proxy Server: sip.gmx.net
Proxy Port: (vorgabe 5060)
Anmeldeserver: sip.gmx.net
Anmeldeport: (vorgabe 5060)
Intervall: (vorgabe 600)
Ausgangsserver:sip.gmx.net (leer lassen geht auch für Abgehende Gespräche)
Ausgangsport: (vorgabe 5060)
RTP-Port-Audio: (vorgabe 30000)
RTP-PKT-Intervall: (vorgabe 20)
Codec auswählen: (welcher ist stark komprimierend sollte so stark sein dass ich mit 128 upstream 2 Gespräche führen kann Auswahl G711U und G711A, G726-32 und 24 )

Dann Oberbegriff NAT-EINSTELLUNGEN
RPORT: (Auswahlmöglichkeit EIN AUS) egal ob ein oder aus bei abgehend
Stun: (Auswahlmöglichkeit EIN AUS) bei EIN geht GMX
Server Adresse: stun.gmx.net
Portnummer: ( Vorgabe 3478 )
Auffrischzyklus: ( Vorgabe 60 )
Welcher muss ein und welcher muss ausgeschaltet sein oder beide ein aus ?????

Die Fritz Box ist in Originalkonfiguration als ATA
 
Zuletzt bearbeitet:
hab mit 1und1 so ziemlich das gleiche problem:

Zwar klappen eingehende Anrufe per VoIP ohne Fehler,
aber abgehende Gespräche werden nach 30 sekunden getrennt.

Das TC300 ist in der FB7170 als "Exposed Host" eingetragen.


bei der 1&1 Nummer handelt es sich um eine reine VoIP-Nummer,
keine Freigeschaltete Festnetz-Nummer.

####################### SIP-Einstellungen
Benutzername: 49Vorwahl(ohne 0)Rufnummer
Passwort: (scheinbar gehen nur Ziffern, bei Buchstaben gab es immer Auth.-Fehler)
email-Adresse: (nix)
Domänenname: (nix)
Lokaler Port: 5061 (5060 belegt von Fritzbox)
Proxy-Server: (nix)
Proxy-Port: 5061
Anmeldeserver: sip.1und1.de
Anmeldeport: [[5061]] EDIT: 5060
Intervall: 60
Ausgangsserver: sip.1und1.de
Ausgangsport: [[5061]] EDIT: 5060
RTP-Port Audio: 30000
RTP-PKT-Intervall: 20
Codex: G.711A
####################### NAT-Einstellungen
RPORT: An
STUN: An
> Server-Adrese: stun.1und1.de
> Portnummer: 3478
> Auffrischzyklus: 60

Äbnderungen unter NAT, den Intervallen und Codecs haben das Problem nicht behoben.
Änderungen der Ports, Server und Login-Daten führen nur zu Authentifizierungs-Fehlern.


Wer weis Rat?



PS: jo2080
benutzt du eine reine VoIP-Nummer oder eine Freigeschaltete?
Denn Festnetzanrufe lassen sich nur über die "Sinus TC 300" annehmen.
falls FN, versuch mal eine der reinen VoIP-Nummern.



UPS: Muss mich selber korrigieren:
Anmelde- und Ausgangsport sind 5060 - sonst AUTH. Fehler, nur der Lokale port ist 5061 - mit welchem das Gerät dann auch korrekterweise Arbeitet.
 
Zuletzt bearbeitet:
Hallo,

habe alles erdenkliche ausprobiert, helfen konnte mir auch die T-Com Technik nicht.

Bei mir gings mit Portfreigabe bei beiden VoIP Nummer Varianten.

GMX der Sauverein hat nicht einmal auf 2 meiner Mails geantwortet zu dem Problem, finde ich sehr schwach.:mad:

AVM hat mir ein paar Tips ohne großen Wert gegeben aber immerhin geantwortet, die hätten mir bestimmt die korrekten Daten geben können,
da die ja GMX 1und1 etc ja vorbelegen

Habe das Gerät zurückgegeben, da ich es mit T-Online nicht betreiben wollte.

Wobei mit T-Online funktionierte es ohne Probleme auch kein Verbindungsabbruch, war ja klar.

Bei mir war der Abbruch bei GMX nach genau 18 Sekunden.

Was für meine Nutzung nicht so sinnvoll war, dass natürlich die Gespräche nicht in der Gesprächsliste von meiner 7170 sind, ist ja klar.

Werde mir das Nokia E70 kaufen.
 
Habe das gleiche Problem mit TC300 und 1und1.
Eingehende Anrufe funktionieren ausgezeichnet. Das Gerät ist immer erreichbar, auch nach IP-Wechsel durch Zwangstrennung. Aber ausgehende Gespräche brechen immer nach ca. 30 sec. ab.

Wer weiß Rat ?
 
jo2080 schrieb:
Hallo,

habe alles erdenkliche ausprobiert, helfen konnte mir auch die T-Com Technik nicht.

Bei mir gings mit Portfreigabe bei beiden VoIP Nummer Varianten.

GMX der Sauverein hat nicht einmal auf 2 meiner Mails geantwortet zu dem Problem, finde ich sehr schwach.:mad:

AVM hat mir ein paar Tips ohne großen Wert gegeben aber immerhin geantwortet, die hätten mir bestimmt die korrekten Daten geben können,
da die ja GMX 1und1 etc ja vorbelegen

Habe das Gerät zurückgegeben, da ich es mit T-Online nicht betreiben wollte.

Wobei mit T-Online funktionierte es ohne Probleme auch kein Verbindungsabbruch, war ja klar.

Bei mir war der Abbruch bei GMX nach genau 18 Sekunden.

Was für meine Nutzung nicht so sinnvoll war, dass natürlich die Gespräche nicht in der Gesprächsliste von meiner 7170 sind, ist ja klar.

Werde mir das Nokia E70 kaufen.


Nun, ich warte noch auf meine Sinus TC 300 (nach dem die Schlafmützen von der Telekom mir die DSL-variante gebucht haben gabs erst mal wieder Stunk) und teste mit der da ich eine VoIP-Nummer von der Fritzbox an nebenstelle 3 an die Sinus-Base übergeben werde, ob es auch einen Abbruch nach X sekunden gibt, wenn nicht liegt es nämlich am Port-Handling.
Und dann werd ich die Einstellungen weiter austüfteln...
Ich behalt das Tele ;)
 
Zuletzt bearbeitet:
Ich habe das Gerät käuflich im T-Punkt für 249 ¤ erworben gehabt, ohne irgendwelche Verträge.

Sollte sich das Problem mit dem Gesprächsabbruch lösen lassen werde ich es wieder kaufen.

Habe einen Vorsprechtermin im T-Punkt, berichte dann wenn es soweit ist.

Habe festgestellt die Nokia geräte E60 etc sind mit dem VOIP noch nicht so ideal.
 
Hier die Konfiguration für GMX laut Mail,


Der Netphone-Server lautet: sip.gmx.net

Ihr Benutzername setzt sich aus der Länderkennzahl 49 (für Deutschland), der Vorwahl (ohne 0) und der Rufnummer, die Sie freigeschaltet haben, zusammen.

Hierzu ein Beispiel: 493501525606
Passwort: Das ist jenes, welches Sie sich bei der Freischaltung selbst vergeben haben.

Konfiguration der gängigsten Softphones VoIP-Software

USER Domain: sip.gmx.net
SIP Server: sip.gmx.net
Sip Proxy oder Outbound Proxy: bitte leer lassen
oder sip.gmx.net:5060 eintragen.
Stun Server: stun.gmx.net:3478

Achtung:

Wenn Sie einen Router oder eine Firewall verwenden, beachten Sie bitte
folgendes:

Portfreigaben konfigurieren Sie in Ihren Router und/oder Ihrer Firewall für die nachfolgend aufgeführten Ports:

5070 - 5079 (UDP-Protokoll)
30000 - 30019 (UDP-Protokoll)

Schritt 1: Vom Rechner an diesen Ports ausgehende Pakete und die dazugehörigen eingehenden Antwortpakete müssen ungehindert weitergeleitet werden. Für die Portnummern der Gegenseite müssen hierbei beliebige Werte möglich sein.

Schritt 2: Reicht diese Maßnahme alleine noch nicht aus, dann stellen
Sie zusätzlich ein, daß an diese Ports - von außen - Ihres Routers
und/oder Ihrer Firewall eingehende Pakete immer an die lokalen Ports Ihres Rechners mit der gleichen Nummer weitergeleitet werden. Diese Funktion wird oft als "Port Forwarding" bezeichnet.

Bitte beachten Sie zusätzlich:

Bei einigen Routern und Firewalls können Sie die Einstellungen von Schritt 1 und Schritt 2 nicht getrennt, sondern nur gemeinsam aktivieren.

Betreiben Sie sowohl einen Router als auch eine Firewall (z.B. eine zusätzliche Personal Firewall auf Ihrem lokalen PC), dann müssen Sie die oben beschriebenen Schritte sowohl für den Router als auch für die Firewall ausführen.

Für Grandstream Geräte (SIP-Telefone) ist folgende Konfiguration
notwendig:


SIP Server/Registrar: sip.gmx.net
Outbound Proxy: keinen
SIP User ID: *49RUFNUMMER* (Vorwahl ohne 0 und Rufnummer) Authenticate ID: *49RUFNUMMER* (Vorwahl ohne 0 und Rufnummer) Authenticate Passwort: Passwort NAT Traversal: YES STUN Server: stun.gmx.net
 
Das eigentliche Problem ist das die FritzBox Packete an Port 5060 nicht weiterleitet. (Wenn das VOIP der BOX auf 5060 steht) Normalerweise müsste es reichen den Lokalen Port des TC300 z.B. auf 5080 zu stellen und in der FritzBox ein Portforwarding des Ports 5080 auf die IP des TC300 zu setzen. Kann man den lokalen Port nicht Ändern dann muss man an den Port der Fritzbox ändern.

http://www.ip-phone-forum.de/showthread.php?p=770761#post770761

Wichtig ist das der wirklich verwendete Port von außen erreichbar ist.
 
Das eigentliche Problem ist das die FritzBox Packete an Port 5060 nicht weiterleitet

Das eigentliche Problem? Welches meinst Du?

Portfreigaben in der FB sind für das Funktionieren des TC 300 DEFINITIV NICHT erforderlich, zumindest nicht, wenn man die jeweils aktuelle FW für die Box hat. Es gibt mit dem TC 300 derzeit zwei Probleme, die hier im Forum aufgelegt wurden.

Problem 1: TC 300 antwortet an die falsche Adresse auf Status 200 OK
Problem 2: TC 300 erzwingt "Remove all bindings" vor dem ersten Register. Dies funktioniert momentan nicht mit GMX, 1und1 und Web.de

Keines dieser Probleme lässt sich mit einer Portfreigabe in der FB erledigen.

Grüsse
 
zu Problem2 kann ich nix sagen,
aber das Problem1 hatte ich mit meiner 2. Fritzbox (hinter der ersten) auch solange der Port nach außen nicht offen war. GMX ging nicht und Registrarlose brachen nach einigen Sekunden ab. Da die Antworten nach den Aufbau der Verbindung auf die Öffentliche IP der 1. Box Port 5060 zeigten und dadurch nicht mehr bis zur 2. Box durchkommen. Nachdem mein Port wirklich offen war gings.
 
Zwei FB's in Reihe? Wozu das denn? Sicher keine Standard-Konfig. In der von mir gemeinten Konfig (eine FB, PC mit Softphone oder TC 300 oder anderes Hardphone hinter der Box per WLAN oder Draht an der FB) ist es NICHT ERFORDERLICH, auch nur eine Portfreigabe an der Box zu machen.

Ich kann Dir gerne mal einen Blick in die REGISTER Traces geben. Da diese HINTER DER BOX, also im PPPoE, "kurz vor dem Modem sozusagen", gezogen wurden, bin ich ziemlich sicher, dass REIN UND RAUS auf Port 5060 über die Box kommuniziert wurde. Denn mein TC 300 sah genau dasselbe Problem, was etherreal im SIP sah... Da ist nichts Mystisches mit fehlenden Freigaben.

Grüsse
 
spongebob schrieb:
Zwei FB's in Reihe? Wozu das denn?
Ganz einfach. Hab in dem Zimmer nur eine Landose.

spongebob schrieb:
Sicher keine Standard-Konfig. In der von mir gemeinten Konfig (eine FB, PC mit Softphone oder TC 300 oder anderes Hardphone hinter der Box per WLAN oder Draht an der FB) ist es NICHT ERFORDERLICH, auch nur eine Portfreigabe an der Box zu machen.
Das stimmt solange ein Registrar dich mit einen Proxy weiterverbindet.

spongebob schrieb:
Ich kann Dir gerne mal einen Blick in die REGISTER Traces geben. Da diese HINTER DER BOX, also im PPPoE, "kurz vor dem Modem sozusagen", gezogen wurden, bin ich ziemlich sicher, dass REIN UND RAUS auf Port 5060 über die Box kommuniziert wurde. Denn mein TC 300 sah genau dasselbe Problem, was etherreal im SIP sah... Da ist nichts Mystisches mit fehlenden Freigaben.

Kann sein das es mit dem TC300 auch mit offenem Port nicht klappt allerdings ist die Chance groß das es doch geht da man mit offenem Port den Proxy des Registrars einspart.

Ich stimme dir allerdings voll zu das es mit Registrar ohne Portfreigaben eigentlich gehen müßte.
 
Das stimmt solange ein Registrar dich mit einen Proxy weiterverbindet

Sorry, das ist sowas von unsinnig... Wie verbindet mich ein Registrar mit einem Proxy? :confused: Definiere mal bitte, was für Dich ein Registrar und ein Proxy ist... Irgendwie habe ich da andere Vorstellungen :)

Kann sein das es mit dem TC300 auch mit offenem Port nicht klappt allerdings ist die Chance groß das es doch geht da man mit offenem Port den Proxy des Registrars einspart.

Nun ja, der unklaren Aussagen werden leider nicht weniger...

UPDATE: Ahhh, warte mal. Ich versuche gerade, Dein Posting anders zu lesen. Du meinst sicher mit REGISTRAR den externen REGISTRAR Deines Anbieters und mit PROXY Deine zwischengeschaltete zweite lokale FB? Wenn dies so ist, hast Du sicher Recht, obwohl Du Dich nicht ganz korrekt ausgedrückt hast. In diesem Fall verbindet Dich nicht ein Registrar mit einem Proxy, sondern ein Proxy (Deine zweite Kiste) mit dem Registrar. Hierbei kann es durchaus möglich sein, dass auf der Proxy-Kiste ein Portforwarding erforderlich ist. Aber diese Konfiguration ist doch ziemlich "unique", oder?
 
Zuletzt bearbeitet:
Mit Proxy meine ich nichts bei mir sondern den SIP-Proxy des externen Registrars.(ist meist der gleiche Server [z.B. sip.gmx.net]) Wenn sich man komplett hinter einem NAT-Router ohne Portfreigaben befindet laufen alle SIP Daten über diesen Proxy. Ist der Lokale Port aus dem Internet erreichbar dann Baut die Gegenstelle eine Direkte Verbindung auf.

Hat das TC300 hier möglicherweise einen Bug das es nicht den eingestellten Lokalen Port an den Partner übermittelt sondern fest 5060 ? Eigentlich sollte die Konfig aus dem Post 2 auch laufen.
 
Mit Proxy meine ich nichts bei mir sondern den SIP-Proxy des externen Registrars.(ist meist der gleiche Server [z.B. sip.gmx.net])
OK, das macht Deine Aussage oben aber nun wieder komplett unsinnig. Schone erstaunlich, mit welcher Vehemenz Du hier falsche Dinge verbreitest.

Wenn sich man komplett hinter einem NAT-Router ohne Portfreigaben befindet laufen alle SIP Daten über diesen Proxy.
Halt, Halt. Das müssen wir hier mal genauer aufdröseln. Nichts passiert automatisch und NAT u.ä. ist hier erst mal gaaaanz aussen vor und hat mit der Portfreigabe nichts zu tun. Schau zunächst mal bei Google nach, welche Aufgaben ein Registrar und welche ein Proxy hat. Die Trennung ist eine rein logische, also aufgabenbezogene, und muss nicht (ist es auch in den meisten Fällen nicht) eine physische sein.

Es gibt keinen Zusammenhang in der Form "Wenn man sich hinter einem NAT Router befindet, laufen alle SIP Daten über den Proxy". Unsinn. Selbst wenn man direkt am Inernet hängt, laufen die Daten i.d.R. (nicht notwendigerweise) über den Proxy, der (wie Du richtig sagst) meist (nicht notwendigerweise) dieselbe URI hat, wie der Registrar. Allein schon diese von Dir bemerkte Identität beider Entities hätte Dir die Absurdität Deiner Konstruktion nahelegen müssen... Heh, Proxy und Registrar sind identisch, aber wenn man hinter NAT ist, muss der Proxy angesprochen werden, damit die Gegenstelle die Verbindung direkt aufbauen kann... Krude, Krude...

Fakt ist: Ob nun NAT oder nicht: Jeder SIP Stack, jedes SIP Gerät wendet sich zum REGISTRIEREN (Authorisieren mit Benutzername/Passwort) seiner selbst - wenn dies z.B. durch den Provider erforderlich ist - den konfigurierten externen REGISTRAR und benutzt für die Einleitung von Gesprächen (INVITE) den konfigurierten PROXY. Und wenn es korrekt arbeitet, verwendet es die konfigurierten Ports (so natürlich auch das TC 300). Dabei gibt es keine Frage - extern ist da immer 5060 GESETZT, schon vom Standard her. INTERN kann das jeder Port der Welt sein, er muss lokal nur frei sein. Ggf. muss man bei blöden Firewalls ein Portforwarding einrichten, nur eben NICHT bei der FB.

Der REGISTRAR in seiner Funktion als "Zulasser" ist während der Gespräche aussen vor. Er wird nur in (konfigurierbaren) Zeitintervallen immer mal wieder bemüht, weil Registrierungen auch "auslaufen". Der PROXY wird nur solange involviert, bis das die externe URI des Zielpartners bekannt ist. Danach kommunizieren A und B tatsächlich direkt über RTP und auch der Rest der Kommunikation im SIP läuft direkt ab (hier bin ich nicht ganz sicher. Habe noch nie nachgesehen, wer mir eigentlich das BYE schickt. Also dies unter Vorbehalt). Auch hier gilt: Bei blöden Firewalls muss man dazu ggf. ein Portforwarding einrichten (z.B. auch für RTP), nur eben nicht bei der FB.

Ist der Lokale Port aus dem Internet erreichbar dann Baut die Gegenstelle eine Direkte Verbindung auf.

Tja, irgendwie ist da was Halbwahres dran, aber da Du Dich nicht konkret ausdrückst, kommentiere ich das nicht weiter.

Irgendwie habe ich den Eindruck, dass Du hier in Bezug auf NAT das STUN-Protokoll mit SIP verwechselst. Aber auch unter diesem Aspkekt stimmen Deine Aussagen nicht. STUN dient einem Endgerät u.a. dazu, die aktuelle externe IP zu erkennen und diese für den Rückweg der Daten nach aussen zu kommunizieren.

BTW: Bei 1und1 kommst Du hinter NAT ohne STUN noch nicht mal über die Registrierung hinaus, weil 1und1 private URIs komplett ablehnt (zu Recht). Erklär das mal mit Deiner Proxy/Registrar Theorie.

Möglichwerweise kommt all dies ziemlich arrogant rüber, aber sieh es mir bitte nach und fühle Dich nicht auf den Schlips getreten. Nimm dies zum Anlass, Dich noch einmal genau über die Protokolle zu informieren. Dinge werden nicht wahrer, wenn man sie wiederholt.

Grüsse
 
spongebob schrieb:
Möglichwerweise kommt all dies ziemlich arrogant rüber, aber sieh es mir bitte nach und fühle Dich nicht auf den Schlips getreten. Nimm dies zum Anlass, Dich noch einmal genau über die Protokolle zu informieren. Dinge werden nicht wahrer, wenn man sie wiederholt.
Keine Angst das werd ich machen. Ich empfehle dir allerdings das Gleiche da Portfreigabe (in der Fritzbox) durchaus etwas mit NAT zu tun hat. Damit gibt man nämlich an welche Ports von Geräten hinter der Box auch von außen erreichbar sein sollen. Leider kann man den Port 5060 standardmäßig aber nicht freigeben.

Ich gebe auch zu das ich kein SIP Experte bin und SIP eine Menge Fallback-Möglichkeiten hat falls eine direkte Verbindung nicht möglich ist.

Vergleiche auch mal einen Ethereal-Trace von der Registrierung direkt am DSL-Modem und im Lan. Ich denke mal einige Packete vom Registrar werden von den Box abgefangen oder mit Fehler beantwortet. (Die Prüfung ob der Lokale Port von außen erreichbar ist) Danach bleibt die Verbindung zum Registrar offen so das dieser das Gerät weiter erreichen kann. Ist der Locale Port von außen offen braucht der Registrar diese Verbindung nicht halten da er ja die Verbindung selbst Triggern kann.

PS: Werde mir auch so ein Teil zulegen. Scheint ja allein als Handy ganz brauchbar zu sein.
 
Keine Angst das werd ich machen. Ich empfehle dir allerdings das Gleiche da Portfreigabe (in der Fritzbox) durchaus etwas mit NAT zu tun hat. Damit gibt man nämlich an welche Ports von Geräten hinter der Box auch von außen erreichbar sein sollen. Leider kann man den Port 5060 standardmäßig aber nicht freigeben.

So langsam macht mir das Spass mit Dir. Was willst Du als Nächses erklärt haben? PPPoE? Internet über Satellit? DHCP?

Portfreigabe hat NULL KOMMA NULL NIX mit NAT zu tun. NAT = Network Address Translation = ein Verfahren, um private Adressen auf öffentliche Adressen umzusetzen. Eine Krücke, um die notorische IP Knappheit von IPv4 zu umgehen. Die Aufgaben des NAT werden i.d.R. vom Internetzugangsrouter übernommen. Der bekommt eine Public IP vom Provider und kommuniziert mit dieser mit der Aussenwelt. Verkehre von "Innen nach aussen" werden von der privaten IP (als Zieladresse) befreit. An deren Stelle wird die öffentliche IP und ein in einer Mappingtable für diese Relation gemerkte Portnummer eingetragen. So und nur so geht es, dass ein Client mit 192.168.1.1. Pakete von 171.33.44.55 empfangen kann, denn die Antworten von Remote können nur an die Öffentliche zurück. Der NAT-Teil des Routers löst anhand seiner Tabelle die Beziehung Öffentliche IP + Portnummer wieder in eine Private IP (plus initaler Portnummer) auf und forwarded das Paket an den internen Empfänger.

Aber da Du mir das wahrscheinlich wieder ausreden willst, will ich gar nicht weiter in's Detail gehen. Könnte sein, dass die bloße Erwähnung weiterer Fachbegriffe Dich erneut in's Fabulieren bringt :)

Portfreigabe = ein Verfahren, um Firewalls (nicht NAT) zu durchlöchern. Gesetzt den Fall, Deine Firewall lässt per se keinen UDP Traffic über Port 5060 nach drinnen (in deinen Clientbereich), so kannst Du mit der Portfreigabe: "UDP extern 5060 auf intern 192.168.1. Port 5060" dafür sorgen, dass jedes von aussen kommende UDP Paket, dass am öffentlichen Interface der Box Port 5060 ankommt an die interne Zieladresse 192.168.1.1 und den Port 5060 "geforwarded" wird. Eine reine Umschaufelei mit IP Adress-Patchen, das die Schwarte kracht. Mehr nicht.

Ich gebe auch zu das ich kein SIP Experte bin und SIP eine Menge Fallback-Möglichkeiten hat falls eine direkte Verbindung nicht möglich ist.

Ich gebe auch zu, keine Ahnung von Astronomie zu haben, aber die Erde ist eine Scheibe, so wahr mir Kopernikus helfe.

Der Rest ist bla, da gehe ich nicht mehr drauf ein.

IHR WISSENDEN DIESES FORUMS: WILL MIR NICHT BALD MAL EINER BEISPRINGEN UND DIESEN "EXPERTEN"-STREIT MIT EINEM MACHTWORT BEENDEN?

OTHERWISE I'M GOING NUTS...

:)

Grüsse
 
Zuletzt bearbeitet:
Ich geb Ruhe bis ich das Teil hab und selber Testen kann.

PS: Schalte deine Fritzbox mal in die Expertenansicht und geh auf Einstellungen -> Internet -> Portfreigabe dann hast du die Optionen um das NAT von außen zu öffnen.
 
Kostenlos!

Statistik des Forums

Themen
248,867
Beiträge
2,303,314
Mitglieder
378,526
Neuestes Mitglied
looser11