[Info] FRITZ!Box 7390 Labor-Firmware Version 84.06.25-30630 vom 12.06.2015

[SF1975]

Hallo,
Jaaa und? Eine Labor ist halt ein Freilandversuch

 

[Johnney]

Es ist zwar kein wirkliches Problem den nmbd wieder reinzubauen - hab ich bei der aktuellen Firmware auch gemacht und das funktioniert einwandfrei, aber das für jede Laborversion zu machen ist mir dann doch zu aufwändig. Auf telnet kann ich allerdings verzichten, hab ich bisher sowieso noch nie benutzt.

 

[koyaanisqatsi]

Moins

:doktor:

Auf telnet kann ich allerdings verzichten, hab ich bisher sowieso noch nie benutzt.

Ein Zauberer?
Denn dann frag ich mich...

Es ist zwar kein wirkliches Problem den nmbd wieder reinzubauen - hab ich bei der aktuellen Firmware auch gemacht...

...wie du das geschafft hast.

Lass mich raten: freetz?
...da kann ich mir den überflüssigen telnetd schon vorstellen.

 

[Johnney]

6.20er Firmware ausgepackt, nmbd kopiert, 6.23er ausgepackt, reinkopiert und wieder zusammengepackt, das ganz dann als FW in die Box geladen. Klar kann ich den auch direkt mit telnet auf die Box laden, aber irgendwie hab ich wohl geahnt dass der demnächst rausfliegt... So hab ich nen setup das immer funktioniert.

 

[OD1001]

@Jonney: Da muss ich 'mal genauer nachfragen. Ich habe die FRITZ.Box.....image Datei in eine tar-Datei umbenannt. Dann kann meine Archivverwaltung (unter Ubuntu) die Datei öffnen. Dort finde ich aber keine nmbd Datei. In /./var/tmp/ finde ich aber die Dateien filesystem.image & kernel.image. Muss ich da weiter entpacken? Umbenennen in tar hilft da aber nicht....

 

[PeterPawn]

Muss ich da weiter entpacken?

filesystem.image ist bei der 7390 0 Byte groß und die Datei kernel.image enthält am Beginn den Kernel für die Box und dahinter das root-Filesystem als SquashFS-Image.

Dieses Image mußt Du mounten oder entpacken, darin findet sich dann der nmbd.

Dazu mußt Du aber erst einmal (gesetzt den Fall, Du willst das zu Fuß machen) den Kernel vom SquashFS trennen, dazu suchst Du am besten in der kernel.image nach der Zeichenkette "sqsh" (an einem durch 256 teilbaren Offset, aber i.d.R. taucht die ohnehin nur einmal auf). Das ist die Signatur des SquashFS-Images und mit der Kenntnis des korrekten Offsets kannst Du mit dem "dd"-Kommando das SquashFS-Image aus der Datei extrahieren (es beginnt bei "sqsh" und reicht bis zum Ende von kernel.image).

Nun brauchst Du nur noch ein passendes SquashFS-Module für Dein System (es ist SquashFS-Version 3 mit LZMA-Komprimierung - keine Ahnung, ob Deine Archivverwaltung damit umgehen könnte) um das Image zu mounten oder Du entpackst es mit einem passenden "unsquashfs"-Utility (auch das muß wieder LZMA-Komprimierung verstehen).

Wenn Du das sehr kompliziert findest, bleibt Dir noch das Installieren einer Freetz-VM und das Auspacken dort.

Alternativ kannst Du Dir (das Auspacken funktioniert) auch selbst ein unsquashfs mit meinem Patch für die SquashFS-Tools in Version 3.4 für Dein Ubuntu bauen (aus dem Freetz-Ticket 2731), das beherrscht das Suchen des SquashFS-Superblocks in der kompletten kernel.image-Datei und der Schritt mit dem "dd" kann entfallen.

Der allereinfachste Weg wäre aber der Download des von mir aus einer 06.20 (deutsch) extrahierten nmbd ... in irgendeinem Thread zu den Firmware-Versionen der 7390 hier habe ich sowohl einen Hash-Wert für die Datei als auch den zugehörigen Link veröffentlicht. Den Hash-Wert kann ja mal jemand mit einem selbst extrahierten nmbd mit meiner Angabe vergleichen ... wenn der stimmt, sind die Chancen auf eine Manipulation meinerseits an der Binärdatei ja nahe Null, ich bin nicht die NSA und mir fehlen die Mittel, eine Hash-Kollision für ein von mir modifiziertes Binärfile zu berechnen ... selbst wenn es "nur" MD5 ist (man könnte ja auch SHA256 nehmen).

In welchem Thread das nun aber genau war, weiß ich selbst nicht mehr ... die Suchfunktion hilft sicherlich.
Gefunden.

 

[koyaanisqatsi]

Ja, genauso hab ich mir das vorgestellt.

Aber gestatte mir eine rethorische Frage.
...und ich stell die nicht als freetz Ticket, nein, rethorisch.

"Warum patcht freetz die debug.cfg aber nicht den nmbd per Default?"
...zumindest bei meiner 7360SL F!OS 6.20.

 

[PeterPawn]

"Warum patcht freetz die debug.cfg aber nicht den nmbd per Default?"

Ich rate mal, daß es bei Deiner 7360SL gar nicht notwendig ist ... denn das Entfernen des nmbd hat meines Wissens nur bei der 7390 stattgefunden (ich halte das ja immer noch für einen Unfall). Es gibt allerdings m.W. eine 7360-Variante komplett ohne NAS, aber da bringt das Hinzufügen des nmbd alleine dann auch nichts.

Freetz selbst setzt (meines Wissens) eine neuere Samba-Version ein als AVM und nachdem dann sowohl der smbd als auch der nmbd auf libsamba.so zurückgreifen, würde ich da auch nicht mischen ... also halte ich das Kopieren des Freetz-nmbd ohne gleichzeitiges Ersetzen des smbd (und aller dazugehörenden Libs) für nicht zielführend. Bliebe also die Frage, ob Freetz tatsächlich den binären nmbd gesondert ablegen sollte (auf irgendwelchen Mirrors, denn der Download einer 84.06.20 bei AVM wird sicherlich in absehbarer Zeit auch nicht mehr funktionieren oder klappt schon jetzt nicht mehr), nur um den dann in ein 7390-Image einzubauen.

Nur für das (hoffentlich temporäre) Problem der 7390 wird wahrscheinlich niemand so einen Patch in Freetz integrieren, zumal der "eigentliche Zweck" ja auch das Erstellen eines Freetz-Images ist und das "Umpacken" der Firmware eher ein "Mißbrauch" von fwmod (der auch unter bestimmten Umständen nicht wie erwartbar - zumindest nach meiner Meinung - funktioniert).

Was aber die Leute, die mit dem von er13 beschriebenen Verfahren das Image umpacken, um die debug.cfg wieder verwenden zu können, vielleicht mal machen sollten, ist der Vorschlag, auch noch einen Patch für den Telnet-Daemon (der ja im Moment nur den Symlink wieder einrichten müßte) einzubauen ... auch das ist unter einem kompletten Freetz-Image allerdings wieder unnötig, denn die dort enthaltene Busybox enthält ja denn wieder den AVM-Patch mit der Symlink-Prüfung nicht mehr und sogar der Start über Tastencodes funktioniert wieder ... ganz ohne existierenden Symlink, aber selbst der wird beim Installieren der Busybox in einem Freetz-Image ja wieder (automatisch) angelegt.

Bleibt also am Ende die Frage, ob jemand einen solchen Telnet-Patch (der ist ja nun wirklich simpel) nur für das Umpacken einer AVM-Firmware in den Trunk integrieren würde (er schadet ja bei einem Freetz-Image auch nicht bzw. kann problemlos mehrfach ausgeführt werden, ohne daß daraus ein Problem entsteht - ein Symlink ist ein Symlink ist ein Symlink) ... dazu kann und will ich nichts sagen.

Aber je mehr Funktionen man mit dem einfachen Umpacken nachrüsten kann - oder besser muß - bei AVM-Firmware, um so eher macht das Entwickeln eines passenden Shell-Skripts Sinn, welches (zunächst mal unter Linux, damit die Dateirechte funktionieren) einfach alle Schritte (Auspacken, Modifizieren, Einpacken) hintereinander ausführt und damit nur noch ein funktionierendes x86-Linux erfordert und auf den Rest von Freetz (vom Auschecken des Trunks bis zum Kompilieren) verzichtet. Die "Bausteine" sind zum großen Teil vorhanden und auch der ganze Aufwand mit dem "fakeroot" ist eigentlich nicht mehr erforderlich, da das mksquashfs auch beim Einpacken das "Eigentum" der Dateien auf root ändern kann. Da werden eben im Trunk auch noch einige alte Zöpfe mitgeschleppt, die man für ein solches Skript einfach ignorieren könnte, denn die alten Boxen kriegen ja vermutlich keine Firmware ab 06.25 - ja überwiegend nicht einmal ein FRITZ!OS 6 überhaupt.

 

[qwertz.asdfgh]

Guten Abend nachtaktive Mitglieder,

Aber je mehr Funktionen man mit dem einfachen Umpacken nachrüsten kann - oder besser muß - bei AVM-Firmware, um so eher macht das Entwickeln eines passenden Shell-Skripts Sinn, ...

also so etwas wie "Freetz-Lite" für die "Stock-FritzOS-Fans" die aber debug.cfg, nmbd und telnetd haben wollen? :mrgreen:

 

[koyaanisqatsi]

Auch so :mrgreen:

Widerspruch, sie taucht nicht automatisch in der MS Netzwerkumgebung* auf

Ich rate mal, daß es bei Deiner 7360SL gar nicht notwendig ist

...daneben, bei der 6.20, also gerade aktuell, ist/wäre es das, warum auch immer,
denn sie hat ja nicht einmal den selben Prozessor und die 7490 hat diesen Fehler nicht?


* Nicht als: Computer

 

[PeterPawn]

also so etwas wie "Freetz-Lite" für die "Stock-FritzOS-Fans" die aber debug.cfg, nmbd und telnetd haben wollen? :mrgreen:

Ja und nein. Eher so etwas wie "externes modfs" ... bei den NOR-Modellen ist mir das Modifizieren direkt auf der Box immer noch zu heiß (obwohl es bei mir funktioniert), denn das Flashen eines nicht funktionierenden Systems macht die Box zum Recovery-Fall und ehe ich mir den Ruf von "modfs" durch Probleme bei NOR-Boxen ruiniere (ich glaube nicht, daß die meisten den fundamentalen Unterschied beim Flashen verstehen), lasse ich das lieber (im Moment jedenfalls noch) bleiben.

Ich meine aber tatsächlich auf der anderen Seite wirklich kein "Freetz-Lite", denn solange da keine zusätzlichen Binaries integriert werden sollen (selbst dann wären sicherlich viele mit einem Repository mit signierten Paketen für FRITZ!OS zufrieden, das muß man halt nur verwalten), braucht es weder das Freetz-Buildsystem (solange man die Tools für das (Ent-)Packen aus einer vertrauenswürdigen Quelle bezieht) noch die Bestandteile eines Freetz-Images wie "modsave", "moduser", usw. - für mich persönlich besteht das, was man landläufig unter "Freetz" zusammenfaßt, ohnehin aus vier - weitgehend voneinander unabhängigen - Teilprojekten, die aber immer als Einheit wahrgenommen werden, was man häufig genug auch hier lesen kann. Auch die Beiträge in Zeitschriften differenzieren da meiner Meinung nach nur unzureichend und so verfestigt sich diese Meinung mehr und mehr.

Aber je mehr AVM die Box verriegelt (was ich ja begrüße, solange man es nicht übertreibt), um so mehr steigt (nach meinem Empfinden) auch die Nachfrage nach einer einfacheren Lösung als Freetz, um die bisher vorhandenen Freiheiten wiederherzustellen für die Leute, die damit etwas anzufangen wissen.

Schon die Hürde, sich eine Linux-Maschine einzurichten (ob als VM oder was auch immer), ist ja für einige recht hoch und warum sollte ein Windows-Benutzer außen vor bleiben? Man muß sich ja an AVM nicht die schlechten Seiten abschauen, meines Wissens gibt es immer noch kein Recovery-Programm für Linux oder OS X. Am Ende würde ich mir also sogar ein Windows-Programm wünschen (das kann notfalls auch auf Cygwin-Basis o.ä. arbeiten), das einfach ein Image vom AVM-Server lädt und die Arbeiten am Image dann selbst ausführt. Es ist nun mal ein nicht wegzudiskutierender Fakt, daß immer noch die meisten PCs unter Windows laufen. Auf der anderen Seite gibt es z.B. bei Amazon's EC2 auch Freistunden und wenn man ein passendes Image für eine EC2-Instanz zum Modifizieren einer FRITZ!Box-Firmware hätte, könnte das tatsächlich auch jeder Windows-Nutzer ausführen (oder meinetwegen auch per VMPlayer, wobei das eben wieder eine Installation zusätzlicher Windows-Software erfordert, die sonst vermutlich die wenigsten brauchen.

Ich könnte mir aber dann eben auch eine Bereitstellung der am häufigsten nachgefragten Pakete (in Standardkonfigurationen, wie bei Paketmanagern üblich) in Binärform vorstellen ... solange man da eine vertrauenswürdige Struktur aufbaut, habe ich ja nicht prinzipiell etwas gegen Binärpakete. Das Credo "use the source, luke" ist ja nicht mal bei den "Puristen" wie Arch Linux o.ä. unumstößlich.

@koy: Fehlt denn nun der nmbd oder taucht sie nur nicht in der Netzwerkumgebung auf? Es gibt - wie gesagt - meines Wissens eine 7360-Version, bei der CONFIG_NAS=n gesetzt ist und damit gar kein NAS funktioniert, logischerweise dann auch kein Samba.

 

[koyaanisqatsi]

Hier gabs grad eine Gurumeditation (Forumfehler)

Also...

   __  _   __  __ ___ __
  |__ |_) |__ |__  |   /
  |   |\  |__ |__  |  /_

   The fun has just begun ...


BusyBox v1.23.2 (2015-06-21 16:18:57 CEST) built-in shell (ash)
nobody@deepbase:/var/tmp$ which nmbd
nobody@deepbase:/var/tmp$ echo $PATH
/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin:/mod/etc/init.d:/sbin:/bin:/usr/sbin:/usr/bin

...weg, nicht da, wie auch immer.
NAS (auch SAMBA) funktioniert über: \\fritz.box oder \\fritz.nas in der Adresszeile (Netzwerkumgebung)

 

[PeterPawn]

BusyBox v1.23.2 (2015-06-21 16:18:57 CEST) built-in shell (ash)
nobody@deepbase:/var/tmp$ which nmbd

Da haben wir so sehr aneinander vorbei geredet, daß sich schon die Frage nach derselben Zeitzone, ja fast nach demselben Planeten, stellt.

Wenn ich das richtig verstehe, redest Du ja hier im AVM-Laborthread über Dein Freetz-Image und bei der Frage

"Warum patcht freetz die debug.cfg aber nicht den nmbd per Default?"

geht es gar nicht um den AVM-nmbd, sondern eigentlich um den aus dem Freetz-Samba-Paket, wo man die Chance hat, den nmbd getrennt vom smbd zu selektieren, also auch - auf eigenen Wunsch hin - eine Samba-Installation ohne nmbd zu erzeugen.

Zwar steht das tatsächlich so da bei Dir, wenn man es erst einmal anhand des Beispiels verstanden hat, aber vorher ging es hier die ganze Zeit um den fehlenden AVM-nmbd und da es im Freetz eben auch die Möglichkeit gibt, die debug.cfg wieder zu reaktivieren ohne ein Freetz-Image zu verwenden, bezogen sich alle nachfolgenden Antworten meinerseits auch genau auf diese Möglichkeit und logischerweise verstand ich deshalb auch die Frage nach der Aktivierung des nmbd in diesem Kontext.

Das sollte auch aus meinen Antworten problemlos erkennbar sein und qwertz.asdfgh hat das ja auch richtig interpretiert, nur das eigentliche Ziel zu sehr in die Nähe von Freetz gerückt.

OT, aber zur Begründung der Abgrenzung zu Freetz notwendig:
Da die (finale) Idee des Modifizierens (z.B. einer 7490, wo ich das in Grundzügen und als CLI-Anwendung ja mit modfs schon demonstriert habe) durch das Laden eines Pseudo-Images und ein dabei hinzugefügtes HTML-Menü, welches dann gleich Bestandteil des Systems wird (wie das gehen kann, zeigt die Dual-Boot-Moglichkeit im GUI eines per modfs modifizierten Images) und später auch ohne erneutes Pseudo-Update für das Hinzufügen/Löschen/Aktualisieren von Paketen verfügbar ist, bei den Freetz-Developern nicht so gut ankam, als ich sie in der Mailing-Liste aufgeworfen habe (vor einem halben Jahr schon), da muß und will ich das weiter von Freetz abgrenzen, als ich es ursprünglich gewünscht hätte, wo die Idee noch als eine Art "Freetz by GUI" von mir gesehen und als solche auch vorgeschlagen wurde, eben als (mögliche) Richtung für eine Weiterentwicklung des - aus meiner Perspektive stagnierenden - Freetz.

Inzwischen hat AVM für meine Begriffe an entscheidenden Stellen die Nase vorn und - meine Leidenschaft für die Sicherheit der LAN-Seite der Box ist sicherlich nicht zu überlesen und wohl kaum ein Geheimnis - die von Freetz gebotenen Lösungen mindestens eingeholt, wenn nicht sogar überboten ... z.B. bei der Möglichkeit, das GUI auch über eine TLS-Verbindung aufzurufen oder bei der Benutzerverwaltung. Auch eine separate Paketverwaltung und damit die Möglichkeit, auf Security-Fixes in einem Paket schneller zu reagieren, hat ja etwas mit der Sicherheit des Gesamtsystems zu tun und hier könnte man eben wieder AVM ein paar Schritte vorauseilen und ihnen zeigen, was machbar ist - wie es bei früheren Freetz-Änderungen/-Ideen der Fall war, die dann irgendwann mal Einzug bei AVM hielten.

Wie weit die Freetz-Developer (bei denen ich zwar in der Mailing-Liste mitlesen/-schreiben kann (das braucht auch nicht sooo viel zusätzliche Zeit), aber ich habe keine Schreibrechte für das SVN oder weitergehende Rechte im Trac und habe das Angebot, diese zu erhalten, bisher auch immer abgelehnt - aus verschiedenen Gründen) bei den Themen TLS und Benutzerverwaltung mitziehen wollen und werden, weiß ich nicht - der aktuell anstehende Umbau verschiedener TLS-nutzender Pakete auf die Benutzung des Box-Zertifikats von AVM (es macht keinen Sinn, mehrere verschiedene Zertifikate für denselben Host verwalten zu müssen) ist für mich da die Nagelprobe, die Tickets existieren schon für ShellInABox und stunnel, inkl. der Anleitung für apache2 und einer Anfrage, wie man das für OpenVPN am besten lösen sollte.

Deshalb finde ich die Bezeichnung "Freetz-Lite" unglücklich und wollte die Idee dahinter (auch "Nicht-Linuxern" bzw. am Ende vielleicht sogar Nutzern ohne einen PC das Modifizieren der Box über eine (zeitgemäßere) Oberfläche zu ermöglichen) nicht in den Freetz-Kontext rücken lassen, denn das wird von den Developern dort selbst (bisher zumindest) nicht gewünscht.

Das hat nichts damit zu tun, daß man nicht auch bei der Umsetzung meiner Idee selbstverständlich auf Teile von Freetz zurückgreifen müßte und sollte, daher auch die von mir propagierte differenzierte Sicht auf die verschiedenen Bestandteile, die sich für mich in

1. Paket-Verwaltung - dazu gehört praktisch alles, was sich vor und hinter dem "menuconfig" verbirgt, von der Erstellung der Freetz-Pakete bis zur (Standard-)Konfiguration für die überwiegende Zahl der Einsatzfälle
2. Cross-Compiling / Packaging
3. Image-Generierung und nicht zuletzt
4. den Freetz-Mod im fertigen Freetz-Image

unterteilen.

Meine Idee würde

• 1. überhaupt nicht tangieren,
• 2. irgendwie versuchen auf einen Build-Service (z.B. den OBS von Novell) auszulagern (es gibt entsprechende Möglichkeiten, z.B. hier dokumentiert),
• 3. durch das GUI-gestützte Modifizieren der AVM-Firmware direkt auf der Box ersetzen (die hat jeder an dem Thema interessierte mit höherer Wahrscheinlichkeit, als einen eigenen PC - zumindest wenn die Entwicklung bei Tablets so weiter geht und Windows 10 nicht alles wieder umkehrt, selbst wenn ich mir eine Linux-VM auf einem Surface zwar vorstellen kann, auch wenn ich sie nicht für eine gute Idee halte)
• und bei 4. sicherlich eine Weiterentwicklung erfordern, schon weil ja das GUI für die Paketverwaltung unter diesen Punkt fallen würde.

Ich habe schon vor dem Propagieren dieser Idee erst einmal die prinzipielle Realisierbarkeit geprüft/getestet, damit das nicht alles nur "Luftschlösser" sind. Einige Teilergebnisse sind ja auch als PoC veröffentlicht, mit diesen Bausteinen - die iterativ von mir weiterentwickelt werden - ließe sich das Ziel nach meinem Verständnis tatsächlich erreichen. Aber es ist eben auch eine Menge Arbeit und solange ich daran alleine herumwurstele (und auch noch "Tagesgeschäft" zu bewältigen ist), ist das ein sehr langfristiges Vorhaben ... nur durch mehr Manpower kann man das ggf. schneller vorantreiben.

Als die Freetz-Developer auf die Idee nicht ansprangen, habe ich das eben auf die lange Bank geschoben, da ich eine Zersplitterung der Community nicht für sinnvoll erachte, auch wenn es aus meiner Sicht - siehe oben zu Synergie-Effekten/Nachnutzungen - keine Konkurrenzsituation ist und ich Neuentwicklungen (von der sehr seltenen Integration neuer Pakete, was auch mehr auf das Patchen vorhandener Software als auf eigene Entwicklungen hinausläuft, mal abgesehen) bei Freetz derzeit nicht sehe. Wenn es sie geben sollte, dann eher im Hintergrund ...

 

[OD1001]

Da hab ich ja eine Diskussion ausgelöst....

Danke für die Infos - ich werde bei Gelegenheit diese Informationen weiter verfolgen...

 

[Johnney]

Da hab ich ja eine Diskussion ausgelöst....

Danke für die Infos - ich werde bei Gelegenheit diese Informationen weiter verfolgen...

Das aus- und einpacken geht auch wesentlich einfacher übrigens. Auf freetz.org gibts nen how-to dazu. Geh aber mal davon aus, dass du ne Linux installation in irgendeiner form wie auch immer brauchst und den freetz-2.0-stable branch, mit dem anderen tut sich rein gar nichts. Wenn aber mal alles eingerichtet ist gehts relativ fix, einem kompletten Linux-Neuling würd ich jetzt aber man nicht direkt dazu raten.

 

[koyaanisqatsi]

Da haben wir so sehr aneinander vorbei geredet

Dann will ich das mal kurz darstellen.

1. Mein freetz Image (7360SL) ist auf 6.20 Basis, bei der wie bei der 7390 der nmbd fehlt.
2. Ich hab mit make menuconfig die Samba Pakete nicht angefasst.
3. Hab aber zufällig gesehn, dass mir per Default die debug.cfg gepatched wird.
...Moment? Bei freetz? Brauch ich das? Nee, abhaken.
5. Ich hatte schon meine Diskussion mit Cuma, über eine 7113, AVM Update LED Fehler, vielleicht patchen?
6. Deswegen verwundert mich das mit der debug.cfg, dass mit dem nmbd nicht.

 

[PeterPawn]

Das aus- und einpacken geht auch wesentlich einfacher übrigens.

Jetzt war ich tatsächlich kurz verunsichert, ob ich diese Variante unterschlagen hatte ... das war aber nicht der Fall:

Wenn Du das sehr kompliziert findest, bleibt Dir noch das Installieren einer Freetz-VM und das Auspacken dort.

Bei einem bereits vorhandenen Linux-System (hier geht es ja um ein Ubuntu bei OD1001, s. #25) bleibt ja trotzdem abzuwägen, ob sich die Installation der VM lohnt, wenn man "nur" Umpacken will. Das klärt aber sicherlich auch (in gewissen Grenzen jedenfalls), die Frage, ob OD1001 nun "kompletter Linux-Neuling" ist oder nicht. Zumindest benutzt er/sie ja eine Linux-Installation.

Geh aber mal davon aus, dass du [...] den freetz-2.0-stable branch [brauchst], mit dem anderen tut sich rein gar nichts.

Da sollte man dann tatsächlich auch lieber den Trunk nehmen ... unter "dem anderen" verstehst Du hoffentlich die älteren stable-1.x-Stände, oder? Mit dem Trunk sollte das problemlos funktionieren ... wenn nicht, wäre eine genauere Information als "tut sich rein gar nichts" hilfreich.

@koy:
Wenn man es dann erst einmal verstanden hat, kann man es ja auch nachvollziehen. Ich bin mir nur bei

bei der wie bei der 7390 der nmbd fehlt.

etwas unsicher, ob es sich auch wirklich um dieselbe Situation handelt und Du nicht nur ein AVM-Image als Basis hast, was gar keinen NAS hat ... dann ist da ja auch kein smbd im AVM-Image vorhanden und der nmbd macht dann keinen Sinn. Wenn das tatsächlich auch ein AVM-Image mit smbd und ohne nmbd ist, dann wäre die 7390 ja nicht mehr die einzige, wo das mit dem (alleine) fehlenden nmbd auftritt, was dann die Spekulationen, was sich AVM dabei denken könnte, wieder anheizen würde.

 

[koyaanisqatsi]

Schwere Geburt, fürchte ich...

mit smbd und ohne nmbd

Ja dem ist so. Die liegt als Release auf dem AVM Update Server rum.
Deutlicher:
7360SL (übrigens mit NAS)

Firmware-Informationen
Firmwareversion
    109.06.20 
AVM-Revision
    29220
Sprache
    de
Erstellungsdatum (AVM)
    22.10.2014 14:07:54
Bootloaderversion
    1.1475

Um dir das mit der originalen Firmware (nicht freetz) beweisen zu können,
müsste ich sie wieder flashen. Das spar ich mir.
Denn ich benötige ihn eh nicht unbedingt, aber immerhin ist die Info jetzt rübergekommen?

 

[qwertz.asdfgh]

Wenn das tatsächlich auch ein AVM-Image mit smbd und ohne nmbd ist, dann wäre die 7390 ja nicht mehr die einzige, wo das mit dem (alleine) fehlenden nmbd auftritt, ...

Habe spaßeshalber jetzt einfach mal die 109.06.20 für die 7360SL entpackt da ich es auch nicht glauben wollte dass das bis jetzt noch keiner bemerkt haben will, also ich muss koy recht geben, der smbd ist da und nmbd nicht, genauso wie bei der 84.06.23 @7390.

Ist nun eine neue Spalte in der "Spezialtabelle" notwendig? nmbd ja/nein? Für telnetd und debug.cfg sicherlich nicht notwendig da es ja dazu eine pauschale Aussage gibt z.B. in der Form ab 6.10 keine debug.cfg (Ausnahme 7270 mit 6.05) und ab 6.25 Labor kein telnetd.

 

[PeterPawn]

also ich muss koy recht geben, der smbd ist da und nmbd nicht, genauso wie bei der 84.06.23 @7390.

Ich war noch beim Auspacken ... was mich daran am meisten verblüfft (jetzt stellt sich dann wirklich wieder die Frage nach dem Grund), ist die Tatsache, daß die 7360SL ja eine VR9-Box ist. Bei einer Vx180-Box hätte ich glatt noch auf denselben Build-Zweig geschlossen, aber hier wird es jetzt wirklich mysteriös in meinen Augen.

Ich packe das mal bis zum Ende aus (muß erst mal ergründen, ob das nun LZMA ist (wahrscheinlich schon) oder nicht, ich habe keine AR9-Boxen bisher betrachtet) und rechne das mit dem Platz mal nach ... irgendwie ergibt jetzt die These mit der "vergessenen Wiederaufnahme" des nmbd nur noch begrenzt Sinn (so wie die Betrachtungen zum zeitlichen Ablauf bei der 7390i).

Wobei doch der nmbd bei der 7390 in der 06.20 noch drin war (da habe ich den auf yourfritz.de ja extrahiert) und erst mit der 06.21 nicht mehr vorhanden war ... das ist alles sehr undurchsichtig. Anschließend nehme ich mir jedenfalls diese Versionen noch einmal vor und vergleiche die Änderung des benötigten Platzes im Flash zwischen der 06.20 und 06.21.

Der zeitliche Ablauf sieht jetzt so aus:

84.06.20 - 7390 -> 05.09.2014 12:06:11 -> mit nmbd
109.06.20 - 7360SL -> 22.10.2014 14:07:54 -> ohne nmbd
84.06.21 - 7390 -> 05.11.2014 12:09:26 -> ohne nmbd
84.06.20 int. - 7390i -> 21.11.2014 16:37:10 -> ohne nmbd

Wenn es jetzt bei der vorhergehenden Version für die 7360SL nicht auch so war, daß dort wegen Platzmangels der komplette Samba-Server fehlte (wie bei der internationalen 7390 in den 06.0x-Versionen) und mit der 06.20 wieder aufgenommen wurde, dann stellt sich die Frage, warum irgendwann zwischen Anfang Sept. und Ende Okt. der nmbd aus der Firmware entfernt wurde und auch das nur bei diesen beiden Modellen, soweit wir bisher wissen. Eigentlich müßte man jetzt hingehen und das mal für die anderen Modelle mit 16MB Flash untersuchen.

Aber mit dieser neuen Box ohne nmbd wird es in meinen Augen nun erst richtig unklar, was sich AVM dabei denkt ... eine Sicherheitslücke im nmbd ist jedenfalls (offiziell) meines Wissen nicht bekannt und bei der aktuellen 7490 wird ja auch genau dieselbe Samba-Version (3.0.37 lt. smbclient) weiterhin mit dem nmbd verwendet.

Bei der 7390 ist das Platzargument offensichtlicher Unsinn (oft genug vorgerechnet und es gibt ja Leute hier, die den nmbd wieder in ein - nur umgepacktes - Image integriert haben), das sind keine 90KB unkomprimiert. Da ich die 7360SL selbst nicht habe (und auch den Firmware-Thread damit nicht belasten will), die Bitte an einen von Euch beiden (koy oder qwertz.asdfgh) - notfalls auch an beide, das verkraftet mein Postfach noch - mir die Vorgängerversion für die 7360SL (wenn vorhanden) mal irgendwo bereitzustellen. Bei der 7390 komme ich selbst weit genug in die Vergangenheit ...

Auf der anderen Seite gibt es ja bei der 7360SL doch eigentlich noch jede Menge anderes Sparpotential, denn ohne ISDN und 5 GHz-WLAN sollte sich noch etwas anderes entfernen lassen. Da macht das Platzargument ja noch viel weniger Sinn ... :gruebel:

Das führt dann wieder zu der Vermutung, AVM wolle den Kunden die älteren Modelle beim Update sukzessive verleiden, um den Umsatz bei den neueren Modellen anzukurbeln. So blöd das auch klingen mag ... vielleicht schafft es AVM ja tatsächlich mal, die Entscheidung zum nmbd (wenn es denn wirklich eine bewußte war) plausibel zu begründen. Die hier auch irgendwo zitierte Aussage des Support, bei der 7390 wären Platzprobleme der Grund, ist bei der 06.21 bis 06.23 ja offenkundiger Unsinn. Wenn das schon vorauseilender Gehorsam für künftige Versionen war, sollte AVM wieder darüber nachdenken, uns die "Multimedia-Dateien" im NAND-Flash vorzuenthalten -> das ist ja noch ein weiterer Punkt, der bei der 7360SL nicht vorhanden ist, damit braucht es auch die Dateien zur "Initialisierung" des NAND-Inhalts (den Song, die Bilder und das Video) nicht, was dort weiteren Platz spart.

EDIT:

SquashFS 84.06.20 -> 14072370 Byte (0xD6BA32) + Kernel -> 1384448 Byte (0x152000)
SquashFS 84.06.21 -> 14026574 Byte (0xD6074E) + Kernel -> 1384704 Byte (0x152100)

verfügbar bei 7390 -> 15597568 Byte (0xEE0000)

Platzbedarf gesamt 06.20 => 0x152000 + 0xD6BA32 = 0xEBDA32 => frei (bzw. ungenutzt) sind also 0xEE0000 - 0xEBDA32 = 0x225CE (140750 Byte)
Platzbedarf gesamt 06.21 => 0x152100 + 0xD6074E = 0xEB284E => 0xEE0000 - 0xEB284E = 0x2D7B2 (186290 Byte)

Es ist also bei der 06.21 mehr Platz übrig ... bei der 7390 spielt dieser freie Platz, der auf anderen Modellen schon mal für den AB gebraucht wird, gar keine Rolle, denn TAM-Inhalte werden ohnehin im NAND-Flash unter /var/media/ftp/FRITZ abgelegt. Die 256 Byte zusätzlicher Platzbedarf für den Kernel (da ist auch noch Padding dabei, da ja auf eine 256-Byte-Boundary gerundet wird), wären auch mit den zusätzlichen 90KB für den nmbd (das ist immer noch unkomprimiert, der tatsächliche Platzbedarf ist noch kleiner) locker zu verkraften. Den Verweis auf die vollkommen überflüssigen Dateien unter /etc/internal_memory_default_de kann ich mir auch wieder nicht verkneifen:

~/7390/06.21/etc$ du -abc internal_memory_default_de
676     internal_memory_default_de/Videos/FRITZ! Clips.html
95907   internal_memory_default_de/Videos/FRITZ-Video.mp4
100679  internal_memory_default_de/Videos
30192   internal_memory_default_de/Bilder/FRITZ-Picture.jpg
34288   internal_memory_default_de/Bilder
6640    internal_memory_default_de/Dokumente/FRITZ-NAS.txt
634     internal_memory_default_de/Dokumente/Produkthandbuch.html
11370   internal_memory_default_de/Dokumente
104464  internal_memory_default_de/Musik/FRITZ-Song.mp3
108560  internal_memory_default_de/Musik
258993  internal_memory_default_de
258993  total

In Anbetracht der Tatsache, daß MP3-, MP4- und JPG-Dateien bereits komprimiert sind, sind das (vermutlich) auch die Netto-Werte, die den Platzbedarf im SquashFS-Image widerspiegeln. Wenn also mal wieder Platz benötigt wird ... da wären noch knapp 250 KB zu finden, die am Ende kein Mensch wirklich braucht - auch den Vorschlag, die notfalls vom AVM-Server zu holen, wenn die Box mal ins Internet kommt, kann man ja noch mal erneuern.