@splenditnet:
modfs ist geändert ... so schön es auch ist, daß Du den Fehler nachgestellt und gefunden hast, für die Zukunft bleibt es dabei, daß
ich so etwas nur mit Debug-Log anfassen werde ... dort wäre dann im Klartext abzulesen gewesen, daß eben die falschen Brandings ermittelt wurden, weil durch den fehlenden Parameter der Pfad ausgehend vom Wurzelverzeichnis des aktiven Systems benutzt wurde für das Auslesen - die Aussage mit dem "Leerstring" bei den Brandings (aus
#482) sollte aber auch falsch sein. Ein fehlender Wert für "rootdir" in "get_target_brandings" sollte aus dem Pfad "$rootdir/etc" beim "find" den Pfad "/etc" machen und dann sollte das Ergebnis die Liste der Brandings des aktiven Systems sein und kein Leer-String. Oder habe ich Dich da falsch verstanden? Eigentlich spricht aber auch die Fehlermeldung (die ja das
erwartete Branding "1und1" bzw. "avm" ausweist anstelle des richtigen "avme") eher gegen eine leere Zeichenkette bei den Brandings.
Dieser Fehler konnte damit nur dann auftreten, wenn die Systeme unterschiedliche Brandings haben ... wie es der falsche Aufruf geschafft hat, auf dem Weg aus dem gui_boot_manager_v0.2 (da stammte die Funktion "get_brandings" ja 1:1 her, inkl. ihres Aufrufs (da noch mit "rootdir" als Parameter) und da war es noch richtig) in das "modfs"-Skript (zum Vermeiden von Redundanzen, weil eben seit der "Multi-Branding"-Tauglichkeit nicht mehr nur das gerade aktive Branding modifiziert werden soll, wie es z.B. bei gui_0.1 noch der Fall war) den ersten Parameter zu verlieren, ist mir zwar ein Rätsel, aber das muß irgendwo hier passiert sein:
https://github.com/PeterPawn/modfs/...45d4#diff-da17bd5626b9eaa7559b2ddb10465dfbL30
"mod_default_show_mac" fasse ich trotzdem nicht an, da habe ich #1 in diesem Thread dahingehend geändert, daß es erst ab 06.50 anwendbar ist. Wenn man hingeht und für jede Labor-Version von AVM einen spezifischen Patch einbaut, wird man seines Lebens nicht mehr froh ... auch aus diesem Grund hatte ich ja eigentlich sämtliche GUI-Anpassungen (irgendwo vorher in diesem Thread mal geschrieben) auf die Release-Version verschoben. Da die deutsche Release-Version bereits erschienen ist (und sogar schon ein weitere Update dieser Version), habe ich den Patch eingebaut - allerdings wohl die Tabelle in #1 etwas zu kurz gefaßt, weil ich bei der (bisherigen) Unterscheidung mit 06.36 als "Grenze" dort mehr auf den Unterschied "Kernel 2.6.32 vs. 3.10.73" abstellen wollte und eher nicht damit angedeutet werden sollte, daß GUI-Patches für das "responsive design" ab 06.36 funktionieren müssen. Das war auch in der deutschen Version nach dem Erscheinungsdatum der internationalen Beta noch einigen Änderungen unterworfen, bis es dann mit der Releaseversion einen halbwegs stabilen Stand erreichte.
Daß die internationale Version der deutschen inzwischen so weit nachhängt (die ist irgendwann von Anfang Nov. 2015, wenn ich mich richtig erinnere), ist zwar schade ... aber ich würde fast jede Wette eingehen wollen, daß in der nächsten Labor-Version für die 7490i das dann schon wieder so aussieht, wie in der 06.50/06.51 ... wenn man da den Änderungen hinterherrennen wollte, käme man zu nichts anderem mehr. Also gilt für die GUI-Patches (zumindest für meine), daß sie erst gegen eine Release-Version funktionieren. Wenn jemand unbedingt eine Labor-Version patchen will, muß er/sie das selbst irgendwie regeln.
@koy:
Die Liste der Brandings wird anhand der Unterverzeichnisse von /etc/default.$CONFIG_PRODUKT gebildet, wo jedes Branding sein eigenes Unterverzeichnis haben sollte ... wobei es mit dem "default"-Verzeichnis gerade auch bei der internationalen Version nicht ganz so einfach ist, da das richtige zu finden ... denn dort, wo die deutsche Version nur ein "default.049" parallel zu dem anderen Verzeichnis liegen hat, sind es bei bestimmten internationalen Versionen jede Menge weitere - daher werden alle "default"-Verzeichnisse, die nach dem Punkt nur noch Ziffern haben (für die LKZ) dort noch ausgesiebt. Zwar könnte man für die aktive Box wieder auf $CONFIG_PRODUKT zurückgreifen, dann funktioniert das aber beim Cross-Modifizieren nicht mehr oder man sucht sich "CONFIG_PRODUKT" erst aus der rc.conf im Image. Das ist am Ende alles aufwändiger als einfach davon auszugehen, daß das gesuchte Verzeichnis nach dem Punkt mindestens einen Buchstaben im Namen hat.
Und nochmal @splenditnet:
Das mit den anderen Änderungen hast Du falsch verstanden ... den Patch für LAN2LAN-VPN-Anzeige mache ich schon selbst (der DynDNS-Status ist mir persönlich egal, der wird bei mir ohnehin alle fünf Minuten aktualisiert als "
alive"-Signal) und es war keine "Aufforderung", den irgendwie anzubieten ... es sollte im Gegenteil verhindern, daß diese Arbeit doppelt gemacht wird.
@eisbaerin:
Habe ich nie so genau ausgemessen bei der 7490, das letzte Mal ist schon etwas her und war bei der 6360 - ich weiß nicht genau, wann die LEDs bei "led_off" in der ar7.cfg beim Systemstart abgeschaltet werden (ich rate mal und sage, beim Start des "ctlmgr"), aber da dürften dann Statusanzeigen der DSL-Synchronisation auch schon unter den Tisch fallen und die hätten einige (u.a. auch ich) eben noch gerne gesehen, bevor es zappenduster wird - das ist ja auch nur eine zusätzliche Zeile in der led_display.lua (2 Minuten Aufwand), weil man sich um Speichern o.ä. gar keinen Kopf machen muß, denn es wird stur die "value" des ausgewählten Radiobuttons gesetzt.
@maulich:
Es geht auch mit ein paar Zeilen Shell-Code, aus dem binären Zertifikat (DER ist ja auch nur ASN.1-Speicherung und PEM ist nichts anderes als Base64-kodiertes DER) die verwendeten Koeffizienten auszulesen und dann eine passende Datei für den "dropbear" damit zu schreiben - aber das baut man dann besser gleich in den "dropbear" in C-Code mit ein. Beim SIAB ist es ja im Prinzip dasselbe, auch das ist ja angepaßt, damit es das Zertifikat der Box direkt benutzen kann. Wenn es auf der Box schon ein passendes Schlüsselpaar gibt, will ich nicht unbedingt ein weiteres erzeugen müssen ... abgesehen davon ist das eine wegfallende Konfigurationsnotwendigkeit für den "dropbear"-Service, wenn der keinen eigenen Server-Schlüssel (mit der Notwendigkeit irgendeiner Absicherung des privaten Schlüssels - der öffentliche ist ja Bummi, wie eigentlich jeder öffentliche Schlüssel und wie der Name schon sagt) verwendet. Zwar muß man sich nach wie vor überlegen, wie man das
Hinzufügen weiterer pubkeys für Auth verhindert, aber man muß nicht darüber nachdenken, wie man das Auslesen dieser pubkeys verhindert.