TODO: Firmware entrümpeln

knox

Mitglied
Mitglied seit
20 Mai 2006
Beiträge
577
Punkte für Reaktionen
0
Punkte
0
Ich habe heute mit der neuen .49 Firmware für die 7170 und einem aktuellen SVN Checkout herum experimentiert. Dabei bin ich auf gruselige Probleme gestoßen: Image too big - und das mit einer 7170 :mad:

Inzwischen hat AVM eine ganze Menge "Krempel" in die original Firmware integriert (Samba, Mediaserver, Anrufbeantworter, ...), so daß kaum noch Platz für eigene Sachen ist. Das finde ich sehr ärgerlich! Vor allem, weil beispielsweise der Samba Server alles andere als konfigurierbar ist und somit einen großen Teil seines Zwecks verliert.

Gleichzeitig sind einige, wie ich finde, vielversprechende Ansätze, "überflüssige" Dinge aus der Firmware herraus zu werfen, wieder aus dem Mod verschwunden?! (Replace Websrv, remove UPnP, ...) Das wundert mich etwas, denn ich hatte das bisher genutzt und keinerlei Probleme festgestellt.

Ich denke, wenn wir noch weiterhin so viel Spaß mit der Box haben wollen wie bisher, müssen dringend Wege gefunden werden, die Firmware zu entrümpeln. Neben dem optinalen Enfernen von UPnP, Mediaserver, Samba und Anrufbeantworter sollten aber auch so Dinge wie die Rudishell, die ja zur Zeit fest eingebaut ist, unbedingt in einen optionalen Bestandteil umgewandelt werden, damit man beim Image bauen so viel Spielraum wie möglich erhält. Wir haben keinen Platz zu verschenken. Auch nicht die 27K für haserl.

Das Motto muss also lauten: Platz, Platz - wir brauchen Platz!
 
Mit TODO meinte ich, Du könntest es in unsere TODO im SVN schreiben. ;-)

Außerdem wird Haserl nicht nur von Rudi benutzt, das kann man nicht einfach mal so eben schnell weglassen. Davon abgesehen, finde ich es lächerlich, über die sogar unkomprimiert winzige und komprimiert noch viel winzigere Rudi-Shell nachzudenken, die ein Größe-Nutzen-Verhältnis hat wie kaum ein anderer Firmware-Bestandteil, solange wir ständig Upgrades fahren auf monströs wachsende Pakete wie MC 4.5.0 nach 4.6.1.

Nebenbei gesagt, redest Du hier über Patches, die in pre15.3 für eine bestimmte Firmware momentan nicht drin sind, weil die Patches nicht mehr paßten oder das Weglassen zu Problemen führte. Das hatte ich Dir doch im Chat bereits gesagt. Wollten wir nicht mal interne Sachen intern besprechen? Du mit Deinem SVN-Schreibzugriff darfst gern mithelfen, das wieder in den Griff zu kriegen. Daß ich wenig Zeit habe, steht ja schon in meiner Signatur. In den vergangenen Wochen war Oliver ziemlich alleine, da helfen meine Mini-Änderungen und Deine Tor-Upgrades auch nicht viel.
 
Zuletzt bearbeitet:
@Off-Topic:

Ich habe ganz bewusst hier ins Forum geschrieben, weil ich mich ganz bewusst an die ganze Community wenden wollte!

Zum einen ist es eine implizite Frage danach, ob und welche Erfahrungen andere Leute mit dem Weglassen/Ersetzen von AVM Diensten gemacht habe und zum anderen ist es klipp und klar ein Aufruf, die hier im Forum versammelte Energie (Bastelwut) darauf zu lenken, die Bestandteile der Firmware abwählbar zu machen.

Tut mir ja leid, lieber Alexander, wenn ich dabei eine Deiner heiligen Kühe angesprochen habe, aber früher kam das mod ganz prima ohne haserl aus, und da kannst Du dich jetzt gerne weiter aufregen, dass ich das ausspreche. Jedes Kilobyte zählt, und da gibt es für mich keine Ausnahme.
An sonsten vielen Dank für Deine aufmunternden Worte. Das hat uns jetzt wirklich weiter gebracht. Ich würde mal sagen, Du bist mit Deiner Antwort ziemlich off-Topic geraten. Und überhaupt; bist Du nicht beruflich bedingt verhindert? Dann halt Dich doch bitte mal zurück, wenn sowieso kein sinnvoller Beitrag von Dir kommt. :groesste:

Und bitte keine weiteren Off-Topic Antworten in diesem Thread, denn ich möchte gerne ernsthaft und unvoreingenommen mit allen anderen Leuten im Forum darüber diskutieren, ob und wie man Dinge aus der Firmware weglassen kann. Alles andere gehört nicht hierher und interessiert mich auch eigentlich gar nicht. Danke.
 
@Knox vs. Kriegeax: Och nee, nicht schon wieder ....

Zum Thema: Platz sparen ist immer gut, mit meiner 4MB Box kann ich das nur bestätigen!

Bei mir gab es mit den verfügbaren "Platzsparern" wie dem Weglassen von "Websrv, USB und UPNP" bislang nur positive Erfahrung. Das auch bei neueren Firmwares zu realisieren, wenn es jetzt Probleme macht, halte ich daher für sehr sinnvoll.
Ob ich "Haserl" brauche, kann ich nicht sagen, dafür bin ich nicht tief genug in der Materie, aber die RudiShell finde ich tatsächlich fast unentbehrlich. Gerade für "Noteinsätze" ohne Telnet, vergessenen Passwörtern usw. Wenn, solte die höchstens unter "Experteneinstellungen" rausgemacht werden können.

Woran man arbeiten könnte, wären vielleicht verschiedene "Busybox-Presets" oder sowas. Dann müssten aber eventuell gewählte Pakete die Busybox-Config anpassen, damit keine benötigten Befehle fehlen. Ist das mach-/denkbar?

EDIT Ach so, weitere Ideen wäre, um innerhalb von Paketen Platz zu sparen:
- Die *_conf scripte evtl zu als Progremme zu schreiben und zu compillieren
- Durch "Ersetzungen/Shellexpansion" sparen (die openvpn-GUI z.B. würde durch Ersetzen von "document.getElementById" durch $byID einige Bytes sparen)

Jörg
 
Zuletzt bearbeitet:
Vergleich von 58.04.47 und 29.04.47 als Entrümpelungs-Ansatz?

Hallo knox,

dass die neuen AVM Firmwares immer größer werden und damit selbst auf einer 7170 bald kein Platz mehr für große Pakete wie OpenVPN ist, habe ich auch schon mit Sorge festgestellt.

Ein Ansatz für die "Entrümpelung" konnte ein Vergleich der folgenden beiden aktuellen englischen Firmware-Versionen für die 7170 sein:

Code:
Product: 	: FRITZ!Box Fon WLAN 7170
Version       	: 58.04.47
Build         	: 08.01.07
Language      	: English
Annex		: A
File Size	: 4.990 kB
            
Product: 	: FRITZ!Box Fon WLAN 7170
Version       	: 29.04.47
Build         	: 08.01.07
Language      	: English
Annex		: B
File Size	: 6.300 kB
Die Beschreibung der neuen Funktionen ist für beide Versionen exakt identisch, so dass mir unklar ist, warum die Annex B-Version um 1.310 kB größer ist als die Annex A-Version. Falls AVM hier nicht ein falsches Annex A-Image hochgeladen hat, fehlt in der Annex A-Varianten vermutlich irgendein Feature oder sonstiger Ballast. Ein Vergleich des Inhalts der beiden Images könnte vielleicht eine Möglichkeit zum Platzsparen aufzeigen.

Grüße,
DSLFritze
 
Es geht keinesfalls darum, vorhandenes komplett wegzuwerfen. Ganz im Gegenteil.

Wir müssen aber dahin kommen, dass so viel wie möglich von dem, was in die selbst zusammengestellten Firmware Images kommt, modular auswählbar wird. Und dabei liegt natürlich ein besonderes Augenmerk auf den "tollen" Neuerungen, die AVM in die Firmware eingebaut hat.

Edit: vielen Dank für die letzten beiden Beiträge, genau diese Diskussion wollte ich lostreten.
 
ui...na hier isja wieder stimmung *GRINS*
zu deinem entfernen des webservers....sowie ich weiß iss der irgndwo drin verschwunden, sowas er nicht mehr rausgeschnitten werden kann...wenn du mal schauen magst...websvr gibeet nicht mehr im image...so würde der andere replace httpd nur zusätzlichen latz verbrauchen...aber nix an mehr platz bringen.
die zwergen apps rauswerfbar zu machen...ich weiß nicht..nen gewises gerüst hatte der mod schon immer...
aber wie krieger schon so richitg erwähnte seh auch ich in monster apps wie dem mc aus meiner sicht auch keinen nährwert...er tut ja nix...vpn iss zwar auch gross, aber nicht untätig.
den mediaserver entfernen..das seh ich auch noch als tolles feature an...ich kenne nämlich niemanden der diesen stream auch hören könnte...und das wären ja mal kurz ~190 kb ;-) (wieviel macht lzma wieder wett?)
samba wiederum finde ich sehr angenehm...genauso gross wie aus dem mod, aber stabiler...wobei 1.2 mb schon nen lecker brocken wären......aber wieso nicht konfigurierbar?
die sambacontrol steht dir doch mit minifo oder vor dem modden oder hinterher von bind -o sehrwohl zur verfügung
ich sehe da eher handlungsbedarf den avm ftp zu entfernen, wenn eine alternative ausgewählt wurde...auch wenn es kaum platz schafft...

fass ich also mal zusammen:
was kann wirklich raus, ohne die box zu beeinträchtigen?
smbd mit 1,2mb (smbpaswd nochmal ~19kb)
mediasrv mit 134kb
streamer.plugin mit 122,8kb (was auch immer das iss)
ftpd mit 74kb
plus ein paar webseiten und cgi´s die dnn anfallen...
du siehst...wenn man samba drinlääst, gewinnt man nicht viel...aber wenn du das bissel gewinnen willst, dann lösch die selber...so wie ich es mit ftpd und mediasrv mache

nun bleibt auf der anderen seite rasuzufinden, was in dein image alles rein soll/muss, das er hinterher sagt es wäre zu gross?
vor allem ob da nen tools wie mc reinmüssen, die 98% der zeit nix tun...und daher wunderbar nachgeladen oder vom stick/platte kommen könnten...

hoffe ich war jetzt nicht zu offtopic für dich ;-)

edit1: das mit dem image vergleichen mach ich grad...2 doofe ein gedanke :-)

edit2: also die annex a scheint nur den halben funktionsumfang zu besitzen...allein der bin ordner iss um die hälfte kleiner...nur an binarys...722kb in annex a zu 1,4 mb in annex b...scheint aber alles mit dem minid zutun zu haben

edit3:die annex a hat keinen samba (-1.2mb)

daher abchliessend...kein samba und keine minid support...
 
Zuletzt bearbeitet:
Binarys könnte man doch auch auf Mounts auslagern. Muß man nur aufpassen, das die Start-Aufrufe erst dann gemacht werden, wenn der Mount erfolgreich erfolgt ist.

Als Beispiel: Auf der Dbox2 unter Linux wird der Samba-Server prinzipiell nur als Binary ausserhalb des Images geliefert und nur von /hdd gestartet.

Machbar ist da einiges. Und kleinere (Start-)Skripte kann man gut im Flash lassen, weil die da ja sehr gut komprimiert sind.

Möglich ist unter Linux ja sogar das Mounten einer Iso-Datei. Diese könnte irgendwo liegen und zu einem bestimmten Punkt gemountet werden, um dann immer Startbefehle an einen definierten Punkt bringen zu können.

cu
Jens
 
Also, konstruktiv, obwohl ich es ja schon einige Male erklärt habe (auch hier im Thema ansatzweise): Selbstverständlich wollen wir weiter dahin gehen, nicht benötigte FW-Bestandteile per Patch entfernbar zu machen. Aber wir reden trotzdem über eine FW-Version, für die es ja noch gar keinen DS-Mod gibt. Das meinte ich mit "intern". Das websrv-Binary wegzulassen, geht, wie von Darkyputz angedeutet, deshalb nicht, weil es in *.49 nicht mehr da ist. Der Webserver steckt im ctlmgr. Wir haben das also nicht aus Langeweile aus dem Menuconfig in der aktuellen Entwicklerversion entfernt, sondern weil es schlicht nicht mehr geht. Die anderen Vorschläge, z.B. MediaServer, sind gut, sonst hätte ich im Chat doch nicht sofort gesagt, Du solltest es ins interne TODO schreiben. Daß es hier im Forum steht, hilft nur bedingt, denn die allerwenigsten, die hier mitlesen, haben Stand heute die Entwicklerversion und noch weniger Leute dürfen in Subversion einchecken. Ich dachte, das versteht sich von selbst. Du, Mickey, als "Interner" kennst doch die To-Do-Liste im Repository und darfst sogar rein schreiben. Dort gehört sowas hin. Dann zusätzlich im Forum zu diskutieren, ist okay, aber nicht auf Basis des aktuellen Entwicklerstandes. Noch ist das Repository nicht freigegeben, und wir hatten eine bisher nicht aufgehobene Vereinbarung, die Leute im Forum nicht mit Diskussionen darüber zu verwirren, was sie gar nicht wissen/kennen können. Das ist kein böser Wille sondern wohl durchdacht. Daher hatte ich auch guten Grund, mich ein bißchen zu ärgern.

Zu Rudi und Haserl nochmal: Haserl wird auch von Backup/Restore und vom Firmware-Uploader benutzt (unverzichtbar für viele Speedport-Benutzer), nicht nur in Rudi. Klar gab es Haserl früher nicht vor Rudi, aber da gab es ja auch die anderen beiden Anwendungen noch nicht. Verstehst Du jetzt? Auch hier geht es nicht um "mein Baby", sondern um ganz sachliche Argumente. Davon abgesehen, ist Haserl LZMA-komprimiert gerade mal 9,5 KB groß und die Rudi-Shell LZMA-komprimiert 1,8 KB. Ich glaube ganz ehrlich, daß es bessere Möglichkeiten und Ansätze gibt, sich den Kopf übers Sparen zu zerbrechen.
 
Lass uns mal nicht um die paar Kilobytes zu streiten. Firmwareupdate ist ein Wort. Und nicht nur für Speedports. Ich mache die Updates seit 15.2 nur ausschließlich über ds-mod.
Viel lieber solte man die "doppelten" Pakete angehen. Ich hatte die gleichen Probleme wie knox gehabt, als ich versucht hatte "dtmfbox" in das mod einzubinden. Vom Sinn her kann "dtmfbox" den AVM-Anrufbeantworter ersetzen. Deswegen wäre es für den Fall angebracht den Anrufbeantworter rauszuschmeißen. Ähnlich mit Samba, Webserver usw. Das es mit Webserver nicht mehr geht ist natürlich schlecht, bleibt aber nichts anderes übrig.
Ich schlage mal Folgendes vor:
Man nimmt die 49-Firm auseinander und schaut, was dort grundsätzlich rauszuschmeißen möglich wäre. Die Beispiele von Darkyputz sind ein guter Anfang, aber nicht vollständig.

Und bitte keine Streitereien! Alles wird gut.

Die Frage ist nur, ob USB-Root (zumindest für die meisten Boxen) die Lösung des Problems sein könnte? USB-Sticks kosten heutzutage nichts...

MfG
 
USB-Root löst auf einen Schlag alle Flash-Platzprobleme (nicht eventuelle RAM-Knappheit, das ist was anderes), aber nicht jeder hat eine Box mit USB-Host, was wirklich schade ist. Ich habe hier unterwegs auch nur meine W701V dabei, und der fehlt ein USB-Host.

P.S.: USB-Root scheint sehr stabil zu laufen. Meine Box zu Hause (7170, allerdings noch mit 40er Firmware) sagt:
Code:
$ uptime
 13:48:16 up 33 days, 23:38, load average: 0.28, 0.15, 0.10
:D
 
Wo wir gerade bei Uptime sind? Meine FB Fon Wlan läuft schon ewig. Das war früher nicht so. Da gabs öfter mal ein Neustart...
Code:
/var/mod/root # uptime
 13:56:11 up 51 days, 15:45, load average: 0.16, 0.03, 0.01
Aber eigentlich gehts hier im Thread ja nicht um USB-Root. Wobei wir uns für die Zukunft überlegen sollten, ob wir eine Funktion für dynamische Packages auf z.B. einem USB Stick integrieren können.

Zum Thema: Leider sind die verschiedenen Komponenten der AVM Firmware sehr eng miteinander verwoben. Daher passiert es mir immer wieder, dass die Box ständig neu startet, wenn ich irgendwelche Libs entferne. Aber ich denke, dass wir trotzdem einiges rauswerfen können. Meine Vorschreiber haben ja schon die wichtigsten Punkte genannt.
Für mich wäre noch interessant zu wissen was mit Einträgen im Webinterface passieren soll, wenn die betreffende Funktion entfernt wird? Da müsste nämlich für jede Box ein Patch gemacht werden, der bei neuen Firmware Versionen anzupassen ist, was einiges an Arbeit bedeutet. Oder könntet ihr damit leben, dass ein nutzloser Eintrag im Webinterface steht?

MfG Oliver
 
also ich bin damit vollkommen glücklich wenn nur die binarys verschwinden...
mache es zwar jetzt schon selber, aber die webmenüs stören mich ja dann nicht mehr weil ich ja selber weiß was ich gekillt habe...
natürlich gefährlich für den 0815 user...
was meint ihr?
 
Oder könntet ihr damit leben, dass ein nutzloser Eintrag im Webinterface steht?

Die entsprechende Arbeit kann sich ja im Endeffetk der machen, den es auf seiner Box stört, oder? Wenn diese dann noch öffentlich dem Mod (eher den Entwicklern mit svn-Screibrecht ;-) zur Verfügung gestellt werden, dann sollte es relativ schnell eine breite Basis an Patches in Abhängigkeit der Box und der Paketauswahl geben, und alle sind glücklich.

wobei meine Meinung dazu eher in Richtung "drinlassen" tendiert. Ist zwar unsauber, aber spart Arbeit.

Wie sähe es eigentlich aus, würde man die komplette Oberfläche (AVM & dsmod) rauspatchen? Denn wenn so eine Box einmal richtig konfiguriert ist, kann man darauf ja fast ohne Schwierigkeiten verzichten. Oder lohnt sich das nicht wegen der Kompression?
 
Ich bin auch eher für drin lassen. Wenn ich mich erinnere, was für ein Alptraum es kürzlich war, den auf der 49 nicht mehr funktionierenden Remove-Help-Patch mit einem fiesen Awk-Spezialskript wieder zum Laufen zu bringen, dann weiß ich ziemlich genau, daß ich das nicht nochmal machen möchte. Klar ist aber auch, daß es immer einen Anwender geben wird, dessen Firmware gerade dadurch um drei Bytes zu groß wird.

Wir sollten uns, so wie ich auch oben schon erklärt habe, öfter Gedanken um das Verhältnis von Aufwand zu Ertrag bei der Arbeit am DS-Mod machen oder den Leuten, die sich ohne Hintergrundwissen pauschal über alles beklagen, großzügig den Vortritt lassen, wenn es darum geht, solche aufwendigen Kleinigkeiten zu implementieren (dann aber bitte so, daß es für alle >30 aktuelle Firmwares funktioniert, und das ist oft sehr aufwendig).
 
Um mal kurz bei dem Web-IF zu bleiben: Rausnehmen, allerdings zusammenpacken und irgendwo als tar hinterlegen zum nachladen und "übermounten". Da sollte es dann irgendwie doch möglich sein, drauf zu verzichten. Um wie viele KB würde es da überhaupt gehen? So ungefähr natürlich? Unter berücksichtigung vom Symlinks und verscheidenen Brandings?
 
Was immer geht drin lassen: ein "toter Link" stört nicht, ein "tötender Link" (der die Box zum Reboot bringt) natürlich schon.

Welche Chancen hat man denn, die Versionen "zu mischen" (ich oute mich ja gern als nicht 7170 Benutzer), so dass man dann z.B. den "alten" ctlmgr ohne Websrv in der neuen FW mit dem httpd nutzt? Oder gibt es da Library-Probleme?


Jörg
 
Welche Chancen hat man denn, die Versionen "zu mischen" (ich oute mich ja gern als nicht 7170 Benutzer), so dass man dann z.B. den "alten" ctlmgr ohne Websrv in der neuen FW mit dem httpd nutzt? Oder gibt es da Library-Probleme?
Da sehe ich große Probleme, weil wir dann auch die Libraries rüberkopieren müssten. Und dann geht ein anderer Daemon nicht mehr usw.

MfG Oliver
 
  • websrv
    Wieviel größer ist denn der ctlmgr überhaupt durch die websrv-Integration geworden?
  • busybox-settings
    Die lassen sich seit ds26-15 (bzw. dem inetd-Patch in 14.4) doch bereits teilweise unter Advanced Options->Busybox Options einstellen. Es ist keine große Sache, da auch weitere Optionen anzupassen, nur müssen die halt alle einzeln in den Makefiles eingetragen werden, und theoretisch auch mit dem Busybox-Makefile mit angepasst werden. Da man als Fortgeschrittener auch nach dem
    Code:
    make menuconfig
    noch mittels
    Code:
    make busybox-menuconfig
    die Busybox-Optionen manuell anpassen kann, ist das wohl nur bei exotischeren Optionen, die wirklich Platz verbrauchen, sinnvoll.
  • haserl
    Ich denke, haserl optional zu machen, ist aufgrund der Abhängigkeiten im v.a. im Firmwareupdate nur bedingt sinnvoll. Das ist wegen dem Dateiupload auch nicht so leicht anders zu realisieren.
  • Webinterface(s) komplett rauspatchen
    Also wenn wir bei der Diskussion sind, wäre ich eher dafür, das AVM-Webif rauszuschmeissen und durch ein eigenes zu ersetzen. Das ist aber schon ein politisches Thema (ich denke die meisten wollen möglichst wenig an den AVM-Sachen ändern, wenn nicht nötig). Wenn man beide Optionen pflegen muss, ist es natürlich sehr aufwendig, wenn man nur ein eigenes IF hätte, wäre (nach anfänglichem Entwicklungsaufwand) evtl. die Pflege weniger aufwendig.

Gruss, Nico
 
Wer ein neues Web-Interface fertig hat, darf sich gern melden. Aber wie man an OrangeBox sieht, geht es ja weniger ums Interface als vielmehr darum, daß in den Binaries von AVM die Intelligenz (oder sagen wir besser: das API) steckt, um die Einstellungen zu ändern. Will die auch jemand ersetzen? Ich habe nichts dagegen, also Freiwillige vor! Auch die ganzen Ideen mit FreeWrt oder OpenWrt sind sehr willkommen, wenn jemand eine Lösung präsentiert, mit der alle AVM-Hardware-Bestandteile noch funktionieren. Ich bin nicht in der Lage, proprietäre Treiber durch selbst geschriebene zu ersetzen, Oliver wohl auch nicht. Wer von Euch sich zutraut, selbst Treiber zu programmieren, die sauber laufen und dazu noch kleiner oder wenigstens nicht größer als die von AVM sind, ist sicher unser aller Held. :D
 
Kostenlos!

Statistik des Forums

Themen
248,864
Beiträge
2,303,175
Mitglieder
378,519
Neuestes Mitglied
webtop17