AVM-Watchdog - kann man den guten gewissen deaktivieren?

Mach mich mal schlau ... wieso paßt Dein Verweis auf "06_9X_MIN" (das wäre ja drei Zeilen nach dem "07_1X_MAX") nicht zu den von mir geschriebenen Versionsnummern?

Oder willst Du nur darauf hinaus, daß der Benutzer (anders als bei anderen Patches, die wir in diesem Thread schon hatten) den auch "abwählen" könnte? Dazu müßte er erst einmal danach sehen im "menuconfig" - was er nicht machen wird, wenn er nicht weiß, daß es ihn gibt. Das ist für mich "aufs Auge gedrückt" - und die Frage war nicht, wie die "nicht-VR9"-Boxen darauf reagieren (da wird es ja nicht eingebaut), sondern die anderen VR9-Boxen, wo es das zweite FRITZ!OS für die WLAN-Versorgung nicht gibt.

Denn daß von einem "ifconfig wlan up" irgendwann auch "netlink"-Nachrichten (https://man7.org/linux/man-pages/man7/netlink.7.html) durch die Gegend geschickt werden, dürfte hoffentlich unstrittig sein und wenn die einen AVM-Daemon erreichen, der darauf wartet, wird der auch irgendwie reagieren (und da ist die Hardware dann auch "lokal" erreichbar) - ein ordentlicher Test würde eben auch bedeuten, daß man sich vergewissert hat (und es nicht nur hofft), daß davon keine negativen Konsequenzen ausgehen.

Denn die Aktionen eines "ifconfig ... up" sind üblicherweise:

1. Das angesprochene Link-Layer-Device wird initialisiert.
2. Dem Device werden IP-Adressen zugeordnet.
3. Die Routen, die über dieses Device führen (explizit gesetzte oder die, die sich aus den Adressen ableiten), werden in die Routing-Tabelle eingetragen.

(Das kann man alles nachlesen, wenn man es wissen will.)

Hat tatsächlich mal irgendeiner darüber nachgedacht, ob es schlau wäre, bei einer Box, die meinetwegen ihre Internetverbindung per WLAN bezieht (wo also "wlan_wan" verwendet wird) und ansonsten ihr WLAN für den lokalen Betrieb lieber ausgeschaltet lassen würde, auch diesen Patch einzusetzen? Die Konfigurationsmöglichkeiten gerade beim WLAN sind so vielfältig (wenn's schlecht läuft, ist sogar das WLAN "open", weil es nur zu bestimmten Zeiten, dann aber "für alle" freigegeben werden soll), daß so eine "one fits all"-Lösung (oder auch "der Arsch paßt auf jeden Eimer") schon ziemlich "mutig" ist und die Argumentation, daß Du irgendetwas nicht brauchst, führt mich immer wieder zu der Frage zurück, was das "Freetz-NG" nun eigentlich (nach Deiner Ansicht) für eine Veranstaltung sein oder werden soll.

Ist das nur Deine eigene Vorstellung davon, was andere mit Freetz anstellen sollen/dürfen und wenn die jemandem nicht paßt, hat er halt Pech gehabt? Oder soll das tatsächlich die Konkurrenz zum originalen "Freetz" sein und wenn das so ist, hast Du da schon sehr oft eine Begründung gesehen, die "brauche ich selbst nicht, also braucht es auch kein anderer" lautete?

Ich rede hier natürlich von "normalen Zeiten" und anderen Benutzern - daß Dir schon "Vorschläge" abgelehnt wurden (die Du aber auch gerne auf Deine eigene, unnachahmliche Art "eingereicht" hast - üblicherweise in der Art: "Die kann man sich ja von da und da zusammensuchen, wenn man sie haben will." und eher nicht als Teil des "normalen Workflow", der eben aus einem Branch und einem Pull-Request besteht), ist mir genauso bekannt wie der Umstand, daß auch einige meiner Vorschläge mit der Begründung abgebügelt wurden, daß man das alles auf irgendwelchen (manchmal auch reichlich obskuren) alternativen Wegen auch erreichen könnte und das niemand "leichter" brauchen sollte und wenn es nicht anders geht, dann braucht das auch niemand.

Ich verstehe halt die Philosophie hinter einem "Ich baue alles aus oder lasse alles weg, was ich selbst nicht brauche oder noch nie benutzt habe (egal, ob das schon da ist und von jemandem benutzt wird)." nicht so ganz - zumindest nicht, wenn man andere zur Benutzung des Forks animieren wollte. Wenn der tatsächlich nur zu Deinem privaten Vergnügen dienen soll und Dich ansonsten die Bedürfnisse der anderen Interessenten so vollkommen kalt lassen, warum gibt es dann immer noch so viele Pakete? Oder warum werden dann immer noch so viele Modelle unterstützt?

Die wirst Du ja sicherlich nicht alle selbst einsetzen - wo ziehst Du also die Grenze zwischen "Brauche ich nicht, also auch kein anderer." und "Wenn's das schon mal gibt, kann man es ja auch 'anbieten', falls es jemand benutzen will."? Das macht - zumindest auf mich - immer einen etwas unausgegorenen und eher sprunghaften Eindruck ... so als hättest Du gar keinen "Plan" und würdest das immer "frei Schnauze" und eher nach Lust und Laune entscheiden und wenn etwas nicht auf Anhieb mit einer neueren AVM-Firmware funktioniert, fliegt es auch schon mal komplett raus, anstatt daß Du dann hinterher wieder versuchst, das doch noch irgendwie (und sei es auf anderem Wege) zu realisieren.

Hier meine ich jetzt tatsächlich speziell die "debug.cfg" - die gab es praktisch seit Menschengedenken in Freetz (und davor auch schon) und eine der ersten Aktionen, nachdem die von AVM ausgebaut wurde, war es, diese zu reaktivieren. Ich würde es ja noch verstehen, wenn es jede Menge anderer "Hooks" gäbe, wo sich der Benutzer selbst in die Abläufe einklinken kann - aber m.W. gibt es da nur drei Stellen (rc.custom, onlinechanged, autorun.sh) und das war's dann aber auch schon.

Wobei "autorun" ja nun wirklich eine galoppierende Sicherheitslücke ist, die (wenn jemand tatsächlich so mutig/verschusselt ist, diese Funktion zu aktivieren) einfach nur ein Traum für jeden Angreifer ist, der für 15 Sekunden unbeobachtet in die Nähe der FRITZ!Box gelangt - das ist fast so schön, wie der USB-Stick mit dem Keylogger, den man nur hinten an den PC stecken muß. Wenn ich es nicht falsch lese, wird das auch wieder automatisch mit ausgewählt, wenn man sich für "UDEVMOUNT" oder "FREETZMOUNT" entscheidet und ich kann in der CGI-Seite beim besten Willen auch nichts finden, was den (unbedarften) Benutzer jetzt noch einmal nachdrücklich auf die Gefahren aufmerksam machen würde, die sich daraus ergeben. Hätte irgendein Hersteller so etwas in seiner Firmware, würde man ihn heutzutage dafür vermutlich kreuzigen.

Aber so etwas ist dann eben automatisch in Freetz enthalten (UDEVMOUNT ist ja auch als Standard "an") und wartet nur auf den (uninformierten) Klick durch den Benutzer - während die (im Vergleich dazu wieder deutlich schwerer für einen Angreifer zugängliche) "debug.cfg" entfernt wurde. Wenn sich dann jemand dazu entschließt, Aktionen aus der bisherigen "debug.cfg" in eine "autorun.sh" zu packen, weil die wenigstens beim Systemstart auch irgendwann mal ausgeführt wird, wenn das Volume gemountet wird, ist da die gesamte Box schneller wieder offen wie ein Scheunentor, als man es für möglich hält.

Aber laß Dir von meinen "Einwänden" auch nicht die Laune verderben ... immerhin gibt es mit Freetz-NG wenigstens ein Projekt, was überhaupt noch weiter betreut und angepaßt wird. Nur wirst Du (nach meiner Überzeugung) eben auch schnell Vertrauen potentieller Interessenten verspielen, wenn das alles so planlos und "spontan" wirkt.

Diejenigen, die eigentlich Freetz/Freetz-NG einsetzen wollen, um ihren Router besser abzusichern und ein Schutzniveau zu erzielen, welches über das der AVM-Firmware hinausgeht, die wollen sicherlich keine Firmware, bei der sie nie ganz sicher sein können, ob da nicht doch ein riesiges Loch in der Firmware klafft (nicht mal absichtlich als Backdoor, sondern einfach durch zu wenig durchdachte Aktionen und spontane Änderungen). Es macht jedenfalls nur sehr begrenzt Sinn, wenn man auf einer FRITZ!Box, die ansonsten in puncto "Security" eher eine Blackbox ist und wo man sich nicht sicher sein kann, wie gut die abgesichert ist, jetzt sein "tor"-Paket installiert und dann der Meinung ist, nun würde man sicherer/anonymer im Internet unterwegs sein können.
 
Das ist doch Unsinn was du schreibst und ich bin mir sicher dass du das genau weisst. Es verunsichert nur andere.

Ein ifconfig-up aktiviert das Netzwerkinterface. Es wird dadurch nicht:
- Ein Netzwerkkabel in die Netzwerkkarte gesteckt (sollte jedem klar sein)
- Ein Wlan Netzwerk gestartet (sollte auf jeden Fall dir klar sein)

Daher gibt es keine "Sicherheitslücke", da das Aktivieren vom Wlan wie eh und je Sache jedes einzelnen ist. Das "wlan" Interface ist sowieso auf einer (fehlerfreien) Fritzbox aktiviert, ob Wlan eingeschaltet ist oder nicht

Wenn du die debug.cfg unbedingt haben willst, mach es! Der alte Patch ist zum supervisor von 7.2x nicht kompatibel und solange den niemand/du anpasst gehts halt nicht
 
Ein Netzwerkkabel in die Netzwerkkarte gesteckt
Da hat Dich jemand gnadenlos verarscht ... bei einem WLAN-Interface gibt es gar kein Kabel (höchstens vielleicht eines zu einer externen Antenne, aber das ist etwas anderes) - und selbstverständlich wird ein WLAN-Interface ausschließlich "per Software" aktiviert, solange da nicht noch ein Schalter drangepappt ist, der das "physisch" deaktivieren kann.

Das ist doch Unsinn was du schreibst
https://git.busybox.net/busybox/tree/networking/ifconfig.c#n549 - "xioctl" für das entsprechende Interface.

https://git.busybox.net/busybox/tree/libbb/xfuncs_printf.c#n559 - Der "echte" Aufruf von "ioctl" in der BusyBox-Library.

https://github.com/torvalds/linux/blob/master/net/core/dev.c#L1544 - Hier landet ein "IFF_UP" als "ioctl" und hier wird auch die "notifier chain" nach einer Status-Änderung benachrichtigt, wo Du keinen Schimmer hast, wer da alles drin hängt (bis zum AVM-"wland") und wie der jeweils reagiert.

https://github.com/torvalds/linux/blob/master/net/core/dev.c#L1491 - Hier wird der Status des Interfaces geändert, wobei Punkt 1 meiner Liste oben in den "privaten Funktionen" für das Interface erfolgt (ops->ndo_open()).

https://github.com/torvalds/linux/blob/master/net/core/dev.c#L8319 - Adressen werden zugewiesen - das geht beim generischen "set_rx_mode" los und zieht sich bis in den jeweiligen Treiber, wo dann wieder "private" Funktionen über die "net_device_ops"-Struktur benutzt werden, u.a. für ".ndo_set_rx_mode" und wo dann vom jeweiligen Treiber Adressen (mindestens auf L2 - für den Empfang eintreffender Daten) aktiviert werden.

https://github.com/torvalds/linux/blob/master/net/core/dev.c#L1458 - Du weißt gar nicht genau, wer hier alles in der "notifier chain" hängt und wie jeder der Empfänger auf die Message reagiert.

- Das Scheduling wird auch geändert.

... und so geht das noch eine Weile weiter.

Du weißt halt gar nicht genau, was da alles in den AVM-Daemons in Reaktion auf "netlink"-Messages passiert und daß - im Gegensatz zu einer 7490, wo eben das zweite FRITZ!OS alles das verwaltet, was "hinter" dem Interface "wasp" noch an physikalischen Interfaces steckt (hier ist das "wlan" ja am Ende nur ein VLAN über "dev wasp", wo die anderen WLAN-Interfaces mit anderen VLAN-IDs auch zu finden sind) - es bei anderen VR9-Modellen mal gar kein "wlan"-Interface gibt (solange der Benutzer nicht selbst eins eingerichtet hat, was er über die Bridge-Konfiguration in der "ar7.cfg" auch hinbekommen sollte), soll ja offenbar sogar Dein eigener Test hier: https://github.com/Freetz-NG/freetz-ng/blob/master/make/mod/files/root/etc/init.d/rc.mod#L61 prüfen.

Da mußt Du Dir aber trotzdem die Frage gefallen lassen, ob Du das JEMALS getestet und richtig durchdacht hast - wenn Du das schon so kühn auf andere Modelle erweiterst, für die es (bei diesem Punkt) bisher (nach allem, was ich selbst dazu bisher gefunden/gelesen habe, aber Du kannst natürlich gerne entsprechende Quellen aufzeigen, die ein "alle VR9-Modelle" erforderlich machen) noch gar keine Beschwerden in dieser Richtung gab. Denn auch wenn bei einer 7412 mal kein "wlan" existiert (weil die nur ein einzelnes Band unterstützt und deshalb "ath0" auch gleichzeitig alles wäre, was da als "wlan" verfügbar ist), woher weißt Du (ohne entsprechende Prüfung), daß es bei anderen VR9-Modellen, die über mehr als ein WLAN-Interface verfügen, nicht auch ein "wlan"-Device gibt, das die beiden Bänder zusammenfaßt?

Wenn solche Probleme am Ende durch "pures Glück" nicht auftreten (weil es vielleicht gar kein weiteres VR9-Modell mit "dual WLAN" gibt, was nicht mit dem QCA995X arbeitet), dann hat das mit vorherigem Überlegen eben auch nichts zu tun und wenn die Kombination aus "VR9", "06_9X_MIN" und "07_1X_MAX" das "nebenbei" auf die richtigen Modelle beschränken sollte, ist das genauso "Dusel" bzw. für alle anderen "verwirrend" - und hinterher dann zu behaupten, weil es funktioniert, hätte man sich das vorher schon genau überlegt, ist ja wohl auch eher ein Lacher.

Daß der "dsld" von AVM (der ja bekanntlich auch den Rest der Interfaces verwaltet und aus den Informationen in der "ar7.cfg" die jeweils gewünschte Konstellation zusammenstellt) auf die entsprechenden "netlink"-Messages bei einem "ifconfig ... up" reagiert, kann man sich wieder ganz einfach selbst ansehen - dazu muß man nur auf die Console schauen, nachdem ein solches Kommando den Zustand eines Interfaces geändert hat (zweimal "up" oder "down" ändern ihn nicht). Und die These, daß eine solche Aktion dann bei geeigneter Konfiguration für die AVM-Komponenten zu einer vom Besitzer eigentlich nicht gewünschten Konfiguration führen kann, ist damit auch nur schwerlich von der Hand zu weisen, solange Du nicht über die Quelltexte für diese AVM-Daemons oder "Insider-Informationen", was da tatsächlich passiert, verfügst. Hast Du die? Ich vermute mal: Nein.

Eine Alternative wäre es dann, wenn man es zuvor durchdenkt und testet. Hast Du das getan? Auch hier vermute ich: Nein - wie solltest Du auch (zumindest den Teil mit dem "testen"), wenn Du die Technik dafür nicht hast. Bei Deiner 7490 kann das nämlich etwas vollkommen anderes sein, als bei einer 3390 - die hat auch VR9 und Dual-WLAN (damit "rate" ich mal, daß es auch ein "wlan" geben könnte - für Sicherheit müßte man das eben wieder prüfen) und nur die Tatsache, daß es von AVM (bisher?) da keine Version zwischen 06.9x und 07.1x gibt, "rettet" das hier.

Aber solche "impliziten" Bedingungen sind nicht nur deshalb verpönt, weil man das "wissen" muß und andere da erst mal rätseln. Wenn AVM tatsächlich eine 06.9x für die 3390 brächte (ich weiß, daß das mehr als unwahrscheinlich ist, aber das ist damit nicht zwangsweise "ausgeschlossen"), dann wüßtest Du selbst nicht mehr, daß Du es an dieser Stelle noch einmal kontrollieren müßtest, anstatt einfach nur die Quelle für die Firmware und die Versions-Variablen (in den Freetz-Templates) zu ändern.

Ich habe - wenn Du das noch einmal genau liest - auch gar nicht behauptet, daß es tatsächlich so sein müsse, daß man damit ein Sicherheitsproblem eingebaut hat (und sei es nur bei bestimmten Konfigurationen). Mein Frage war:
Hat tatsächlich mal irgendeiner darüber nachgedacht
und dann kam ein mögliches Szenario (da gibt es durchaus ja noch andere), was man - nach meiner Überzeugung - durchdenken und ggf. eben auch testen hätte müssen. Und wenn da niemand drüber nachgedacht hat bzw. sofern sich Deine Überlegungen auf die Überzeugung beschränken, daß ein "ifconfig ... up" kein WLAN-Netzwerk startet (ich nehme mal an, da willst Du auf die anderen Einstellungen, die dafür jeweils noch gesetzt sein müssen, hinaus), dann muß die Antwort eben auch lauten: Nein (ggf. noch um ein "interessiert mich auch nicht" ergänzt).

Nur spielt Deine Überzeugung, daß ein "ifconfig wlan up" generell "ungefährlich" wäre, spätestens dann keine Rolle mehr, wenn Du es nicht für nötig hältst, das auch zu überprüfen. Oder hast Du Dich jemals überzeugt, zu welchem Zeitpunkt der "hostapd" auf dem WiSoC die Konfiguration tatsächlich setzt? Solange die nicht "enabled" wird, kann das zu jedem beliebigen Zeitpunkt schon erfolgt sein - dann ist Dein "wird kein WLAN-Netz gestartet" für die Tonne, falls der "dsld" aus einem "ifconfig wlan up" seinerseits einen Auftrag an den "hostapd" auf dem WiSoC generiert, einfach nur noch ein ENABLE hinterher zu schicken. Selbst wenn es also "sicher" sein sollte, gehört da doch noch die Kontrolle (und nicht nur die "Vermutung") dazu und das wird wohl nur mit einem Blick in die Protokolle der WiSoC-Version gehen.

Und auch Dein:
Das "wlan" Interface ist sowieso auf einer (fehlerfreien) Fritzbox aktiviert, ob Wlan eingeschaltet ist oder nicht
kann ja schon deshalb nicht stimmen, weil es eben dieses Interface gar nicht bei allen Modellen gibt - auch bei so einer Aussage müßtest Du also etwas differenzierter vorgehen und zumindest mal einen Unterschied zwischen den Systemen mit einem separaten FRITZ!OS (die wohl von dieser verzögerten Bereitschaft des "wasp"-Interfaces betroffen waren in den passenden FRITZ!OS-Versionen - denn man konnte das ja u.a. daran sehen, daß das "dev wlan" nicht in die "lan"-Bridge eingebunden war, was am Ende dazu führte, daß nur bis L2 die Kommunikation möglich war und kein DHCP funktionierte) und denen ohne ein solches machen.

Ich denke mal, daß Du den Kern meiner Kritik trotzdem schon verstanden hast ... es geht darum, daß Du viele ungetestete und in ihren Konsequenzen nicht zwangsweise zu Ende gedachte oder auch nur auf mögliche Seiteneffekte getestete Änderungen machst und nur mit den Schultern zuckst ("ist eben eine Developer-Version"), wenn das bei irgendjemandem zu Problemen führt. Auch hier gab es mit dem "httpsdl" für das "gettfepic.sh" doch gerade erst wieder ein Beispiel - selbst wenn das neu hinzugekommen ist als Abhängigkeit, hast Du das ganz offensichtlich eben NICHT geprüft, bevor Du Dich dazu aufgeschwungen hast, daß 07.2x jetzt auch "supported" wäre.

Da kriegt dann auch der Support für ein neu hinzugefügtes Modell mal auf die Schnelle den Stempel "Funktioniert doch!", wenn das nur ein Einzelner mal gebaut und irgendwie gestartet hat und dabei wird nicht einmal richtig "nachgehakt", was das für die Funktion generell wohl bedeuten könnte. Die Tatsache, daß ein Minimal-Image auf einer Box auch bootet, sagt ja nun absolut nichts darüber aus, wie sich das im weiteren Verlauf verhält und/oder welche Pakete dieser "Tester" da überhaupt verwendet hat. Ein schönes Beispiel waren da die 6890 und der DVB-C-Repeater ... die standen auch auf "supported", nur funktionierten eben die entscheidenden Teile der Firmware trotzdem nicht, weil beim Nachladen von LKMs ein Problem bestand, das aber das generelle Booten nicht verhinderte.

Da steht dann aber auch nicht länger ein passendes Label (z.B. "EXPERIMENTAL") an der Unterstützung solcher Modelle (oder eine Erklärung, worauf sich die Unterstützung genau bezieht) - der geneigte "Benutzer" (über die "Rollenbeschreibung" haben wir uns ja auch schon unterhalten) kann gar nicht mehr erkennen, wie verläßlich diese Aussage am Ende tatsächlich ist und worauf sie wirklich beruht.

Vielleicht schaffst Du es ja irgendwann doch mal zu beschreiben, wie Du selbst das Freetz-NG eigentlich positionieren möchtest im Bezug auf diejenigen, die ihrerseits ein Interesse daran hätten, das bei sich zu benutzen - aber eben ohne dabei ihrerseits (wenn's schlecht läuft) nur Zeit zu verschwenden, weil das alles nur "oberflächlich" getestet ist und sie schon mit einem erheblichen Risiko rechnen müssen, daß ihre eigene Konfiguration so gar nicht zu der passen könnte, auf der Du das selbst getestet hast.

Wenn Du auch dafür ein Beispiel willst, denke einfach mal an die kürzlich ausgeführten Änderungen bei "nano", "ncurses" und "ncursesw", wo auch erst noch einmal "nachgearbeitet" werden mußte. Das mag für eine "Developer-Version" vielleicht wirklich "normal" sein - nur gibt's bei Dir eben auch keine andere und der (nicht ganz so firme) Benutzer hat gar keine echte Chance, eine wirklich stabile Version zu benutzen.

Denn auch wenn man mit dem originalen Freetz nicht immer zufrieden und mit den Machern dort nur selten einer Meinung war - eines muß man trotzdem attestieren: Es gab deutlich weniger "halbgare" Änderungen und dann kann man vielleicht sogar (auch wenn's alles andere als ideal und für die meisten Entwickler, die das beruflich machen, wohl auch ziemlich unprofessionell ist nach deren Ansicht) mit so einem einzelnen Branch für die "Öffentlichkeit" arbeiten.

Ich ziehe den Hut vor Dir, daß Du es geschafft hast (für mich durchaus auch nach einigen Irrungen und Wirrungen hinsichtlich der verwendeten Werkzeuge und Plattformen, aber das ist Geschichte - selbst wenn es zur "historischen Wahrheit" gehört), einige "liegengebliebene" Änderungen in Freetz so umzusetzen, daß andere das benutzen können - und ich bin immer noch der Meinung, daß das "im Team" und mit etwas Planung und Verteilung von Aufgaben und Verantwortlichkeiten besser gegangen wäre. Gerade im Hinblick auf die (effektive) Zusammenarbeit mit anderen sehe ich auch bei Freetz-NG noch jede Menge verschenktes Potential - denn daß sich bei den eher chaotischen Änderungen keiner findet, der über "version bumps" oder andere Kleinigkeiten hinaus da mitarbeiten will, kann ich auch wieder sehr gut verstehen.

Und auch wenn Du das hier:
Wenn du die debug.cfg unbedingt haben willst, mach es!
für eine passende Antwort hältst ... es ist keine. Denn daß ich selbst gar kein Freetz verwende und auch kein Freetz-NG verwenden werde, ist eine mittlerweile schon oft wiederholte Feststellung. Ergo brauche ich da auch keinen Support für eine "debug.cfg" - es ging mir in diesem konkreten Punkt (und wer lesen kann, wird das auch erkennen können) ausschließlich darum, daß Du (ohne Not, denn die Aussage, daß es an der Umstellung auf "supervisor" final scheitern würde, ist ja eher Kohl) eine über Jahre existierende Funktion deaktiviert hast (wovon der Benutzer auch erst einmal gar nichts bemerkt) und sie jetzt nach Deiner Ansicht komplett wegfallen soll und das dann eben erneut mit einem "weil ich es nie gebraucht habe" und nicht, weil es andere nie benutzt hätten (oder ich habe Deine Frage dazu, die sich an die (ehemaligen) Freetz-Benutzer richtete, nur überlesen).

Ich denke, wir sind beim "gegenseitigen Verständnis" mal wieder an einem toten Punkt angekommen, wo weiterer "Austausch" dann nicht erwarten läßt, daß bei Dir oder bei mir "Einsicht" einkehrt und man sich der Meinung des Gegenüber anschließt. Daher sollten wir das hier auch beenden - es bringt uns beiden nichts und wird immer mehr zum "täglichen Meeting" (oder zur täglichen Videokonferenz), was zwar auch ab und an mal ganz sinnvoll sein mag, um sich abzustimmen, aber wenn die Standpunkte ohnehin so unterschiedlich sind, nur in Zeitverschwendung ausartet. Ich denke, wir haben beide Besseres zu tun.
 
Zuletzt bearbeitet:
Hab ich mit meiner 7490 um die es hier geht getestet. Und du?

Code:
$ cat /sys/class/net/wlan/operstate
up
Und das obwohl Wlan seit Systemstart nicht aktiviert war, ohne wlan-up Patch natürlich.

Unterstell mir doch nicht ständig irgend einen Unsinn! Die debug.cfg soll nach NICHT meiner "Ansicht komplett wegfallen", auch wenn du es noch so oft behauptest. Ich hab einfach keine Lust das zu machen weil ich es nicht brauche. Ausser dir braucht das auch niemand. Eigentlich du selbst ja auch nicht....?!
Mach es also kompatibel mit der 7.2 und dann kannst du es benutzen falls du es brauchst
 
Vielleicht gehst Du ja doch erst mal auf meine Frage ein, wie Du das "Freetz-NG" selbst verstanden wissen willst?

Denn davon hängt natürlich auch in erheblichem Umfang ab, wie weit das am Ende ein Projekt "für Dich" (und Deine Bedürfnisse) ist oder ob das tatsächlich ein Projekt "für andere" sein soll, das die nicht nur (dank Deiner gnädigen Erlaubnis und weil Du die Änderungen veröffentlichst) "mitbenutzen", sondern auch die Erwartung hegen dürfen, daß es sich für sie lohnt, ihre Zeit in die Benutzung von Freetz-NG zu investieren (auch wenn ihnen sonst nur bleiben sollte, auf FRITZ!Box-Modifikationen in diesem Umfang zu verzichten) oder ob sie damit rechnen müssen, daß bei der nächsten "Schwierigkeit" (und die "debug.cfg" ist auch nur ein Beispiel - aber eben ein schönes, weil der Abschied davon in Freetz-NG für FRITZ!OS ab 07.19 schon ähnliche Dimensionen hat, wie der Abschied vom "telnetd" in der originalen Firmware ... es geht eine Funktion, die über Jahre hinaus verfügbar war und die nicht einmal das größte (Sicherheits-)Risiko in der Firmware darstellt) dann erneut eine "Wundertüte" auf sie wartet.

Für mich schwankst Du immer zwischen "ist nur für mich" und "warum nehmt ihr nicht einfach alle Freetz-NG" hin und her - ist es tatsächlich so schwer, sich da auf eine eindeutige Haltung festzulegen?

Die debug.cfg soll nach NICHT meiner "Ansicht komplett wegfallen", auch wenn du es noch so oft behauptest. Ich hab einfach keine Lust das zu machen weil ich es nicht brauche. Ausser dir braucht das auch niemand.
Ich bin aber wohl auch zu blöd, den Unterschied zwischen meiner Feststellung, daß die "debug.cfg" (beim derzeitigen Stand) komplett entfallen ist und Du keine Notwendigkeit siehst, das zu ändern und Deiner Aussage oben zu verstehen ... daher entschuldige ich mich mal für den Unsinn und die "Unterstellung", daß das weggefallen ist: https://github.com/Freetz-NG/freetz-ng/blob/master/config/ui/patches.in#L1693 und Du nicht die Absicht hast, das Deinerseits wieder einzubauen.

So, jetzt ist aber (für mich) tatsächlich das Ende erreicht - ich klinke mich hier aus und widme mich anderen Aufgaben. Du kannst natürlich gerne noch fortsetzen - die erwähnte "Positionierung" von Freetz-NG könnte ja den einen oder anderen am Ende doch interessieren (bzw. meine Frage danach und Deine Antwort darauf).
 
  • Like
Reaktionen: Master SaMMy
Genau ICH sehe keine Notwendigkeit MEINE Zeit in eine Funktion (debug.cfg) zu stecken die ICH und sonst auch NIEMAND braucht.
Wenn DU es gerne hättest, mach es. Ich bin sicher dass du das kannst und dafür keine Hilfe brauchst
Das war jetzt bestimmt das 10. mal
 
Frage an die wissenden, speziell aber an @fda89:
Kürzlich gab es eine Änderung die das auslösen des Watchdogs umgeht, indem die rc.mod und rc.custom asynchron gestartet wird und "Disable AVM watchdog" setzt nun die Developer-Option voraus.
Ich habe kürzlich einen frischen Checkout gemacht, paar Pakete angewählt und Ergebnis war, dass die Box nach ca. 2 Minuten rebootet hat. Erst durch "Disable AVM watchdog" im Developer-Modus konnte das beheben. Meine Frage daher: Sollte das korrekt funktionieren? Wollte das klären bevor ich weiter mit einem Minimalimage teste. Weil Issue #28 ist noch offen was ja dann eigentlich gelöst sein müsste?
 
Zuletzt bearbeitet:
Ich bin zwar nur am Rande angesprochen ... aber mein Kenntnisstand wäre, daß das Watchdog-Problem auf den "untrustedd" herunter gebrochen werden konnte und es z.Zt. als Workaround auch ausreicht, nur diesen (AVM-)Daemon zu entfernen: https://github.com/Freetz-NG/freetz-ng/blob/master/patches/scripts/570-remove-untrustedd.sh

Das kommt mir zwar immer noch eher als "Holzhammer-Methode" vor (weil es ja für den Workaround vermutlich schon ausreichen würde, den Start des Daemons einfach nur zu verhindern), aber es bringt wohl erst einmal einen sichtbaren Erfolg.

Wie weit sich dann meine wilden Spekulationen hinsichtlich "low on entropy" als Ursache für die Probleme tatsächlich ausmachen lassen, ist im Moment wohl ebenfalls noch offen - zumindest gibt (oder gab) es offenbar Unterschiede an dieser Stelle, was Freetz-NG-Images und die originale Firmware von AVM anbelangt: https://github.com/Freetz-NG/freetz-ng/issues/120

EDIT:
Ich sehe gerade, daß Dir ja "über Bande" auch auf GitHub schon geantwortet wurde: https://github.com/Freetz-NG/freetz-ng/issues/28#issuecomment-752715033 - so langsam geht mir dieser ganze Kindergarten so was von auf die Nüsse ... ich denke mal, ich verabschiede mich dann offiziell als potentieller Ansprechpartner, wenn es um Probleme mit Freetz oder Freetz-NG oder generell Modifikationen der AVM-Firmware durch einen dieser Forks geht. Ich bin dann also raus ...
 
Hallo NDiPP,
dann bin ich zu blöd dafür :-(.
Ich hatte mir gestern ein frisches Freetz-NG ausgescheckt und dann davon ein Image für meine 7590 erstellt. Nach dem einspielen habe ich immer noch "Reboots". Mein Workaround war erstmal "echo disable > /dev/watchdog".
Wie kann ich erkennen, ob das Script beim erstellen des Image sauber ausgeführt wird?
Otto
 
EDIT:
Ich sehe gerade, daß Dir ja "über Bande" auch auf GitHub schon geantwortet wurde: https://github.com/Freetz-NG/freetz-ng/issues/28#issuecomment-752715033 - so langsam geht mir dieser ganze Kindergarten so was von auf die Nüsse ... ich denke mal, ich verabschiede mich dann offiziell als potentieller Ansprechpartner, wenn es um Probleme mit Freetz oder Freetz-NG oder generell Modifikationen der AVM-Firmware durch einen dieser Forks geht. Ich bin dann also raus ...
@PeterPawn
Was hällst du davon die untrusted zu entfernen?
 
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.