Sammelthema für FB 7590 mit Firmware "Intern"/"Inhaus" bis 07.22

[chilango79]

Die Dect-Telefone haben jeweils eine eigene Nummer. Willst du beide anrufen wähle dann die **9
Ist hier aber Off-Topic

 

[Björn Otto 1993]

Ich will das beide dect telefone zusammen klingel !!

 

[Joe_57]

@bjoerni1993:
zeig doch bitte mal einen Screenshot von "Telefonie" - "Telefoniegeräte", lass dabei aber unbedingt jeweils die erste und die letzte Ziffer der Telefonnummern sichtbar!

 

[Björn Otto 1993]

Ich habe markiert was ich gerne zusammen haben möchte

 

[NDiIPP]

z.b ich habe zwei Dect Telefone in der Wohnung eins im Wohnzimmer und eins im Schlafzimmer ich möchte gerne beide über **611 laufen lassen.

Was soll der Unsinn bei einer IP-DECT Basis bzw. einer Fritzbox? Bzw. mal eine Gegenfrage: Warum soll das anders sein? Da steckt doch keine analog angeschlossene DECT-Basisstation dahinter, wo es zwangsweise so ist, dass man mehrere an dieser Basistation angemeldete Telefone immer unter einer gemeinsamen Rufnummer bzw. Nebenstellennr. (wenn an einer TK-Anlage angeschlossen) erreichen kann (bzw. muss). Aber genau das ist ja bei ISDN- oder IP-DECT Basistationen (dazu zähle ich auch IADs wie die Fritzbox) dankenswerterweise/glücklicherweise nicht der Fall!

Wer das dennoch will, kann sich ja (optional) immer noch passende Gruppenrufe in der TK-Anlage einrichten (bspw. **711).

 

[Micha0815]

Der erste Versuch via GUI (74542->74948) schlug wieder mal fehl auf meiner WLAN-Repeater-FB. Das kuriose ist, dass die FB -hier GUI- via LAN-Kabel einfach nicht zu erreichen ist. Die Notfall-IP greift auf die Master-FB zu und/oder, falls angeklemmt und WLAN=Aus, auf eine nachgelagerte IP-Client-via-LAN-verbundene FB7390 zu.
Da ich neulich bei einem Mobilfunkexperiment mit einem E3372-s denselben ominösen Zustand irgendwie erreicht hatte, bin ich heute eher durch Zufall reproduzierbar auf den Umstand gestossen, dass die Notfall-IP in diesem Zustand nur bei einer Verbindung des LAN-Kabels an dem blauen WAN-Port funktioniert? In diesem ominösen Zustand haben alle angeschlossenen LAN-Clients (LAN 1-4 ohne Gastnetzeinstellung) stets I-Net-Zugang, als ob die FB nur als unmanaged Switch arbeitet?
Ein Umschalten via linux_fs_start in die vorherige Version hat nix geändert, bis zum Umstecken an den WAN-Port+169.254.1.1.
Trotzdem ich kein Vermeshen möchte, da Master+WLAN-Repeater unterschiedliche SIP-Accounts+Telefonie/FAX-Geräte neben Smarthome-Geräten angemeldet haben, muss ich MESH-Repeater+WLAN auswählen , obschon dies vormals auch über Mesh-Master+WLAN ging.
LG

 

[Dann halt nicht mehr]

Kann jemand für die 74948 Inhouse folgendes Fehlerbild bestätigen:

Nach Update funktioniert beim DECT 400 das Schaltprofil "Lang" nicht mehr.

(Meine Update-Historie vor dem Problem: 74542 - 74611 - 74948)

 

[eisbaerin]

Trotzdem ich kein Vermeshen möchte,

Ja, den Schalter, wo ich das Mesh komplett ausschalten kann suche ich auch noch.
In der rc.conf habe ich nichts gefunden.

 

[Björn Otto 1993]

Übernahme der Einstellungen aus dem Mesh deaktivieren | FRITZ!Box 7590

Standardmäßig übernehmen alle Mesh Repeater im Heimnetz die Einstellungen des Mesh Masters (FRITZ!Box). Allerdings können Sie die Einstellungsübernahme an einzelnen Mesh Repeatern auch deaktivieren und diese danach individuell einrichten. Der Mesh Repeater wird dabei nicht aus dem Mesh entfernt...

avm.de

das habe ich gefunden !!

 

[grundigboy]

Hallo,

habe das Update von der normalen Labor (!) auf diese Inhouse gemacht, obwohl meine Box nicht Bootloader-Signatur-Frickel-manipuliert ist. Bisher keine sichtbaren Probleme. Mit der Labor hatte ich immer wieder kurzzeitige WLAN-Abbrüche bei einzelnen Netzwerkgeräten (Echo und Co), was aber auch im Labor-FW bekannt ist. Mal sehen, ob es nun besser läuft.

Ich wünsche Euch ein schönes Wochenende.

VG

Thomas

 

[eisbaerin]

das habe ich gefunden

Danke, aber wie da schon steht:
"Der Mesh Repeater wird dabei nicht aus dem Mesh entfernt"

Ich möchte es aber komplett abschalten, so wie bei einer FW vor dem Mesh.

 

[HarryP_1964]

Nach Update funktioniert beim DECT 400 das Schaltprofil "Lang" nicht mehr.

Nein, kann ich nicht bestätigen. Bei mir funktioniert am DECT400 sowohl lang als auch kurz.

Harry

 

[Dann halt nicht mehr]

Damn it. Dann muss ich wohl nochmal anders zu werke gehen.

 

[avm_7170]

@bjoerni1993:

beide dect telefone zusammen klingel

Dafür legst du dir einen Telefonbucheintrag an ....z.B. Björns Telefone
Dieser Eintrag bekommt eine interne Telefonnummer z.B. 710
In dieser Eintrag trägst du die beiden internen Telefonnummern der Dect Telefone ein
in dieser Form **1#611#612

Dann kannst du beide Telefone unter **710 erreichen ...beide klingel zusammen

 

[alexandi]

@Daniel Lücking
Schon mal so probiert ?:

 

[Björn Otto 1993]

Vollzitate sind nach wie vor unerwünscht. Zitiere ab sofort mit Maß - by stoney

Danke danke schön hat geklappt

nur auf passen **1#611#612 das hat auch gklappt nur die falschen geräte haben geklingelt
**2#611#612 hat geklappt !!! hier haben die richtigen geräte geklingelt

 

[PeterPawn]

obwohl meine Box nicht Bootloader-Signatur-Frickel-manipuliert ist.

Wen wundert's ... da von den Images ja auch nicht mehr wirklich eine Gefahr ausgeht, verwendet AVM da auch wieder die "normalen" Keys zum Signieren - bereits seit der ersten 07.19, die den Weg in die Öffentlichkeit fand.

Alles das, was ein Angreifer früher (als der Shell-Zugriff über "Shell in a Box" noch existierte) durch die Installation einer (korrekt signierten) Inhouse-Version hätte anrichten können, ist ohne diesen Shell-Zugriff kein echtes Thema mehr ... auch die Lua-Console ist m.W. weg. Da müßte man sich also schon noch deutlich mehr einfallen lassen, um mit einem solchen Inhouse-Image einen Angriff auf Boxen bei einem Nutzer starten zu können.

Es gibt also gar keinen (offensichtlichen) Grund mehr für AVM, die Installation einer solchen Inhouse-Version auf einer "normalen Box" zu unterbinden - dabei ist halt auch der Shell-Zugriff (bzw. auch die Lua-Console, weil die auch wieder Shell-Zugriff erlaubt) für alle Benutzer einer solchen Version auf der Strecke geblieben und die Unterschiede ggü. offiziellen Versionen reduzieren sich auf ganz wenige und nicht wirklich sicherheitsrelevante Dinge, nach denen man schon sehr genau suchen muß. Der Vorteil einer solchen Inhouse-Version dürfte für die meisten also nur noch in der etwas höheren Frequenz von "Neuerscheinungen" liegen - sicherlich auch eine Gruppe von Interessenten, aber beileibe auch nicht die einzige.

Selbst das "webcm", was bei 07.08-Inhouse-Images noch dabei war (und für manchen wohl auch ein "alter Bekannter" ist, denn darin verbarg sich 2014 die Schwachstelle, über die per "lang"-Parameter die "Übernahme" der Boxen möglich war - auch wenn die dann mittlerweile schon geschlossen war), ist inzwischen nicht mehr an Bord ... auch wenn ein Binary mit dem vielsagenden Namen "rpcstreamcap_notimeout" das offenbar noch als Ziel-URL in einem "refresh"-Header einer HTML-Seite verwenden möchte. Dieses Binary hat AVM aber schon in den Release-Versionen vor der 07.12 in der Firmware "vergessen" (das darf man zumindest unterstellen - hinzugekommen ist es irgendwann im Frühjahr 2018 bei der 06.98-Reihe, iirc), während es in der 07.12 dann wieder verschwunden war.

Als Fazit kann man also inzwischen festhalten, daß die Unterschiede zwischen Inhouse- und "offiziellen" Labor-Versionen sich so weit verringert haben, daß erstere inzwischen auch "harmlos" sind und damit ist es auch nur noch ein kleines Problem, wenn ein Unbefugter so ein Image dank korrekter AVM-Signatur ohne Kenntnis des Besitzers installieren könnte.

 

[Dann halt nicht mehr]

@Daniel Lücking
Schon mal so probiert ?:
Anhang anzeigen 103735

Nope - kommt nicht in Frage. Hier hängt die 7590 als Mesh-Repeater und macht DECT wegen der Smartbulbs und die 6890 ist noch auf Stand 7.12. Wäre gut, wenn da bald ein Labor käme. Naja... jetzt muss es erstmal ohne den Taster Lang gehen ... neu Einrichten mag ich gerade nicht und es schaut aus, als hätte ich da einen Konfig-Kuddel-Muddel...

 

[NDiIPP]

BTW:

Wen wundert's ... da von den Images ja auch nicht mehr wirklich eine Gefahr ausgeht, verwendet AVM da auch wieder die "normalen" Keys zum Signieren - bereits seit der ersten 07.19, die den Weg in die Öffentlichkeit fand.

Deshalb war ich übrigens auch sehr verwundert darüber, dass @SnoopyDog (sh. Beitrag #2.746) sich einen dermaßen umfangreichen Installationsweg für die Inhaus-Version herausgesucht hatte...

Obwohl bereits @Daniel Lücking vor mehreren Monaten festgestellt hatte (sh. Beitrag #2.060), dass das eigentlich nicht notwendig ist. Auch wenn es da natürlich noch nicht explizit um die gerade aktuelle 74948 ging. Und er war auch nicht der einzige, der das seit dem (erneut) festgestellt bzw. wiederholt hatte. Auch für die folgenden 07.19er Inhaus-Versionen (in diesem Thread sh. bspw. #2.062, #2.131#, #2.205, #2.260, ...).

Aber dennoch warst du ja noch einmal so freundlich, in #2.747 auf die Bootloader-Installationsvariante als Alternative zu verweisen.

 

[Micha0815]

Dem ominösen "Nichterreichbarkeits-Status" auf der Spur, scheint es ein Problem mit dem E3372 zu sein, dessen Verbindungseinstellungen sich irgendwo in der *.export vergraben haben. Demnach

Spoiler

Da ich neulich bei einem Mobilfunkexperiment mit einem E3372-s denselben ominösen Zustand irgendwie erreicht hatte, bin ich heute eher durch Zufall reproduzierbar auf den Umstand gestossen, dass die Notfall-IP in diesem Zustand nur bei einer Verbindung des LAN-Kabels an dem blauen WAN-Port funktioniert? In diesem ominösen Zustand haben alle angeschlossenen LAN-Clients (LAN 1-4 ohne Gastnetzeinstellung) stets I-Net-Zugang, als ob die FB nur als unmanaged Switch arbeitet?
Ein Umschalten via linux_fs_start in die vorherige Version hat nix geändert, bis zum Umstecken an den WAN-Port+169.254.1.1.

stimmt dies nicht so ganz, da ein update via FW-Datei das Problem nurnoch verschärfte. Mit keiner LAN/WLAN-Option konnte ich die FB noch erreichen! Daraufhin 7.12-Recovery->Update auf 74542, von der ich eine funktionierende *.export hatte und direkt einspielte. Conjo+wieder ward die FB nur als Ghost sichtbar aber nicht erreichbar weder über einen LAN/WAN-Port noch WLAN obschon Clients I-Net hatten?
Erst durch das Einstecken des E3372 und seiner Modem-Registrierung, griff der Zugriff via Notfall-IP 169.254.1.1 auf das GUI. Dort waren beide WLANs abgeschaltet und der "MESH-Repeater"-Status musste zur WLAN-Basis-FB neu initialisiert werden. -Div. DECT-ULE-Smarthome-Bulbs und Türkontakt mussten über "bekannte DECT-Geräte wiederverbinden" neu eingebunden werden.

Erneut versuchte ich via GUI wiederum das Update auf 74948, was erfolgreich erschien, allerdings mit demselben frustrierenden Ergebnis? Erst das Anstecken+Initialisieren des E3372 liess -zwecks Bearbeitung der Einstellungen überhaupt- einen LAN-Zugriff mittels 169.254.1.1. zu zwecks Einstellungskorrektur.
LG
P.S.: Wer in seiner config mal mit dem E3372 und HiLink-FW getestet hatte ... auch mit aktueller Release-FW der 7590 ... sollte imho mit "spitzen Fingern" die jüngeren Ausgaben hier geniessen. Ich zähle mich nicht zu den qualifizierten Haubentauchern sondern eher zu einem Gelegenheitsknappernden-Marder aus Lust an der Freude