[Sammlung] Sammelthema für FB 7590 mit Labor-Firmware "INTERN"

chilango79

Aktives Mitglied
Mitglied seit
14 Apr 2010
Beiträge
1,964
Punkte für Reaktionen
51
Punkte
48
Die Dect-Telefone haben jeweils eine eigene Nummer. Willst du beide anrufen wähle dann die **9
Ist hier aber Off-Topic
 

Joe_57

IPPF-Promi
Mitglied seit
5 Mrz 2006
Beiträge
5,538
Punkte für Reaktionen
97
Punkte
48
@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!
 

NDiIPP

Aktives Mitglied
Mitglied seit
13 Apr 2017
Beiträge
2,489
Punkte für Reaktionen
414
Punkte
83
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

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
3,645
Punkte für Reaktionen
181
Punkte
63
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ählen103733 , obschon dies vormals auch über Mesh-Master+WLAN ging. 103734
LG
 
Zuletzt bearbeitet:

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,579
Punkte für Reaktionen
159
Punkte
63
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

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,212
Punkte für Reaktionen
232
Punkte
63

bjoerni1993

Neuer User
Mitglied seit
8 Nov 2015
Beiträge
109
Punkte für Reaktionen
4
Punkte
18


das habe ich gefunden !!
 

grundigboy

Mitglied
Mitglied seit
31 Aug 2006
Beiträge
781
Punkte für Reaktionen
12
Punkte
18
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

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
7,212
Punkte für Reaktionen
232
Punkte
63

HarryP_1964

Mitglied
Mitglied seit
5 Aug 2017
Beiträge
737
Punkte für Reaktionen
63
Punkte
28

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,579
Punkte für Reaktionen
159
Punkte
63
Damn it. Dann muss ich wohl nochmal anders zu werke gehen.
 

avm_7170

Aktives Mitglied
Mitglied seit
4 Jun 2015
Beiträge
1,241
Punkte für Reaktionen
79
Punkte
48
@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

Aktives Mitglied
Mitglied seit
11 Jun 2009
Beiträge
1,680
Punkte für Reaktionen
186
Punkte
63

bjoerni1993

Neuer User
Mitglied seit
8 Nov 2015
Beiträge
109
Punkte für Reaktionen
4
Punkte
18
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
 

Anhänge

Zuletzt bearbeitet von einem Moderator:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,526
Punkte für Reaktionen
852
Punkte
113
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.
 

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,579
Punkte für Reaktionen
159
Punkte
63
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

Aktives Mitglied
Mitglied seit
13 Apr 2017
Beiträge
2,489
Punkte für Reaktionen
414
Punkte
83
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... :confused:

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

IPPF-Promi
Mitglied seit
25 Feb 2008
Beiträge
3,645
Punkte für Reaktionen
181
Punkte
63
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
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 :D
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
234,026
Beiträge
2,041,777
Mitglieder
353,329
Neuestes Mitglied
juevie