FRITZ!Box 7590 - INHAUS 7.39 - Sammelthema

EVA-Gefriemel mit kernel.images
Wer macht/braucht so etwas, um einfach nur auf das andere Set an Partitionen umzuschalten? Das macht ein Großteil sogar mit dem Windows-FTP-Client, obwohl der gar keine passiven Transfers unterstützt und damit auch nicht geeignet ist, irgendwelche "kernel.images" auf die Box zu bringen (nicht mal auf den NAS-Flash, wenn das FRITZ!OS arbeitet).
 
Bitte zur Kenntnis zu nehmen, dass ich mich einfach nur darüber gefreut habe, dass ein Downgrade mit AVM-Bordmitteln auch bei einer sehr jungen Inhaus-Version gelingt!

nun etwas OT als Antwort an PP:
Linux und das Hantieren mit Windows-PS-Scripten zum Umschalten auf ein anderes Set an Partitionen ist mir ein Gräuel. Ellenlange Threads (Protokolle des Scheiterns mit Versuch-Irrtum-Bemühungen) und dazu Erklärungen von mehreren Seiten, die ich mit dem Vermerk TLDR lieber links liegen lasse, sind beredtes Zeugnis für das "Gefriemel", das ich meine.
Meiner Meinung gibt es eben auch den Umstand, dass neben einigen, die stolz über Linux-Kenntnisse verfügen, eine große Anzahl von Fritzbox-Nutzern gerne ohne dieses Sonderwissen und ohne Studium der Grundlagen anwendungsbasiert an der Entwicklung von neuer Firmware teilnimmt. Das hier in der Vergangenheit gerade von den Script-Verfechtern kritisierte ruKernelTool war ein Beispiel für eine alternative Anwendung, die diesem Wunsch entsprochen hat.
(Die Kritik, dass dabei zur Vereinfachung der Anwendung für den User "nach Hause telefoniert worden sei" ist vor dem Hintergrund der heute gängigen, gesellschaftlichen Akzeptanz mit iOS, Android und Microsoft fast schon etwas belustigend...
 
  • Like
Reaktionen: Grisu_
Linux und das Hantieren mit Windows-PS-Scripten zum Umschalten auf ein anderes Set an Partitionen ist mir ein Gräuel.
Dann nimm halt beides nicht dafür. Geht schließlich auch mit Win-Bordmitteln ohne irgendwelche Scripte und ohne irgendein "Gefriemel".
 
@NDiIPP:
Gib Dir keine Mühe, das ist halt kein Adam und daher hat er mit EVA nichts am Hut. Kann ich auch mit leben - nur lasse ich halt Feststellungen oder Behauptungen, wie kompliziert das doch alles sei, nicht einfach unwidersprochen stehen (erst recht nicht, wenn sie fachlich zweifelhaft sind) und hinterfrage das dann gerne ... schon aus dem Grund, damit sich andere (die sich nicht "so anstellen") davon nicht auch noch abschrecken lassen, weil ihnen dann vielleicht beim Lesen weiterer Beiträge dämmert, daß diese Aussagen sehr subjektiv sind und man sich vielleicht besser ein eigenes Bild machen sollte.

@TSprecher:
Niemand will Dich selbst zu irgendetwas "zwingen" oder stört sich daran, wenn Du für Dich eine Entscheidung getroffen hast, das wäre in Deinen Augen "Gefriemel". Es gab auch schon genug andere, die derselben Ansicht waren - ein Teil davon (wie groß der sein mag, kann ich gar nicht einschätzen) wurde "bekehrt", wunderte sich dabei noch, wie einfach das am Ende war und freut sich heute (wie Du bei der AVM-Lösung, die Du schon als "komfortabel" ansiehst, was sicherlich auch nicht jedem so geht) darüber, daß ein leichter Rückweg existiert, der (zumindest als erster Versuch immer lohnt und) auch in den allermeisten Fällen funktioniert und wenn das so ist, dann sogar alle Schritte, die nach dem Zurücksetzen/Wiederherstellen der Konfiguration noch notwendig wären, überflüssig machen kann.

Je nachdem, wie kompliziert die eigene Konfiguration ist und wieviel davon beim Wiederherstellen eben NICHT verarbeitet werden kann (weil es gar nicht in der Sicherungsdatei enthalten ist), spart das halt bei dem einen viel Zeit und bei einem anderen fast gar keine.

Ich kann es gar nicht definitiv sagen, weil ich diesen ganzen Inhouse-/Labor-Quatsch schon lange nicht mehr mitmache ... aber neben dem "Ablatschen" von DECT-Geräten für eine erneute Kopplung (was wohl auch beim "Bulk-Modus" für DECT-Verbindungen noch erforderlich ist) müßten auch die beiden RSA-Keys und die Zertifikate (sowohl das interne als auch das von Let's Encrypt für einen MyFRITZ!-Namen) danach erst mal weg sein. Ich kann jedenfalls in der Sicherungsdatei (7590 / 07.29) keine Daten für die RSA-Keys (oder auch die Zertifikate, wobei die ohne die Keys ja ohnehin nichts bringen) finden. Damit sollte es dann sogar notwendig sein, alle zuvor angemeldeten FRITZ!Apps erneut zu verbinden, was bei manchen sogar nur dann funktioniert, wenn sich das Gerät im WLAN der Box befindet. Dazu kommen dann noch alle Browser, bei denen man ggf. den RSA-Key der Box gepinnt hatte, etc. - das kann sich jedenfalls ganz schon ziehen.

Sollte das bei jemandem mit seinen FRITZ!Apps nicht so sein (daß die nach einem Reset, auch wenn danach die Einstellungen wiederhergestellt wurden, neu verbunden/eingerichtet werden müssen), würde mich das tatsächlich neugierig machen, wie das dann funktionieren soll. Denn die AVM-Apps pinnen zumindest den öffentlichen Schlüssel, der im FRITZ!Box-Zertifikat enthalten ist - wird ein neuer Key generiert, weil beim Wiederherstellen keiner enthalten war in der Sicherung, ändert sich selbstverständlich auch der öffentliche Schlüssel und die Apps sollten sofort rebellieren - zumindest sollten sie Alarm schlagen, wenn sich die Identität einer FRITZ!Box ändert, denn das könnte ja auch der "man in the mirror middle" sein.



Aber langer Erklärung kurzer Sinn (ich hoffe die vier kurzen Absätze hier drüber schaffen es innerhalb Deiner Aufmerksamkeitsspanne gelesen zu werden) - wenn diese Umschaltung funktioniert, weil ein Update nichts Entscheidendes an den Einstellungen geändert hat, dann spart das viel Arbeit ... zumindest bei denen, die ihre Box(en) ausgiebig nutzen mit vielen DECT-Geräten und AVM-Apps.

Und für diese Zielgruppe, die das dann auch nutzen will, frage ich an solchen Stellen immer wieder nach - denn die Aussage weiter oben, daß bei diesem "Gefriemel" irgendwelche "kernel.images" involviert wären, ist eindeutig Blödsinn, solange es ausschließlich um die Umschaltung auf das vorherige System geht. Da hast Du offenbar dann doch eine Wissenslücke (und es bleibt natürlich Dir überlassen, ob Du sie schließen willst) ... und Deine Aussage diesbezüglich sollte nicht dazu führen, daß sich jemand von Deiner Ansicht abschrecken läßt. Ob man sich das ansehen will oder nicht, sollte jeder selbst entscheiden (dürfen), ohne daß man ihm davor irgendwelche Angst einjagt.

Ich kenne (verbürgt) mind. einen Fall, wo selbst eine knapp 80-Jährige es mit telefonischer Anleitung geschafft hat, ihre FRITZ!Box per Windows-FTP-Client auf die zuvor verwendete FRITZ!OS-Version zu "downgraden" ... alles ohne jede "Installation" zusätzlicher Software und ohne irgendeinen zusätzlichen Download, solange nur der FTP-Client installiert war (was bei Windows Standard wäre).
 
Hi,
ich habe mit dieser Version sehr viele Reconnects. Ich habe mal auf maximale Störsicherheit gestellt.

Ralf
 
Wie siehts mit dieser Version aus?

Ich habe mal auf maximale Störsicherheit gestellt.
Ist übrigens kein Allheilmittel...
 
Was haben die länglichen Beiträge weiter oben mit der Inhaus-Firmware für die 7590 zu tun? Richtig: nichts!

Ständige Reconnects habe ich nicht mit der neuesten Version, aber manchmal scheint es ihr langweilig zu sein und sie legt einen spontanen Reboot hin. Die Vorgängerversion hatte das auch hin und wieder. Nach einem Neustart der Box fehlt im Smarthome-Menü des C6 der Punkt "Vorlagen" - der taucht erst dann auf, wenn man die Aktoren aufruft und dann zurück geht. Ist halt die Frage, ob es an der Firmware der Box oder der des C6 liegt.
 
  • Like
Reaktionen: TSprecher
Hi,
Ist übrigens kein Allheilmittel...
ich weiß aber Hoffnung stirbt zuletzt. Zurück auf Release will ich eigentlich vorerst nicht obwohl mich die VoIP Probleme schon ärgern.

Ralf
 
  • Like
Reaktionen: betaman2
Wahrscheinlich eine FRITZ-Tender-Erweiterung, aber darum ging es eigentlich gar nicht!:rolleyes:

Harry
 
  • Like
Reaktionen: Karl. und zorro0369
FRITZ-Tender-Erweiterung
Ja aber schon komisch dass er die da so ständig zeigt und kein Wort darüber verliert. Und manch einer denkt jetzt dass so die 7590AX aussieht.

Es sind auch noch andere Fehler vorhanden.
 
Zuletzt bearbeitet:
Frage an die Theoretiker oder Wissenden hier:
Gemäß Video ist ja WireGuard viel schneller als IPSEC (beides ohne HW-Unterstützung).
Jedoch mit HW-Unterstützung läßt die alte AVM Lösung WireGuard wiederum alt aussehen.
Kann mit WireGuard die HW-Unterstützung (auf der 7590 (ax)) nicht verwendet werden oder ist es (hoffentlich) nur eine Frage der Zeit, bis dies dann wieder zugeschaltet wird?
Damit würde VPN auf der Box ja wirklich nochmals abheben.
 
Servus,
ich hoffe ich habe es hier nicht überlesen.
Funktioniert Wireguard dann auch mit IPv6 oder nur mit IPv4???
 
Kann mit WireGuard die HW-Unterstützung (auf der 7590 (ax)) nicht verwendet werden oder ist es (hoffentlich) nur eine Frage der Zeit, bis dies dann wieder zugeschaltet wird?
Das ist ne gute frage, ich würde in dem Inhaus Stadium vermuten, dass man erstmal Wireguard vollständig einbaut, bevor man mit Hardwarebeschleunigung anfängt.
 
Wireguard benutzt ChaCha20 und wird mit AES-Hardware nicht viel bis gar nichts anfangen können.
Immerhin hatte die 7590ax aber 95Mbit/s Upload geschafft und würde aktuell nur den 200er Upload vom teuersten privaten Telekom-Glasfasertarif für 959,40 per anno so richtig ausbremsen.
 
  • Like
Reaktionen: Grisu_
Schade aber danke für die Antwort.
Dachte eigentlich, daß Verschlüsselung etwas eher Generisches (irgendwelche überall genutzte kryptische oder von mir aus auch kryptographische Berechnungen) ist und man die HW-Beschleunigung (ähnlich wie eine GPU für Mining) für unterschiedlichere Aufgaben heranziehen könnte.
Naja, ist halt HW-zentriert und daher schwerst spezialisiert offensichtlich.

Dann bleibt für die 7590 wohl nur noch zu sagen, wie gewonnen so zeronnen oder ein Schritt nach vorne und 2 zurück.
Wozu sie dann das ganze aber überhaupt noch dieses Jahr erst implementiert haben anstatt gleich (für alle Boxen nutzbar) auf WireGuard umzusteigen bleibt mir dann aber im Verborgenen und nicht nachvollziehbar.
Die Arbeit hätten sie sich sparen und besser investieren können, indem sie gleich WireGuard für alle bringen mit der letzen Release.
Das Ende war ja damals schon genauso für sie absehbar.
 
Zuletzt bearbeitet:
Zumindest versucht man offenbar, es mit IPv6-Support zu integrieren:
Code:
# Port - Open via PCP
pcptest -u -p ${listen_port} -l 0 -d wireguardv4 >/dev/null 2>&1 &
pcptest -6 -u -p ${listen_port} -i 0 -l 0 -d wireguardv6 >/dev/null 2>&1 &

echo "Initialized Wireguard interface (${wg0_ip}/32) listening on ${listen_port}."



bevor man mit Hardwarebeschleunigung anfängt
Hardware-Beschleunigung für AES (was AVM auch im CBC-Mode benutzt, wie man in den Initialisierungen für ip xfrm im vpnd sehen kann - und das ist nun mal nicht parallelisierbar, weil Ergebnisse einer vorherigen Verschlüsselung für einen Block in die Verschlüsselung für den nächsten eingehen: https://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode - in Deutsch) ist etwas vollkommen anderes, als für WireGuard.

Letzteres benutzt einen anderen Algorithmus - ChaCha20 mit Poly1305: https://datatracker.ietf.org/doc/html/rfc7539, der auch erst später standardisiert wurde und daher bei IPSec (zumindest in der ersten Version) noch gar nicht dabei sein konnte: https://www.heise.de/security/meldu...-ChaCha20-fuer-TLS-abgeschlossen-3249531.html, wobei hier die Pakete tatsächlich unabhängig voneinander verschlüsselt werden können (das ist ein AEAD-Verfahren: https://en.wikipedia.org/wiki/Authenticated_encryption) und damit ist es auch parallelisierbar, wobei es dafür sogar ein (relativ unbekanntes) Kernel-Interface namens padata gibt und davon profitiert WireGuard dann auch auf Multi-Core-Systemen. ChaCha20 und Poly1305 gibt es in IKEv2 erst seit RFC 7634 (Mai August 2015).

Gleichzeitig ist das aber eben KEIN AES und wenn Hardware-Einheiten nur für ältere Algorithmen ausgelegt sind, profitiert WG davon nicht. Ich weiß nicht genau, wie es beim GRX5 aussieht, aber auch bei anderen Kernel-Quellen abseits von AVM, wo man die originalen Lantiq-Patches sehen kann: https://github.com/paldier/K3C/blob...patches-3.10/8041-GRX500-LTQ-crypto.patch#L25, ist von ChaCha20-Poly1305 nichts zu sehen beim Hardware-Support.

Auch bei AVM findet man in der Implementierung (bisher) nur folgende Algorithmen (im eip123-Treiber):
Code:
56 #define POLICY_CRYPTO_KEY_AES (1 << 0)
57 #define POLICY_CRYPTO_KEY_CAMELLIA (1 << 1)
58 #define POLICY_CRYPTO_KEY_3DES (1 << 2)
59 #define POLICY_CRYPTO_KEY_MULTI2 (1 << 3)
60 #define POLICY_CRYPTO_KEY_C2 (1 << 4)
61 #define POLICY_CRYPTO_KEY_HMAC_SHA1_KEY (1 << 5)
62 #define POLICY_CRYPTO_KEY_HMAC_SHA224_KEY (1 << 6)
63 #define POLICY_CRYPTO_KEY_HMAC_SHA256_KEY (1 << 7)
und da der Autor hier offenbar sehr gründlich war bei der Definition der denkbaren Anwendungen (C2 (https://en.wikipedia.org/wiki/Cryptomeria_cipher) und MULTI2 (https://en.wikipedia.org/wiki/MULTI2) braucht man für IPSec sicher nicht), würde ich mal vermuten, daß es KEINEN Hardware-Support (weder für's Ver-/Entschlüsseln mit ChaCha20, noch für "Message Authentication" mit Poly1305) für WG geben KANN.

Was ChaCha20-Poly1305 beschleunigen KANN, sind Einheiten für Vector-Befehle, wie sie moderne x86-Prozessoren automatisch haben (https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) und die es auch auf anderen Plattformen durchaus gibt - bei MIPS in Form von Erweiterungen für DSP (Digital Signal Processing) und auch als MSA (MIPS SIMD architecture). Nur ist diese Architektur eben ein "Baukasten", aus dem man sich das zusammenstellen kann, was man tatsächlich braucht und bis 2018 zog das entsprechende Lizenzkosten nach sich, so daß man schon deshalb (und natürlich auch, weil solche Funktionen halt Die-Fläche brauchen) nur das nahm, was man auch brauchte. Ich denke jedenfalls, daß der GRX5 auch deshalb keine Vector-Engine haben dürfte - aber die Fähigkeiten der tatsächlich vorhandenen Hardware sind nur wenig bekannt (in der Öffentlichkeit).

Da es m.W. bisher bei WG auch keine alternativen Algorithmen gibt (die ja ohnehin auf beiden Seiten genutzt werden müßten), sieht es mit Hardware-Support für WG vermutlich eher schlecht aus. Der Autor der verwendeten Algorithmen hat selbst einige optimierte Versionen für verschiedene Plattformen (mit unterschiedlichen Befehlssätzen bei x86) bereitgestellt: https://cr.yp.to/chacha.html - meines Wissens gibt es aber keine solche für MIPS-CPUs ohne passende Erweiterungen (ich bin nicht mal sicher, ob es FÜR die o.a. MIPS-Optionen optimierten Code irgendwo gäbe).

Wenn WG also bei Messungen nicht an IPSec (mit AES und Hardware-Support) herankommen sollte, dann muß man damit vermutlich leben - aber ich lasse mich auch gerne überraschen von einer sehr performaten Umsetzung. AEAD mit ChaCha20-Poly1305 gäbe es ja immerhin als Kernel-Module, was schon deshalb OpenVPN von der Performance her um Längen schlägt, weil letzteres am Ende im User-Space arbeitet. Als Alternative zu OpenVPN ist damit WG NATÜRLICH schneller (und bietet eben auch IPv6 wie WG OpenVPN), der Durchsatz (auf passenden Boxen) dürfte mit AES/SHA1 dennoch höher sein, solange diese beiden Algorithmen von der Hardware-Beschleunigung profitieren.
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,149
Beiträge
2,246,980
Mitglieder
373,668
Neuestes Mitglied
Stripi
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.