[Gelöst] DECT Telefone stürzen bei Freisprechen an 7270v2(IP-Mode) ab ....help!

hominidae

Neuer User
Mitglied seit
8 Jan 2015
Beiträge
69
Punkte für Reaktionen
3
Punkte
8
Hallo Leutz,

ich habe hier ein echt komischen Phänomen, mit meinen beiden Gigaset DECT A630 Mobilteilen an meiner FB 7220v2.:eek:
Auch denke ich aktuell nicht, dass es an den Mobilteilen liegt (die Akkus sind frisch geladen und i.O.).
Deshalb probiere ich mal mein Glück hier im FB-Telefonie Forum.

Der "Bug":
Wenn ich ein Gespräch im Freisprech-Modus starte, wird der Ruf aufgebaut und kurz nachdem die Gegenseite abhebt, wird das Mobilteil dunkel, sprich geht aus. Die FB hat, ausser dem Anruf Versuch nix im Log.

Mein Setup:
Die 7270v2 (ist als IP-Client konfiguriert und macht nur DECT mit AB und den 2 Mobilteilen (WLAN & DSL sind aus).
Sie verbindet sich mit einer 7272 (Kabel, GSM- und SIP/Voip Telefonie) und einer 6840LTE (LTE und SIP/Voip) als Registar.
Bei allen FB ist WLAN aus...DECT ist nur an der 7270v2 an.


Wenn ich das Gespräch "normal", ohne Freisprechen starte, dann geht alles prima.
Ebenso, wenn ich die Mobilteile an den anderen FB anmelde, geht auch Telefonie-Aufbau mit Freisprechen.
Die Mobilteile waren auch schon an der 7270v2 ohne Probleme im Einsatz, als diese mein "alleiniger" Router war, also damals nicht im IP-Client Modus lief (allerdings nicht mit diesem OS 6.06).

Hat noch jemand ältere OS-Versionen für meine 7270v2...das wäre das Einzige was mir noch einfiele..

Edit: ...anbei der Screenshot vom /Dect/Basisstation-Menü der FB

fsTl4mk.jpg


Greetz,
Hominidae
 
Zuletzt bearbeitet:
...danke für den Link...wusste tatsächlich nicht, dass es hier die Image-Sammlung gibt...mein Google-Foo hat es nicht zutage gebracht.
 
Wurde die letzte Option > Problembehebung mal [X] aktiviert ? (auch wenn ich mir keine große Hoffnung mache)
 
nein, ehrlich gesagt nicht, weil die Mobilteile eben vorher einwandfrei auch ohne das [X] liefen und an den anderen Boxen noch laufen.
 
....ich habe ja alle drei FB parallel in Betrieb und alle können DECT.
Ziel ist es die Telefonie beider "Amtsköpfe" (FB7272 und FB6840LTE) mittels der FB7270v2 zu "erschliessen" ...deshalb läuft die 7270 im IP-Client Modus.
Daher DECT nun standardmässig nur an der 7270 in Betrieb....dort tritt dann der Fehler auf.
Testweise habe ich dann aber das DECT jeweils mal in den anderen Boxen (wechselseitig, immer nur eine gleichzeitig) eingeschaltet und die Mobilteile dort angemeldet...dort tritt der Fehler nicht auf.

Die ältere FW habe ich nicht mehr...die 7270 "damals" ge-freezt und war dann einige Zeit eingemottet bzw. wurde in einer Ferienwohnung "normal" für DSL benutzt...dazu erhielt sie das Update auf die Original 6.06
Ich weiss leider nicht genau welche Version es war, aber es war eine 5.7x ...denke 05.74, denn das war die letzte, bevor die 06er rauskam, wenn ich mich richtig erinnere.
 
Interessant ist es allemal - auch wenn das wahrscheinlich auch nicht Zielführend is (bzw ja eig. nichts mit Deinem Problem zu tun haben soltle), aber das NT der 7270 wurde mal getauscht?

Bitte berichte, ob es mit einer (und welcher) es funktioniert

54.06.06 -> 10/2015
54.06.05 -> 06/2014
54.05.54 -> 02/2014
54.05.53 -> 09/2013
54.05.52 -> 08/2013
54.05.50 -> 01/2013
54.05.22 -> 06/2012
54.05.21 -> 04/2012
54.05.05 -> 07/2011
54.04.88 -> 12/2010
54.04.86 -> 09/2010
54.04.80 -> 12/2009
54.04.76 -> 06/2009
54.04.70 -> 02/2009
54.04.67 -> 12/2008
54.04.59 -> 09/2008
54.04.58 -> 07/2008
54.04.57 -> 05/2008
54.04.55 -> 03/2008
54.04.53 -> 02/2008
54.04.52 -> 02/2008
54.04.50 -> 01/2008
54.04.49 -> 12/2007
54.04.48 -> 12/2007
54.04.46 -> 11/2007
54.04.44 -> 11/2007
 
Da WLAN und DSL aus ist, läuft die sehr sparsam...das NT ist, glaube ich, das der (neuen) 7272, denn die hängt im Netzwerkschrank an einer zentralen, grösseren Versorgung.
Ja, die 05.54 war die letzte der "alten" Serie, nicht 05.7x...aber egal, denn....

....dank Deiner Hilfe habe ich nun die 05.54 aufgespielt...und das Phänomen ist weg :D

Another problem solved by the helpdek from hell :p

Nochmals heissen Dank an Alle!

greetz,
Homindae
 
======================================================================
Achtung Sicherheitslücke!
In den Firmware-Reihen yy.04.67 bis yy.06.02 einschließlich(!) ist im Modul der Fernwartung eine gravierende Sicherheitslücke aufgetaucht,
die auch aktiv genutzt wird/wurde.
Siehe auch diesen Thread: Telefonie-Missbrauch anscheinend (doch) Massenhack von AVMs Fritzboxen
Bei Einsatz einer dieser erwähnten Firmware-Versionen ist die Box von innen und von außen angreifbar
======================================================================
Hhmm, auch wenn dein Aufbau etwas speziell ist, ist das nicht ganz ausgeschlossen. Ich tippe sogar auf ein "einfaches KKK". Somit wäre ein Update auf die letzte FW sicher nicht falsch und dann nur die notwendigen Daten und Einstellungen eingeben...
 
...meine FB haben keine Fernwartung aktiviert, auch kein WLAN, kein MyFritz aktiviert....werden eigentlich nur für die Telefonie verwendet...das I-Net der beiden Fritten mit WAN-Anschluss geht 1:1 per exposed Host auf einen Mikrotik und dessen Firewall ist zu.
Die beiden Fritten mit WAN haben die aktuelle, offizielle FW...nur die "interne" 7270v2, nun wegen des hier beschriebenen Problems, die 05.54.
Alternative wäre die 7270v2 gegen eine Voip-fähige Gigaset-Basis zu tauschen...

PS: ...was bitte ist "KKK" in diesem Zusammenhang ?
 
werden eigentlich nur für die Telefonie verwendet
Rufe doch einfach mal eine URL wie
Code:
http://<ip_7270>/cgi-bin/webcm?getpage=../html/menus/menu2.html&var:lang=%26reboot%26
auf (korrektes Escaping abseits von %26 überlasse ich Dir, Credentials sollten nicht erforderlich sein) und wenn dann die 7270 kurz danach mit einem Neustart reagiert, kannst Du Dir zwischen die beiden "&" (also die beiden %26 genauer) ein paar andere Kommandos denken.

Damit kann man dann (wenn es funktioniert - eigentlich ist die 05.54 m.W. bei der 7270v2 aus 02/2014 und sollte bereits gefixt sein - vielleicht willst Du es ja mit der 05.53 noch einmal testen) auch problemlos (und eben ohne Anmeldung) die Einstellungen dieser Box auslesen lassen (da liegen nicht zufällig SIP-Credentials für irgendeinen anderen Registrar?) und das wieder von praktisch jedem Client, der sich in demselben Netz befindet, wie diese Box.

Dazu braucht es gar keine Fernwartung (höchstens dann, wenn man das auch von der WAN-Seite der 7270 machen wollte, so sie eine hat und nicht - wie bei Dir - als IP-Client arbeitet) - das ist eine immer wieder gerne genommene Fehleinschätzung.

Im Zeitalter von Android-Handys mit Malware in Apps aus dem Play-Store, sollte man sich nicht mehr darauf verlassen, daß ja niemand wissen kann, was bei einem im Netz überhaupt vorhanden ist ... so eine FRITZ!Box kündigt sich auch schon mal über UPnP an und wenn dann eine App mit Malware in irgendwelchen Datenbanken nach potentiellen Schwachstellen sucht, findet man diese "webcm"-Schwachstelle praktisch umgehend (in jeder Menge Exploit-Datenbanken).

Auch ist es i.d.R. ein Leichtes, die Firmware der Box zu ermitteln ... die sollte direkt in der Ausgabe von "http://<ip_7270>/jason_boxinfo.xml" auslesbar sein und wie lange diese Schwachstelle bestand, gehört zu den Basisdaten in einer Exploit-DB.

Ich weiß aber auch, daß immer die anderen angegriffen werden ... leider kenne ich auch Fälle, wo genau über diese Lücke dann ein Schaden von ~ 5.000 EUR entstanden ist (durch fremde Telefonate über zusätzliche SIP-Clients), bei denen auch der Kunde die Folgen tragen mußte, weil weder der Provider (z.B. A1) noch AVM sich für zuständig erklärten - bei AVM gab es zu dieser Zeit noch keine funktionierende(!) internationale Firmware für die Box (war eine 7390i, ist aber dasselbe Prinzip).

Also ... meines Erachtens ist die 05.54 zwar tatsächlich bereits gefixt, aber wenn das noch nicht der Fall wäre, ist das Argument "hat ja gar keinen Internetzugriff" (oder etwas in der Richtung) leider wenig stichhaltig. Moderne Malware lädt zur vorhandenen Hardware im Netzwerk passende Module nach und muß nicht mehr von Beginn an alles mit sich herumschleppen - und da ist so ein Router (nicht nur von AVM, aber eben auch von AVM) ein sehr dankbares (und leicht zu erkennendes/zu treffendes) Ziel.
 
KKK,= klassisches konfigurations Kuddelmuddel

:rolleyes: OK den kannte ich noch nicht....
Hmm...naja...hier auf dem Land, ohne DSL .. mit Kabel alllein geht leider nix mit einer Verfügbarkeit die den WAF erfüllt ...also Dual-WAN mit LTE :(
Insofern, würde ich mein Setup als "komplex" bezeichnen...mit der FB7220v2 "in der Mitte" leider getrieben dadurch, dass die Firmware der Fritten einfach verkrüppelt ist und die beiden anderen FB im normalen Router-Mode keinen SIP-Registrar im Heimnetz akzeptieren wollen.

Rufe doch einfach mal eine URL wie
Code:
http://<ip_7270>/cgi-bin/webcm?getpage=../html/menus/menu2.html&var:lang=%26reboot%26
auf (korrektes Escaping abseits von %26 überlasse ich Dir, Credentials sollten nicht erforderlich sein) und wenn dann die 7270 kurz danach mit einem Neustart reagiert, kannst Du Dir zwischen die beiden "&" (also die beiden %26 genauer) ein paar andere Kommandos denken.

...da kommt dann:
Code:
[B]httpd[/B]

[B]404 Not Found [/B]

The requested URL was not found on this server.

...wäre dies das erwartete Ergebnis bei einer gefixten Firmware (Sorry, bin kein Web-Inschinör, von wegen Escaping und so)?

Also ... meines Erachtens ist die 05.54 zwar tatsächlich bereits gefixt, aber wenn das noch nicht der Fall wäre, ist das Argument "hat ja gar keinen Internetzugriff" (oder etwas in der Richtung) leider wenig stichhaltig. Moderne Malware lädt zur vorhandenen Hardware im Netzwerk passende Module nach und muß nicht mehr von Beginn an alles mit sich herumschleppen - und da ist so ein Router (nicht nur von AVM, aber eben auch von AVM) ein sehr dankbares (und leicht zu erkennendes/zu treffendes) Ziel.
Ja, schon klar, das wollte ich auch nicht sagen...ich hatte die Lücke als eine allein in der Seite der Fernwartung verstanden.
Leider gibt es wenige, so flexible Alternativen zur FB was die Telefonie-Unterstützung angeht....ich nutze SIP, Festnetz & GSM und das finde ich in einem Gerät nirgendwo anders so einfach.[/CODE]
 
Zuletzt bearbeitet von einem Moderator:
Wobei das mit dem "Router-Mode" und "keine SIP-Registrare im LAN" definitiv auch nicht stimmt (EDIT: zumindest nicht für alle Boxen und Firmware-Versionen) ... das könnte eine ältere Feststellung sein, die man aber getrost noch einmal prüfen kann. Wenn der "voipd" es mit der Zuordnung des richtigen Interfaces nicht alleine auf die Reihe kriegt (wobei das bei einem LAN-Registrar meist sogar besser und von Beginn an funktioniert, weil diese Accounts auch dann schon funktionieren, wenn das eigene (DSL-)Modem noch trainiert wird), dann kann man ihm mit passenden "hints" in der "voip.cfg" (sipiface = ...) unter die Arme greifen. Wenn das also keine topologischen/geographischen Gründe hat, daß da noch eine 7270 eingebunden ist, sollte sich das auch ohne dieses "alte Schätzchen" lösen lassen.
 
Hmmm...OK, das wäre interessant....geht das mit Standard-FW oder muss ich die Box freetzen?
Es geht um eine 7272 und eine 6840LTE, jeweils aktuelle FW....wären wohl auch vom Freetz Trunk und 2.0 unterstützt, obwohl ich das gerne vermeiden würde.

Beide FB nehmen den anderen "internen" Registrar an, aber verbinden sich nicht...im Ereignis Log dazu steht nur "Zeitüberschreitung"...
Die Routen zum Heimnetz der anderen Fritte sind jeweils eingerichtet....meine Firewall sieht aber keinen Traffic bzw. dessen Versuch zwischen den Fritten.

TIA,
Hominidae
 
Geht auch mit Standard-Firmware ... zuerst solltest Du in den Support-Daten der Box(en) - wobei ich mich erst mal auf die Verbindung der einen mit der anderen konzentrieren würde, auch wenn das später mal wechselseitige Registrierungen brauchen sollte, weil an beiden Boxen Telefone hängen, die jeweils auch die anderen Nummern verwenden sollen - mal nachsehen im SIP-Protokoll (ist aber nur ein kleiner Ring-Puffer, also nur eine begrenzte Anzahl der letzten SIP-Nachrichten in beide Richtungen), welche Interfaces die "Client"-Box (also die, welche hier den SIP-Client gibt) denn für das Senden von REGISTER-Paketen benutzt.

Ist das bereits das falsche, muß man gegensteuern ... mit dem schon genannten Stichwort "sipiface" (ggf. mit Wildcard dahinter, weil die einstellbaren Werte "sipiface_irgendwas" lauten) sollte eine Suche auch zu den möglichen Werten führen und auch zu weiteren Diskussionen zu diesem Thema. Die angezeigte "Zeitüberschreitung" sagt ja nur aus, daß kein vollständiger SIP-Dialog möglich ist ... woran genau das scheitert, muß man eben erkunden. Wenn tatsächlich die Boxen nur über einen internen Router miteinander kommunizieren können und da ist kein einziges Paket zu sehen, versucht es der "voipd" als SIP-Client (der vereint beide Rollen in sich und arbeitet sowohl als Client als auch als Registrar für die Einträge in der "voip.cfg") wohl bei beiden Boxen auf dem falschen Interface.

Wobei ich auch schon Leute gesehen habe, die auf ihrem internen Router eine Firewall aktiviert hatten, um die Netze voneinander zu trennen und sich dann wunderten, warum da keine Datenpakete hin- und hergingen. Hier bin ich bei der Aussage "meine Firewall" halt etwas unschlüssig ... hängt die 7270v2 dann in einem dritten (internen) Netz und kommuniziert mit beiden (Router-)Boxen über diese Firewall?

Ich weiß natürlich nicht, wie gut Du Dich mit Netzwerken auskennst ... aber wenn beide Boxen jeweils als DMZ oder "extern" am internen (MikroTik-)Router hängen, würde eigentlich fast jede Firewall (ich kenne Deinen Mikrotik ja nicht und weiß weder, welche Router-OS-Version dort aktiv ist, noch wie die eingestellt wurde) den Traffic zwischen diesen beiden Netzen ja blockieren, während es aus einem "internen" (in dem die 7270 hängt) in jedes der beiden dann doch funktioniert. Auch käme natürlich der SIP-Traffic von jeder FRITZ!Box (im Gegensatz zu den "echten" externen Verbindungen, wo ja dann die externe Absenderadresse aus dem Internet auch in einem Paket steht, das an den "exposed host" weitergeleitet wird) von deren LAN-Adresse als Absender ... ich habe keine Ahnung, wie der MikroTik das findet. Bei der Lösung mit der 7270 "in der Mitte" ist das für den ja alles eine von innen initiierte Verbindung, wenn da an eine FRITZ!Box über den MikroTik-Router Daten gesendet werden und für die ist der "Rückweg" dann ja bereits eingerichtet ... beim Registrierungsversuch der Box bei der anderen wäre das genau (im MikroTik) nicht der Fall.

Egal, wie Du das hinkriegst ... wenn dann das erste REGISTER-Paket am internen Router zu sehen ist, weil die Box das richtige Interface nimmt (dank entsprechender Änderung in der "voip.cfg", die man auch ohne Änderungen an der Firmware in einer Export-Datei machen kann, wenn man die Prüfsumme in der Datei nach der Änderung korrigieren läßt), dann muß man eben den weiteren Weg auch Schritt für Schritt verfolgen und irgendwann kommt es dann beim Registrar auch in der Support-Datei (bzw. im SIP-Protokoll) an. Paßt dann die Antwort vom Inhalt her (die erste wäre natürlich eine Ablehnung, weil die "nonce" bei der Anmeldung nicht stimmt, bei SIP ist es normal, wenn erst der zweite Versuch klappt), dann muß man deren Rückweg verfolgen.

Wobei es m.W. für den Registrar selbst keine Möglichkeit gibt, einen Client an irgendein Interface zu tackern - die Antwort des "voipd" sollte auf dem Interface gesendet werden, auf dem die Nachricht empfangen wurde. Will der Registrar trotzdem partout ein anderes Interface verwenden (die LTE-Box hatte ich in so einem Kontext noch nicht in den Händen), muß man halt auf dem internen Router auch noch NAT machen, so daß der Client für den Registrar wie der interne Router aussieht (so ist das bei mir, aber aus anderen Gründen) und es gar keine eingetragenen Routen in der FRITZ!Box braucht (weil der interne Router das über sein CT wieder an/für den Client übersetzt).

PS: Freetz 2.0 vergiß ganz schnell ... da war Deine Recherche "zu kurz gegriffen" - ist in etwa dasselbe Problem wie zu alte AVM-Firmware, warum nur der Trunk noch Sinn ergibt.
 
Ich hatte ein ähnliches Problem mit gigaset-Geräten nach einem Firmware-Update. Geholfen hat damals die Mobilteile abzumelden und neu anzumelden.
 
Geht auch mit Standard-Firmware ... zuerst solltest Du in den Support-Daten der Box(en) - wobei ich mich erst mal auf die Verbindung der einen mit der anderen konzentrieren würde, auch wenn das später mal wechselseitige Registrierungen brauchen sollte, weil an beiden Boxen Telefone hängen, die jeweils auch die anderen Nummern verwenden sollen - mal nachsehen im SIP-Protokoll (ist aber nur ein kleiner Ring-Puffer, also nur eine begrenzte Anzahl der letzten SIP-Nachrichten in beide Richtungen), welche Interfaces die "Client"-Box (also die, welche hier den SIP-Client gibt) denn für das Senden von REGISTER-Paketen benutzt.

Ist das bereits das falsche, muß man gegensteuern ... mit dem schon genannten Stichwort "sipiface" (ggf. mit Wildcard dahinter, weil die einstellbaren Werte "sipiface_irgendwas" lauten) sollte eine Suche auch zu den möglichen Werten führen und auch zu weiteren Diskussionen zu diesem Thema. Die angezeigte "Zeitüberschreitung" sagt ja nur aus, daß kein vollständiger SIP-Dialog möglich ist ... woran genau das scheitert, muß man eben erkunden. Wenn tatsächlich die Boxen nur über einen internen Router miteinander kommunizieren können und da ist kein einziges Paket zu sehen, versucht es der "voipd" als SIP-Client (der vereint beide Rollen in sich und arbeitet sowohl als Client als auch als Registrar für die Einträge in der "voip.cfg") wohl bei beiden Boxen auf dem falschen Interface.

OK, danke...das sind im Moment bömische Dörfer für mich...da muss ich mal mein google-foo bemühen.


Wobei ich auch schon Leute gesehen habe, die auf ihrem internen Router eine Firewall aktiviert hatten, um die Netze voneinander zu trennen und sich dann wunderten, warum da keine Datenpakete hin- und hergingen. Hier bin ich bei der Aussage "meine Firewall" halt etwas unschlüssig ... hängt die 7270v2 dann in einem dritten (internen) Netz und kommuniziert mit beiden (Router-)Boxen über diese Firewall?
Ganz genau...meine beiden I-Net Verbindungen werden von jeweils einer Fritz aufgebaut. Ein (Mikrotik) Router dahinter spielt Dual-WAN Manager und hat auch mein eigentliches Heimnetz (LAN) in der Verantwortung.
Da der Mikrotik in der jeweiligen FB als Exposed Host geführt wird, muss er eine aktive Firewall haben.

Ich weiß natürlich nicht, wie gut Du Dich mit Netzwerken auskennst ... aber wenn beide Boxen jeweils als DMZ oder "extern" am internen (MikroTik-)Router hängen, würde eigentlich fast jede Firewall (ich kenne Deinen Mikrotik ja nicht und weiß weder, welche Router-OS-Version dort aktiv ist, noch wie die eingestellt wurde) den Traffic zwischen diesen beiden Netzen ja blockieren, während es aus einem "internen" (in dem die 7270 hängt) in jedes der beiden dann doch funktioniert. Auch käme natürlich der SIP-Traffic von jeder FRITZ!Box (im Gegensatz zu den "echten" externen Verbindungen, wo ja dann die externe Absenderadresse aus dem Internet auch in einem Paket steht, das an den "exposed host" weitergeleitet wird) von deren LAN-Adresse als Absender ... ich habe keine Ahnung, wie der MikroTik das findet. Bei der Lösung mit der 7270 "in der Mitte" ist das für den ja alles eine von innen initiierte Verbindung, wenn da an eine FRITZ!Box über den MikroTik-Router Daten gesendet werden und für die ist der "Rückweg" dann ja bereits eingerichtet ... beim Registrierungsversuch der Box bei der anderen wäre das genau (im MikroTik) nicht der Fall.
Ja, stimmt...aber no worries...da kenn ich mich aus.
Du hast im Prinzip recht...aber in der Firewall sehe ich nicht mal den Versuch der "externen" FB mit der jeweils anderen zu kommunizieren.
Da kann die Firewall noch so falsch eingestellt sein und alles blockieren...das Problem liegt dann ja eben zunächst nicht an der Firewall.


Egal, wie Du das hinkriegst ... wenn dann das erste REGISTER-Paket am internen Router zu sehen ist, weil die Box das richtige Interface nimmt (dank entsprechender Änderung in der "voip.cfg", die man auch ohne Änderungen an der Firmware in einer Export-Datei machen kann, wenn man die Prüfsumme in der Datei nach der Änderung korrigieren läßt), dann muß man eben den weiteren Weg auch Schritt für Schritt verfolgen und irgendwann kommt es dann beim Registrar auch in der Support-Datei (bzw. im SIP-Protokoll) an. Paßt dann die Antwort vom Inhalt her (die erste wäre natürlich eine Ablehnung, weil die "nonce" bei der Anmeldung nicht stimmt, bei SIP ist es normal, wenn erst der zweite Versuch klappt), dann muß man deren Rückweg verfolgen.

Wobei es m.W. für den Registrar selbst keine Möglichkeit gibt, einen Client an irgendein Interface zu tackern - die Antwort des "voipd" sollte auf dem Interface gesendet werden, auf dem die Nachricht empfangen wurde. Will der Registrar trotzdem partout ein anderes Interface verwenden (die LTE-Box hatte ich in so einem Kontext noch nicht in den Händen), muß man halt auf dem internen Router auch noch NAT machen, so daß der Client für den Registrar wie der interne Router aussieht (so ist das bei mir, aber aus anderen Gründen) und es gar keine eingetragenen Routen in der FRITZ!Box braucht (weil der interne Router das über sein CT wieder an/für den Client übersetzt).
Hmmm...ja, wenn ich die Interfaces NATe brauche ich im Router aber noch ein Port-Forwarding und das wird bei Wechselseitigen Verbindungen der beiden Fritten dann eher aufwendig bzw. wieder eine Baustelle.
Einfacher wäre es evtl. - wenn die SIP-Verbindung nach innen im Router-Modus klappt - beide LAN-Interfaces der Fritten gleich ins selbe LAN-Netz zu ziehen.

PS: Freetz 2.0 vergiß ganz schnell ... da war Deine Recherche "zu kurz gegriffen" - ist in etwa dasselbe Problem wie zu alte AVM-Firmware, warum nur der Trunk noch Sinn ergibt.
OK, aber so wie ich Dich verstanden hatte sollte es ganz ohne Freetz gehen....da fang ich mal an.
 
Ich hatte ein ähnliches Problem mit gigaset-Geräten nach einem Firmware-Update. Geholfen hat damals die Mobilteile abzumelden und neu anzumelden.
Ja, danke für den Tipp...aber ich habe ja die FB "gewechselt" und musste die Mobilteile eben auch neu anmelden...hatte die auch mal zurückgesetzt, ohne Erfolg.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.