[Erledigt] rc.custom in image einbinden

[PeterPawn]

So wie ich dich jetzt verstanden haben tritt das Phänomen nur bei gewissen Box mit deaktiviertem DHCP-Server auf.

Das ist noch nicht gesagt ... es gibt (im verlinkten Thread in GitHub, wo ja auch @WileC etwas dazu geschrieben hat) bisher zwei Wortmeldungen, daß es bei einem eigenen DHCP-Server bemerkt wurde.

Das Phänomen, daß das Interface "wlan" (hier sind die beiden WLAN-Adapter der 7490 zusammengefaßt) nicht in der Bridge enthalten ist, die mit dem Namen "lan" eingerichtet wird (wie im Abschnitt "brinterfaces" in der "ar7.cfg" definiert), ist jedenfalls evident ... ob das jetzt so sein soll (und ggf. mit dem Mesh zusammenhängt, denn früher war es definitiv nicht so), kann man mangels Informationen ja nicht verläßlich feststellen - jedenfalls dann nicht, wenn man nur eine Box hat (wie ich) und diese nicht betroffen ist.

In den Support-Daten anderer 7490 (mit 07.01), die ich betreue, sehe ich jedenfalls das "wlan"-Interface als Bestandteil der "lan"-Bridge und da aber bei mir (gerade noch mal getestet) die WLAN-Clients auch dann keine IP-Adressen erhalten, wenn der DHCP-Server in der Box aktiviert ist (zusätzlich zum anderen, da die beide ohnehin disjunkte Netze verwalten und ich auch einfach das LAN-Kabel abziehen kann), ist wohl auch der "multid" nicht direkt (und gesondert) an das "wlan"-Interface gebunden, sondern auch eher an "lan" und dann braucht wohl auch dessen DHCP-Server den Eintrag in der Bridge für die reibungslose Funktion.

Ich würde da trotzdem nichts fest ins Freetz integrieren (nicht mal als Workaround), weil es (a) das Problem nur zukleistert und damit aus dem Bewußtsein der Leute verschwinden läßt, es (b) wohl nicht bei allen auftritt (was ich auch wieder belegen kann) und (c) dann irgendwelche "Spezialkonfigurationen" (man kann ja auch von Hand die Bridges in der "ar7.cfg" konfigurieren) erst recht in Probleme kommen könnten (auch wenn das nur Theorie ist). Außerdem verbaut man damit dem "normalen Freetz-Benutzer", bei dem das auch ohne dieses zusätzliche Kommando funktioniert, jede weitere Test- und Vergleichsmöglichkeit, wenn das "zwangsweise" beim Start ausgeführt würde.

Die passende Switch-Konfiguration (und die daraus abgeleitete Bridge-Konfiguration) wird jedenfalls vom "dsld" gesetzt ... die Funktionen unterhalb von "avm/cpmac" werden wohl vom "kdsldmod" aus genutzt (ist halt "closed source" und nur schwer bis ins Detail zu durchschauen). Die eigentliche Frage für mich wäre, wie es bei anderen aussieht mit der Bridge (konkret: ob es auch Installationen gibt, wo das funktioniert, obwohl "wlan" nicht in der "lan"-Bridge ist) und wenn das so ist, worin sich diese Konfigurationen von meiner (bzw. von anderen mit dem Problem) unterscheiden. Ich kenne bisher nur die Fälle:

- "wlan" ist in der "lan"-Bridge und es funktioniert
- "wlan" ist nicht in der "lan"-Bridge und es funktioniert nicht

Gesucht ist also die Variante "wlan ist nicht in der Bridge und es funktioniert trotzdem" ... sollte es diese tatsächlich geben.

Ich habe jedenfalls kein gesondertes IPv4-Netz nur für das "wlan" (auch wenn man das ebenfalls konfigurieren könnte) und auch die Tatsache, daß das Gäste-Netz ja wohl bei allen Betroffenen trotzdem funktioniert (auch dafür gibt der "multid" ja den DHCP-Server, halt mit nicht einstellbarer Range und einem gesonderten Segment - auch in den Support-Daten nachzulesen), spricht eigentlich nicht unbedingt für ein "getrenntes Handling" des DHCP-Servers für das LAN und das Gäste-Netz (natürlich abgesehen von der anderen Range und dem anderen Interface - "guest" im Falle des Gastnetzes, anstelle von "lan").

Ich bin der Ansicht (zumindest zielen meine Nachforschungen bei der Fehlersuche in diese Richtung), daß irgendein Umstand die erneute (automatische) Konfiguration der "lan"-Bridge verhindert ... das kann meinetwegen auch der deaktivierte DHCP-Server sein, wenn das FRITZ!OS dann bei einer Abfrage der Ansicht ist, es gäbe keinen Grund für eine solche Neukonfiguration. Ich war ja zwischendrin schon beim Verdacht angelangt, die Radar-Prüfung könnte die Ursache sein ... nur habe ich mit deaktiviertem 5 GHz-Band dasselbe Ergebnis.

Anders als @WileC, bei dem das Einschalten des boxinternen DHCP-Servers das Problem auch behebt, habe ich gar kein Freetz-Image am Start ... vielleicht besteht deshalb bei mir das Problem auch mit aktiviertem DHCP-Server weiterhin. Ich verwende für diesen Test 1:1 die originale Firmware (Freetz ändert einiges beim Ablauf, damit die AVM-Komponenten nicht die Ports für die Dienste belegen können, bevor Freetz-Services überhaupt gestartet werden können) - nur die serielle Schnittstelle ist bestückt und ermöglicht den Shell-Zugriff und die näheren Untersuchungen.

Ich halte das immer noch für ein Timing-Problem - und die Frage, ob es sich unter Freetz zeigt oder nicht, sehe ich in Abhängigkeit davon, wann das "wlan"-Interface so weit bereit ist, daß es bei der letzten erfolgenden Umkonfiguration der Bridges (und des Switches) schon mit eingebunden werden kann oder nicht bzw. ob dieses Interface (was wohl auch nur eine Bridge von "ath0" und "ath1" ist) irgendwann noch einmal gelöscht und anschließend neu eingerichtet wird. Beim Löschen würde es ja auch aus der "lan"-Bridge geworfen ... wenn sich dann niemand mehr darum kümmert, daß es wieder aufgenommen wird, gäbe das genau das bei mir vorliegende Fehlerbild.

 

[WileC]

Übrigens, wegen der rc.custom gehts mir nicht um den fest definierten Eintrag eines „ifconfig wlan up“ sondern grundsätzlich um ein paar Definitionen und skriptaufrufe, die auf allen meinen Boxen (5 Stück) ausgeführt werden. Und da ich das nicht für meine Boxen nach einer Neueinrichtung oder einem „Austausch“ immer wieder neu einrichten möchte oder von einer alten, möglicherweise fehlerhaften Sicherungsdatei laden möchte, wäre die Möglichkeit eines „templates“ also einer Standard rc.custom mit gewissen vordefinierten Einstellungen super

 

[er13]

einer Standard rc.custom mit gewissen vordefinierten Einstellungen super

Feel free to implement Erwarte jedoch nicht, dass wir es für Dich machen.

 

[PeterPawn]

Ich diskutiere gerade mit @er13 die Möglichkeiten und die Notwendigkeiten einer individuellen Anpassung einzelner Images und die Möglichkeiten, solche Anpassungen auch gemeinsam für alle Images auszuführen, die aus einem Freetz-Checkout erstellt werden.

Wenn ich das richtig verstehe, ist hier eine zusätzliche "feste" Datei mit Kommandos und Einstellungen die bessere Lösung ... in eine "rc.custom", wo das dann wieder änderbar wird, muß man das ja nicht unbedingt schreiben - denn auch nach meinem Verständnis gäbe es da eigentlich nur die zwei Optionen "fest" mit der Schlußfolgerung "ab ins SquashFS-Image" und "änderbar", mit der Folge "ab in die Einstellungen, aka rc.custom". Der "Mittelweg" würde genau ein einziges Mal benötigt, nämlich bei einer neuen FRITZ!Box ohne alte Freetz-Einstellungen (und damit ohne "rc.custom") und danach niemals wieder.

Aber wenn Du so etwas unbedingt haben willst, ist es ja die einfachste Sache der Welt ... Du mußt Dir halt nur in die "rc.mod" vor der Zeile 83 eine Abfrage einbauen, ob die "rc.custom" existiert und nicht leer ist und sie entsprechend befüllen, wenn das doch der Fall ist. Als "allgemeine Erweiterung" für alle Freetz-Benutzer funktioniert das aber wohl eher nicht ... denn als nächstes stellt sich ja dann die Frage, woher dieser "Standardinhalt" der "rc.custom" bei jedem Einzelnen kommen sollte - der müßte ja dann nach Deiner Lesart auch individuell und damit beim Build anzupassen sein, sonst kannst Du Dein "template" ja auch vergessen. Da scheitert es dann aber gleich wieder ... es gibt derzeit keinen vernünftig konfigurierbaren Mechanismus, mit dem man so etwas in "mconf" eingeben könnte. Das Maximum ist eine "string" und wenn die sich in eine mehrzeilige Datei verwandeln soll, kann den Inhalt kein Schwein mehr lesen.

 

[WileC]

Deswegen dachte ich mir, man könnte eine rc.custom bereits vor dem Build ins ./build/irgendwas oder im entsprechenden Verzeichnisbaum per Skript „hinein kopieren“, das Image packen lassen und dann auf die Box laden.

Also nicht die rc.custom on the fly erstellen, sondern eine „Rohdatei“ direkt ins Build-Verzeichnis legen.

 

[PeterPawn]

Niemand hält Dich davon ab ... Du kannst ja auch ein "here document" in das Shell-Skript "rc.mod" einfügen und daraus bei Bedarf die "rc.custom" erzeugen lassen (was das ist, verrät Dir die Suchmaschine Deines Vertrauens, wenn Du es noch nicht kennst).

Nur ist das eben nichts, was sich "verallgemeinern" und vernünftig parametrieren ließe bzw. es gibt keinen offensichtlichen Grund, warum man so etwas unbedingt vor dem Build irgendwo ablegen sollte, anstatt es in einem entsprechenden Skript (entweder "fwmod_custom" oder das von mir gewünschte, zusätzliche "user hook script") während des Builds im Ausgabeverzeichnis hinzuzufügen. Genau das macht ja u.a. "fwmod_custom" ... es ermöglicht direkt beim Zusammenstellen des neuen Images das Ausführen eigener Kommandos und so eines kann dann auch die "rc.mod" so abändern, daß diese erst einmal eine "rc.custom" erzeugt, wenn es auf der Box noch keine gibt.