Fritzbox 7412 mit Gluon und DSL-Modemsnutzung?

Hallo zusammen,

ich wollte nachfragen ob jemand die 7412 erfolgreich inklusive Nutzung des Modems in Betrieb hat. Wäre als „Kombilösung“ schon nicht ganz unattraktiv.

Ich wette, dass die Antwort „niemand“ ist.

Hallo,

ich habe mittlerweile 8 F!B 7412 zu Wireguard-Servern umgeflasht (vlt. kann sich noch jemand an meinen diesbezüglichen Thread erinnern, wo ich da nach passender HW fragte).
Und wenn ich da schon mal ein anderes OS drauf habe - dachte ich - dann kann ich doch auch mal die paar Haken für das DSL-Modem setzen.
JA, eine DSL-Verbindung kommt zu Stande, aber selbige ist von der Qualität (viele PPPOE-Fehler, erreichbare Bandbreite usw.) nicht mit der einer originalen F!B 7412 zu vergleichen.
Ich habe einen DSL-Zugang 100/40 von 1&1 mit Telekom als Vorleister. Aufgrund meiner TAL von 456m Länge bekomme ich zwar nur 86Mbit/s, diese aber mit der 7590 dafür sehr stabil. Kein Gedanke daran bei der 7412!

MfG Peter

2 „Gefällt mir“

Ich spekuliere mal, dass der Thread hier als Anregung diente, in Gluon gestern diese Änderung einzupflegen:

Nein, der Change kommt daher, dass auf den TP-Link Geräten in diesem Target nicht genug Platz war für einen Build mit OWE/WPA3 und wir bisher keine DSL-Integration haben.

2 „Gefällt mir“

Danke für deine haltlose Unterstellung. Der Grund in weniger ausführlicher Form steht im PR, und nun steht er hier im Forum noch genauer. Es war nicht mehr genug Platz für einen erfolgreichen Build.

Dann entschuldige ich mich, auf den irreführenden Commit-Text hereingefallen zu sein.
Ich hatte den angegebenen Grund „wird entfernt, weil nicht benötigt/benutzt“ für bare Münze genommen.
Wenn ich über nachgedacht hätte, dann hätte ich das „nicht genug Platz, Build fails“ natürlich riechen müssen. Mein Fehler, Entschuldigung nochmals, einfach nur nur den Commit-Text als Basis für haltlose Unterstellungen genutzt zu haben.

The packages necessary to get the DSL modem working increase the
squashfs size by around 1MB.

Remove them from Gluon, as this functionality is not supported.

Hmm. Kann man das nicht anders lösen, mit Buildtime-Flags z. B.? OWE setzt mindestens Android 10 voraus, wird also schon seitens der Endgeräte auf absehbare Zeit ein Nischenprodukt sein. (Eines, was zudem gefühlt primär dazu taugt, telnet auch im öffentlichen WLAN vermeintlich sicher zu machen.) Ich jedenfalls würde Modemfunktion in Gluon OWE- und WPA3 vorziehen.

Die Implementierung hierfür fehlt komplett, aber Pull Requests für diese Implementierung sind gerne gesehen. Die größte Herausforderung ist hierfür vermutlich, dass eine zweite VDSL Line / ein DSLAM für sinnvolle Test benötigt wird.

Die Pakete haben dir vorher auch nicht viel genutzt. Einerseits sind die beiden Firmware welche entfernt wurden sackalt und unterstützen kein Vectoring, andererseits entfernte Gluon pppoe bereits vorher standardmäßig.

Über die Site packages kansnt du die packages wieder hinzufügen, allerdings müsstest du eine Vectoring-fähige Firmware bundlen, welche nirgends unter einer passenden Lizenz erhältlich ist.

2 „Gefällt mir“

Ein völlig unbrauchbares VDSL-Modem/Treiber nutzt niemandem

Es gibt keine Treiber-Drops in passender Lizenz, wir haben zudem kein G.993.5-Testbed.
Von daher halte ich die Entfernung des kaputten Modemtreibers für mehr als gerechtfertigt.

Mein Posting daher so miszuverstehen fand ich daher schon ziemlich belustigend, wo ich doch eigentlich sagen wollte „Die Gluon-Leute haben die Rückmeldung zum disfunktionalen Treiber hier (eventuell) aufgegriffen, den rauszuwerfen“

Wenn natürlich der Grund in Wirklichkeit ist, dass in einigen TP-Link-Geräten mal wieder nicht genug Platz ist, und daher das auch für die AVMs rausfliegen muss: Gekauft.

Das initiale Problem bleibt: Das Modem ist für uns nur im Notlauf ansprechbar und daher produziert die Nutzung mehr Frust als Nutzen. Lösen kann es sinnvoll nur der Hersteller/Chiplieferant, indem es Treiber für die Datapump mit offener Lizenz gibt.

2 „Gefällt mir“

in Kombination mit deiner Einstellung in der Vergangenheit kam es bei uns eher so an, als unterstellst du uns dass wir DSL aktiv verhindern wollen.
Aber dein aktuellster Beitrag liest sich nun anders.

WPA3 verbreitet sich recht schnell eigentlich, Windows 10 kann es auch schon, alte Software gibt es immer, das war bei WPA1 → WPA2 nicht anders.
OWE hat aktuell in der Tat nicht viel Sinn, dank der Bugs in diversen Android 9 Implementierung die eine Nutzung des Transition Mode sinnlos machen :frowning:

Ich möchte Dir jetzt nicht mehrere meiner Postings hier im Forum heraussuchen, in denen ich mich ganz klar gegen den Ansatz gestellt habe „Kann man nicht Gluon auf eine Fritzbox bringen, weil da ein Modem schon mit drin ist“, entsprechende Anfrage gab es früher ja alle paar Monate wieder.

Eben weil da mehr als nur 2-3 Komponenten damals im Gluon fehlten, um das bisherige Bedienkonzept „einstiegsfreundlicher Setupmode“ beizubehalten.

Daher macht das in OpenWrt ja durchaus Sinn; in Gluon, wo WPA3 grundsätzlich überflüssig und nur im gelittenen Sonderfall ‚privates WLAN parallel aussenden‘ nutzbar ist, sehe ich nicht so die Relevanz. Da Du selbst schreibst, daß OWE mit clientseitigen Problemen kämpft, und aus Gründen der effizienten Airtime-Nutzung so wenig VAPs wie möglich genutzt werden sollten, erscheint mir rein technisch der OWE-Support gerade nicht zielführend. Es ist eine schöne Funktion für’s Powerpoint-Marketing, siehe AVM, aber in der technischen Gesamtbetrachtung erscheint mir OWE (derzeit) überflüssig wie ein Kropf.

Ich gebe allerdings zu, daß VVDSL mit Freifunk auf 763x/7412/7490(?) auch eine Nischenanwendung ist. $hier wäre es ggf. das Mittel der Wahl, eine angedachte großflächigere Innenstadtabdeckung (alle ~100m 'n VVDSL-Uplink) umzusetzen — aus Providermodem, Offloader (L2TP-Tunnel nach Mesh-on-LAN), Unifi-AP outdoor könnte man zumindest ein Gerät streichen.