[Info] FRITZ!Box 7590 Laborserie 07.39 – Sammelthema

Und wenn man bei der Einrichtung unten auf "Sie können den Barcode nicht scannen?" klickt kann man sich den Seed bzw. Schlüssel auch anzeigen lassen (und bspw. ganz klassisch auf Papier aufschreiben), muss also nicht der QR-Code sein.

Edit:
Authy gibt es übrigens auch für iOS:
https://apps.apple.com/us/app/authy/id494168017
 
Mein "OTP-Backup" :
Ganz einfach bei der Anzeige des QR-Codes zuerst einen Screenshot machen und irgendwo sicher abspeichern.
Dann kannst du so oft es nötig ist, einen neuen Authenticator damit synchronisieren.

Und ob du den (auf den QR-Code reduzierten) Screenshot ausdruckst, als Datei in einem Veracrypt-Container oder im Keepass speicherst, ist deine eigene Entscheidung.

vy 73 de Peter
 
  • Behoben WLAN-Ausschalten wurde nicht auf Mesh Repeater übertragen, wenn die Mesh-Einstellungsübernahme ausgeschaltet war
Was wurde da schon wieder verschlimmbessert?
Haben sie da nun einen 2. Fehler eingebaut oder sich nur in der Beschreibung verschrieben.

Ich dachte immer es wäre gut und richtig, daß bei ausgeschalteter EÜ das WLAN (Ein- und) Ausschalten nicht übertragen wird ...

Hier noch der Link zum zip: avm.de/fileadmin/user_upload/DE/Labor/Download/fritzbox-7590-labor-96553.zip
und Image: download.avm.de/labor/MOVE21/7590/FRITZ.Box_7590-07.39-96553-LabBETA.image
[Edit Novize: Link entfernt - Verlinken nur offizielle Release-Firmware!]
 
  • Like
Reaktionen: rosi67
Mit dem heutigen FRITZ!OS 7.39-96553 werden beim FRITZ!NAS wieder Umlaute korrekt angezeigt.
 
Wer bei der Einrichtung vergessen hat, das "secret" zu speichern, ist aber auch noch nicht verloren - solange er in der Lage ist, die exportierten Einstellungen der betreffenden FRITZ!Box zu entschlüsseln. Dort findet sich bei den Einstellungen für ein Benutzerkonto dann auch dieses "shared secret" ... in Base32-Kodierung:
Rich (BBCode):
boxusers {
        users {
                enabled = yes;
                id = 13;
                name = "GA-Test";
                email = "";
                password = "<removed>";
                vpn_access = no;
                googleauth_sharedsecret = "WI5MJOGQCBFOXTNIPLSNOVQEO67RWU6C";
                googleauth_devicename = "";
                googleauth_setupdate = "2022-05-13 14:57:51";
                box_admin_rights = secobj_access_rights_readwrite_from_homenetwork_only;
                nas_rights = secobj_access_rights_none;
                phone_rights = secobj_access_rights_readwrite_from_homenetwork_only;
                homeauto_rights = secobj_access_rights_readwrite_from_homenetwork_only;
        } {
[...]
}
Das kann man dann auch in seinem Kennwort-Safe speichern und von dort (sofern der ein "auto-type"-Feature hat) auch automatisch eintragen lassen, wenn man den Safe auf dem Gerät hat, mit dem man sich am FRITZ!OS anmelden will.

Das macht aber beim FRITZ!OS(-Login) jetzt nicht so viel Sinn, weil da die 2FA ja nur bei bestimmten Aktionen erforderlich ist und dann ein "Dialog-Fenster" (mittlerweile in der dialog.js separat implementiert) über den restlichen Seiteninhalt gelegt wird ... aber bei anderen Seiten/Konten kann das durchaus hilfreich sein, zumal viele Kennwort-Safes die Konten auch entsprechenden Webseiten zuordnen können, so daß man da auch nicht lange in irgendwelchen Listen suchen muß und gleich die passenden Einträge angeboten bekommt.

Wenn es AVM jetzt noch schafft, das Dialog-Fenster für die 2FA automatisch so anzuzeigen, daß bei einem angemeldeten Benutzer, für den die 2FA aktiviert ist, auch (a) automatisch der untere Teil sichtbar ist und (b) sogar noch der Cursor im richtigen Feld steht, dann könnte man auch beim FRITZ!OS mit "auto-type" arbeiten und müßte die Ziffern nicht "von Hand" übertragen, solange der Kennwort-Safe das anbietet.

Mit drei geänderten Stellen in der (ebenfalls neuen) twofactor.js ist das auch schon erledigt:
Rich (BBCode):
--- twofactor.js 2022-05-13 20:12:17.231030441 +0200
+++ twofactor.js 2022-05-13 20:11:37.738663295 +0200
@@ -133,7 +133,7 @@

 function buildTfInfo(data) {
     const tfInfo = html2.div({
-        class: "hide",
+        class: ((data.googleauth && googleAuth.isAvailable) ? "show" : "hide"),
         id: "uiTFInfo"
     });
     let linktxt = "{?1973:73?}";
@@ -154,6 +154,7 @@
         noLink: true
     })));
     return html2.fragment(html2.toggleLink({
+        initial: (data.googleauth && googleAuth.isAvailable),
         closedText: linktxt,
         destination: "#uiTFInfo"
     }), html2.br(), tfInfo);
@@ -318,6 +319,7 @@
         if ((data.googleauth && googleAuth.isAvailable && googleAuth.isConfigured) || (data.dtmf && data.code) || data.button) {
             dlgStart(data);
             pollState.start();
+            if (data.googleauth && googleAuth.isAvailable) jsl.focus('uiGoogleAuthCode-input');
         } else if (data.starterror) {
             error = parseInt(data.code || "", 10);
             if (error === 91) {
(die Datei ist bei AVM "minified", daher kann man das nicht einfach als Patch so anwenden) ... damit funktioniert zumindest mit KeePass (2.51.1) auch das "auto-type" (nicht davon irritieren lassen, daß es am Ende "etwas dauert" -> AVM hat da ein Polling drin und da kann es schon mal eine Sekunde dauern, bis das {Enter} dann auch zu einem Roundtrip zum Server (also der Box) führt).

Mal schauen ... wenn AVM das nicht mehr auf die Kette bekommen sollte vor dem Release, werde ich wohl doch mal ein "modscript" bzw. einen Patch dafür machen. Im Moment lohnt das aber noch nicht, denn AVM wird da sicherlich noch einmal ändern ... derzeit steht im 2FA-Fenster (wenn man's ausklappt) ja auch noch, man könne die 2FA wieder abschalten (zumindest in der 113.07-39-86427 Inhouse).



Und auch beim Google Authenticator (GA) kann man Konten auf andere Geräte übertragen - einfach im Menü der App … jedenfalls solange das Ziel eine Kamera hat und ebenfalls die GA-App benutzen soll.

Ansonsten kann man auch den Weg über einen "dummen" QR-Code-Leser gehen, wenn man ein Gerät als "Zwischenwirt" hat, das über eine Kamera UND die passende Reader-App verfügt. Die Übertragung erfolgt als URL otpauth-migration://offline?data=<base64> (viele Reader-Apps kopieren den gelesenen "Text" ins Clipboard und man kann den dann z.B. als Notiz einfügen oder irgendwie anders teilen, um ihn auf einen PC zu bekommen) und dann muß er nur noch dekodiert werden (https://github.com/dim13/otpauth), damit man ihn auch aus der GA-App in andere Apps oder seinen eigenen Password-Safe übernehmen kann.

Das ist jetzt zwar nicht gerade ein Kindergeburtstag (deshalb ist es auch hilfreich, wenn man das "shared secret" gleich beim Einrichten einer 2FA mit TOTP sichert - am besten eben in "Textform"), aber wer bisher nur ein einzelnes Gerät mit der GA-App verwendet und tatsächlich Angst hat, dieses könnte "untergehen", der kann sich auf diesem Weg seine Daten auch sichern ... wo das am besten geschieht, kann sich jeder selbst aussuchen.

Ich rate aber von der Speicherung als Screenshot ab, auch wenn es dann einfacher sein mag, die Daten erneut einzulesen - ansonsten muß man eben die Zeichen in die neue App/den Kennwort-Safe eintragen. Aber (für meinen Geschmack) zu viele QR-Code-Reader (bzw. andere Apps, die ein Bild auf entsprechende Muster scannen) machen das automatisch und ständig "im Hintergrund" (man denke nur an die zunehmend verbreiteten "Anti-Gaffer"-Codes auf RTWs und der Kleidung von Helfern) und da ist dann so ein angezeigter QR-Code auch schnell mal "ungewollt" an einer anderen Stelle gelandet und man hat es gar nicht bemerkt.

Das kann einem zwar bei dem "secret" in Textform auch passieren, aber ohne Kontext ist das erst mal nur irgendeine Zeichenfolge (beim QR-Code ergibt sich der Kontext aus der otpauth-URL, die darin verschlüsselt ist) und man sollte natürlich (auch bei "Zettelwirtschaft") den Zweck der Zeichen nur so notieren, daß man selbst daraus schlau wird, aber kein anderer.

Bei der Speicherung in einem Kennwort-Safe macht es natürlich dann doch wieder Sinn, das gemeinsam mit den anderen Daten für einen Account (Benutzername, Kennwort) irgendwo in einem Eintrag abzulegen - da steht und fällt die Sicherheit dann ja ohnehin mit dem Zugriff auf diesen Kennwort-Safe.
 

Anhänge

  • keepass-otp-dialog.PNG
    keepass-otp-dialog.PNG
    41.5 KB · Aufrufe: 54
  • Like
Reaktionen: NDiIPP
Ich dachte immer es wäre gut und richtig,
Und ich denke, dass ein MESH-Master das WLAN auch tatsächlich eingeschaltet haben sollte, einfach die AVM-MESH-Definition lesen. Dann macht die Aussage im infolab.txt auch Sinn
 
Sorry, aber das ist Quatsch. Ein Mesh-Master kann das Mesh auch ohne eigenes WLAN ganz gut steuern. Das Thema gab's schon öfter.
 
  • Like
Reaktionen: Grisu_
Sinnlos mit 2021 darüber zu diskutieren. Der ist sowas von seiner eigenen Meinung überzeugt und läßt andere nicht gelten, da ist Hopfen und Malz verloren.
 
Habe heute die neueste Labor installiert, von der 7.29 Release aus.
Ich hatte vor einigen Tagen das 5Ghz Netz abgeschaltet und vor dem Update nicht eingeschaltet. Jetzt kann ich dieses Band nicht mehr einschalten, es gibt keinen sichtbaren Button unter WLAN/Funknetz.

EDIT: Gelöst
konnte unter Funkkanal "Funkkanal-Einstellungen anpassen" das Band wieder einschalten.
 
Zuletzt bearbeitet:
Moin, auf der Suche nach einer Lösung für meine Probleme im Zusammenhang mit dem IPSec VPN-Tunnel zur FritzBox bin ich auf das Thema "Labor 7.39 enthält Wireguard" und dann auf diesen Thread gestoßen.

Ich hoffe damit meine Probleme in den Griff zu bekommen, allerdings bin ich auf einen funktionierenden Fernzugang und allgemeine Stabilität der ferngesteuerten Box angewiesen (kein Schnickschnack, wie "NAS" oder Smarthome). Könnt ihr mir sagen, wie stabil diese Labor Firmware mittlerweile ist? Lohnt es sich jetzt schon umzusteigen oder besser den Endrelease abwarten? Übrigens, gibt es schon ein ungefähres Datum, ab wann die FW offiziell verfügbar sein sollte?
 
Es lohnt sich noch nicht für Jedermann. Offiziell wird es für Jedermann in der zweiten Hälfte dieses Jahres zur Verfügung stehen.
 
Zuletzt bearbeitet:
AVM verkündete "im Sommer". Der ist aber lang und geht bis in den September.

Die neueste Laborversion vom 13.05. läuft bei mir eigentlich gut, Abstürze und dergleichen gibt es nicht. Die Zusammenarbeit mit DSL teste ich aber nicht, weil ich den Internetzugang brauche und dafür keine Laborfirmware einsetze.
 
Es lohnt sich noch nicht für Jedermann.
Ich teile die von KunterBunter gepostete Meinung. Für den "produkltiven Einsatz" sollte man keine Labor-, Beta- und sonstige unfertige Firmware verwenden. (Das schreibt hier jemand, der privat seit vielen Jahren so ziemlich alle derartigen Labor usw. testet.)

Jetzt kommt es darauf an, wie eilig du es hast, welche Stabilität du benötigst (und ob du damit leben willst/kannst, ein VPN auf einem Internetrouter zu nutzen).
Ich betreibe schon ein paar Jahre (seit 2019) ein sehr stabil laufendes Wireguard-Netz, bestehend aus gegenwärtig 8 in drei Ländern verteilten externen Wireguard-Servern. Ich nutze dazu drei F!B 4040 und 5 in der Bucht spottbillig zu bekommende F!B 7412. Diese Router wurden mit OpenWrt umgeflasht und werden jetzt ausschließlich als VPN-Server betrieben.
Selbst die "kleinen" 7412 bringen fast den kompletten maximalen Upload unserer 100Mbit/s-Zugänge übers VPN. Und verblüffend schnell werden die Verbindungen auch von den angeschlossenen mobilen Clients beim Wechsel vom heimischen WLAN, Mobilfunk, fremden WLAN und wieder zurück aufgebaut. Und, was das interessanteste ist, dem VPN ist es völlig egal, ob die Internetverbindungen über IPv4 oder IPv6 laufen.

vy 73 de Peter
 
Danke schon mal für eure Antworten! Vielleicht ist es tatsächlich nicht die beste Idee eine Labor aus der Ferne zu installieren, wenn man auf Stabilität und Zuverlässigkeit angewiesen ist, andererseits juckt es mich schon in den Fingern... dann warte ich erstmal noch und hoffe, dass IPSec mich nicht in den Wahnsinn treibt und die Firmware doch nicht erst am letzten Sommertag ausgerollt wird :D

Ich selbst habe keine FritzBox, es geht mir nur darum eine FritzBox per VPN anzubinden (für Remote-Verwaltung und noch ein paar Dienste, aber keine wirklich Traffic-lastigen Sachen). IPSec macht halt hier und da noch Probleme bzw. ist nebenbei auch noch recht kompliziert einzurichten.

Ansonsten braucht man mich nicht zu überzeugen, wie geil Wireguard insgesamt ist und einfach funktioniert. Ich nutze dieses Protokoll schon länger und es hat bei mir nach und nach alle OpenVPN Verbindungen abgelöst. Nur deswegen bin ich so heiß auf das kommende Firmwareupdate.
 
Ich bin gerade von 7.39-96553 wieder zur 7.29 zurück! Wollte mal WG für einen bevorstehenden Auslandsurlaub testen. WG funktioniere gut, aber:
Das NAS kappt alle paar Minuten die Verbindung beim Abspielen :-(

Konstellation: 4GB HDD (ext2) per USB3 an 7590 > WLAN > Rep. 1200 > LAN > Kodi (Raspi 3b+ per SMB2/3) > HDMI > TV
Das ging seit Jahren ohne Probleme.
Auch die Alternative: Mediaserver auf 7590 > WLAN > TV zeigt das selbe Verhalten!
Mit der 7.29 auf der FB ist alles wieder gut!

Balloni
 
Ja, mit sicherer Verbindung im Netzwerk habe ich auch Probleme in den Labor und Inhouse.
Nicht nur Wifi, auch Lan
 
HILFE: Wieso kann man den DHCP Range nicht mehr ändern?
Hatte IP 10.0.0.1/20 mit DHCP auf 10.0.1.0-10.0.1.255.
Die beiden Felder von-bis sind ausgegraut auf meiner Master-Box.
Drum hab ichs deaktivert, jetzt läßt es sich auch gar nicht mehr aktivieren und die Von-Zeile ist rot hinterlegt.
VPN zu einer anderen Box habe ich schon deaktiviert, falls das was blockieren sollte, gibts da noch was anderes?
 

Statistik des Forums

Themen
245,793
Beiträge
2,239,956
Mitglieder
373,012
Neuestes Mitglied
balconi
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.