[Gelöst] FW 6.50 für 7490 in Trunk rev. 13490 - keine Auswahlmöglichkeit

PeterPawn · 29 Dez 2015

@er13:
Sorry, Deine Vergleiche der Busybox im Ticket 2774 habe ich jetzt erst so richtig gesehen dank des Hinweises auf das Shell-Skript ... dadurch, daß es in keinem Changeset auftaucht (außer dem "sync .config" in r13512, wo man das aber auch nicht erkennen konnte), ist mir das gar nicht bewußt gewesen - ich lese halt nur noch als anonymer User das Journal und solche "intra ticket changes" kriege ich damit mangels E-Mails vom Trac nicht mehr mit.

Dann werde ich natürlich die von Dir neu ermittelte .config für die Busybox gleich mal als Ausgangspunkt für einen Test nehmen ... vielleicht ist damit ja schon das Problem behoben. Wobei es wohl nicht nur an meiner eigenen Busybox gelegen haben kann, denn andere haben das WLAN-Problem ja auch und die haben (vermutlich) nicht meine Busybox, solange sie nicht mit bbconfig aus "modfs-Starter" ihre eigene Version gebaut haben (zumindest auf der 7390).

Was machst Du jetzt eigentlich mit Änderungen am Trunk? Wirklich umschalten auf r/o und wenn ja, ab wann und wie lange?

Wenn wirklich jetzt final auf GitHub migriert werden sollte, macht es ja für mich dann auch wieder Sinn, entsprechend zu forken bzw. Patches bereitzustellen, die Du dann (oder auch jemand, der das auschecken will für einen eigenen Build) bei Interesse per "pull" direkt übernehmen könntest - das ist um einiges schöner als das Anhängen von Patches an irgendwelche Tickets im Trac.

Wenn das feststeht, mache ich einen GitHub-Account für meine Zusätze auf, das erleichtert dann die Integration und ich muß das nicht jedesmal alles neu anpassen, wenn wieder ein Version-Bump für ein gepatchtes Paket kommt. Das habe ich ja inzwischen auch "offiziell" aufgegeben ... wenn ich für Binärdateien, die ich bereitstelle, auch noch Patches gegen irgendwelche Freetz-Pakete veröffentliche, damit man das nachbauen kann, dann im Moment nur noch gegen den jeweils zum Zeitpunkt der Veröffentlichung aktiven Prüfpunkt.

@koy:

koyaanisqatsi schrieb:
...das Kommando kennt meine BB (sh/ash) 1.21 nicht.

Selbst erstellt oder die Version von r@d?

Die Einstellung dafür ist "BUSYBOX_ASH_HELP" ... zu finden unter "Shells" in der Busybox-Konfiguration.

vice_pres · 29 Dez 2015

PeterPawn schrieb:
Kann ich Dir nicht sagen, sind denn in Deiner "modules.alias" die von mir erwähnten Einträge für "fs-modulename" vorhanden? Die oben gezeigte "filesystem.c" beim 3er-Kernel verwendet ja eine andere Maske für die Module-Namen. Ob Freetz da selbst an der "modules.alias" dreht, weiß ich wieder mal nicht.

So siehts bei mir aus: (also genauso wie bei dir)

Code:

root@fritz:/var/mod/root# grep "fs-" /lib/modules/$(uname -r)/modules.alias
alias fs-vfat vfat
alias fs-msdos msdos
alias fs-jffs2 jffs2

Habs nochmal probiert - ohne manuelles modprobe funktioniert das mounten nicht.

Code:

root@fritz:/var/mod/root# mount /dev/sda1 /var/media/ftp/uStor01/
mount: mounting /dev/sda1 on /var/media/ftp/uStor01/ failed: Invalid argument
root@fritz:/var/mod/root# modprobe vfat
root@fritz:/var/mod/root# mount /dev/sda1 /var/media/ftp/uStor01/
root@fritz:/var/mod/root# umount /var/media/ftp/uStor01/

koyaanisqatsi · 29 Dez 2015

PeterPawn schrieb:
Selbst erstellt oder die Version von r@d?

Eigentlich hol ich mir die Binary direkt aus der Quelle.
...ist aber (V 1.21) schon länger her.

PeterPawn · 29 Dez 2015

vice_pres schrieb:
Habs nochmal probiert - ohne manuelles modprobe funktioniert das mounten nicht.

Da muß bei Dir dann noch etwas anderes geändert sein, ggf. durch Freetz. Ich verwende ja Freetz nicht und wenn ich ein Volume, das über "blkid" als "vfat" erkannt wurde, mounten will, lädt das System ordentlich die notwendigen Module von alleine.

Es gibt eine Build-Time-Option für "modprobe", daß es anstelle der "modules.dep" für die Abhängigkeiten einen Scan über das "modules"-Verzeichnis verwenden soll (Option BUSYBOX_MODPROBE_SMALL). Ist diese bei Dir eventuell aktiviert und das "modprobe" funktioniert zwar, wenn es explizit aufgerufen wird, aber die Begrenzung von Rekursionen (oder auch ein Timeout für das Laden, ich habe "request_module()" gerade nicht vor Augen und im Moment auch keine Zeit/Lust zum Suchen) im Kernel verhindert das automatische Laden aus filesystem.c heraus? Damit da keine unendlichen Loops entstehen, wenn in der modules.dep falsche Abhängigkeiten hinterlegt sind, gibt es da eine Sperre ... habe ich beim Überfliegen gesehen, aber nicht versucht zu verstehen.

Das ist per Ferndiagnose schwer festzustellen ... da "vfat" ein geladenes "fat" benötigt:

Code:

# grep -r fat /lib/modules/$(uname -r)/modules.dep
kernel/fs/fat/fat.ko:
kernel/fs/fat/vfat.ko: kernel/fs/fat/fat.ko
kernel/fs/fat/msdos.ko: kernel/fs/fat/fat.ko

kannst Du ja mal probieren, was beim Mounten bei Dir passiert, wenn Du vorher nur ein "modprobe fat" machst. Zumindest kriegt man dann mal eine Idee, wo das Problem liegen könnte oder eben auch nicht liegt.

Ich mache hier mal eine Art private "Mini-Liste" auf, welche Freetz-Pakete Anpassungen brauchen und warum ... einiges davon hängt mit dem 3er-Kernel zusammen und einiges nicht.

ImageMagick
- auf dem dortigen Download-Server werden nur noch die Pakete der jeweils aktuellen Version mit Nummer vorgehalten (im Moment 6.9.2.10) und ein Link ohne Versionsnummer
- entweder man paßt das künftig in schnellerer Folge an (ohne diese Anpassung scheitert der Download, wenn das Paket nicht mehr zur Verfügung steht), packt die aktuelle Version aus dem Makefile auf einen Mirror oder man greift gleich auf das Basis-Repository zurück: http://git.imagemagick.org/repos/ImageMagick/

bridge-utils
- unter dem 3er-Kernel braucht das Paket ein zusätzliches "include" - ob es Upstream eine korrigierte Version gibt (ggf. auch ein korrigiertes automake), habe ich gar nicht erst gesucht bei dieser einen Zeile:

Code:

Index: make/bridge-utils/patches/900-kernel_3_10.patch
===================================================================
--- make/bridge-utils/patches/900-kernel_3_10.patch     (revision 0)
+++ make/bridge-utils/patches/900-kernel_3_10.patch     (working copy)
@@ -0,0 +1,10 @@
+--- libbridge/libbridge.h
++++ libbridge/libbridge.h
+@@ -20,6 +20,7 @@
+ #define _LIBBRIDGE_H
+
+ #include <sys/socket.h>
++#include <linux/in6.h>
+ #include <linux/if.h>
+ #include <linux/if_bridge.h>
+

iptraf
- die Unterstützung im Kernel 3 für "Token Ring" wurde aufgegeben
- die letzte iptraf-Version stammt aus 2005
- ~~die Arbeit, den TR-Support auch dort herauszupatchen, hat sich schon jemand anderes gemacht: https://github.com/zaburt/pspecs/bl...kernel-v3.5-kill-off-token-ring-support.patch~~ sorry, falsches Paket erwischt - das ist für "iptraf-ng" und nicht für das alte "iptraf 3.0.1"

er13 · 29 Dez 2015

vice_pres schrieb:
Habs nochmal probiert - ohne manuelles modprobe funktioniert das mounten nicht.

Bevor da wieder nach den Fehlern gesucht wird, die es nicht mehr gibt. Welche Revision verwendest Du? Eigentlich sollte das "Freetz-Modproben" seit r13519 behoben sein. Die Sinnhaftigkeit davon bzw. warum es überhaupt (im Gegensatz zu der Original-Firmware) nötig ist, etwas zu modproben, habe ich noch nicht untersucht.

vice_pres · 29 Dez 2015

PeterPawn schrieb:
Da muß bei Dir dann noch etwas anderes geändert sein, ggf. durch Freetz. Ich verwende ja Freetz nicht und wenn ich ein Volume, das über "blkid" als "vfat" erkannt wurde, mounten will, lädt das System ordentlich die notwendigen Module von alleine.

Es gibt eine Build-Time-Option für "modprobe", daß es anstelle der "modules.dep" für die Abhängigkeiten einen Scan über das "modules"-Verzeichnis verwenden soll (Option BUSYBOX_MODPROBE_SMALL). Ist diese bei Dir eventuell aktiviert und das "modprobe" funktioniert zwar, wenn es explizit aufgerufen wird, aber die Begrenzung von Rekursionen (oder auch ein Timeout für das Laden, ich habe "request_module()" gerade nicht vor Augen und im Moment auch keine Zeit/Lust zum Suchen) im Kernel verhindert das automatische Laden aus filesystem.c heraus? Damit da keine unendlichen Loops entstehen, wenn in der modules.dep falsche Abhängigkeiten hinterlegt sind, gibt es da eine Sperre ... habe ich beim Überfliegen gesehen, aber nicht versucht zu verstehen.

Das ist per Ferndiagnose schwer festzustellen ... da "vfat" ein geladenes "fat" benötigt:

Code:

# grep -r fat /lib/modules/$(uname -r)/modules.dep kernel/fs/fat/fat.ko: kernel/fs/fat/vfat.ko: kernel/fs/fat/fat.ko kernel/fs/fat/msdos.ko: kernel/fs/fat/fat.ko

kannst Du ja mal probieren, was beim Mounten bei Dir passiert, wenn Du vorher nur ein "modprobe fat" machst. Zumindest kriegt man dann mal eine Idee, wo das Problem liegen könnte oder eben auch nicht liegt.

Ne, die busybox option ist eigentlich nicht gesetzt, das hatte ich vorher schonmal überprüft:

Code:

# FREETZ_BUSYBOX_MODPROBE_SMALL is not set

Das laden vom reinen Modul fat bringt nichts - das mounten vom vfat stick klappt damit auch nicht.

Code:

root@fritz:/var/mod/root# modprobe fat
root@fritz:/var/mod/root# mount /dev/sda1 /var/media/ftp/uStor01/
mount: mounting /dev/sda1 on /var/media/ftp/uStor01/ failed: Invalid argument

Der Stick wird über blkid als vfat erkannt, das habe ich auch schon kontrolliert - mir fehlt da leider auch (wie öfter) der richtige Ansatz und auch das tiefe Verständnis (und auch Zeit da richtig reinzukommen). Ich bin gerne bereit in meiner Testumgebung zu testen, brauche nur n Fingerzeig wohin...

Aber mit dem freetz image wird dann das Verhalten definitiv geändert, soviel können wir ja schonmal festhalten wenn es bei dir mit der Stock 06.50 funktioniert. Durch das ändern in die uname variante im trunk tritt das Problem ja auch nicht mehr auf - das Verhalten an sich ist aber ja doch komisch. Ob man das weiter verfolgen will ist die andere Frage wenn man mit uname ja einen Weg um das Problem herum gefunden hat... Damit kann ich dann händisch mounten, automatisch wird nicht gemountet - aber ich muss kein modprobe mehr vorher machen.

Edit: @er13: wir hatten uns da überschnitten. Ich weiß, dass es im aktuellen Stand weg ist (habe ich getestet) - mir gings nur um das unterschiedliche Verhalten. Sorry wenn ich hier für Verwirrung gesorgt habe. Aktuell bin ich auf 13529 mit der das mounten von hand ohne vorherigen modprobe funktioniert (aber nicht automatisch da ja kein Freetzmount vorhanden ist)

PeterPawn · 29 Dez 2015

@SF1975:
Habe ich im "modfs"-Thread schon mal "offiziell" geschrieben ... einfach "modfs (AN) yourfritz (PUNKT) de", solange es um "modfs" im Großen und Ganzen geht, ansonsten "admin".

Damit habe ich inzwischen berufliche Mails von FRITZ!Box/Freetz/YourFritz/(IPPF allg.) getrennt (verwende ich jetzt auch nur noch als E-Mail-Adresse in README-Files in irgendwelchen Paketen) und an der Stelle landen dann Leute, die nur nerven wollen (nein, es gibt keine weiteren Informationen zur 6490 von mir), ohne viel Federlesens im "killfile", ohne daß ich aus beruflichen Gründen jeder einzelnen Mail hinterherlaufen muß - da kann ich es mir leisten, auch mal ein "false positive" zu verlieren, wenn die Filter "DOCSIS" und "6490" gleichzeitig zuschlagen und eine Mail im Junk-Ordner zwischenlagern, bis das IMAP-Purge sie dann entsorgt. Extra dafür habe ich auch eine weitere getrennte Instanz eines MUA eingerichtet (TB, auch wenn das jetzt irgendwohin abgegeben werden soll von der Foundation), die ich deutlich seltener lese und auch auf mobilen Geräten gar nicht erst eingerichtet habe ... das kann also auch mal etwas länger dauern mit einer Reaktion (aber i.d.R. auch keine Tage).

er13 · 29 Dez 2015

PeterPawn schrieb:
@er13:
Was machst Du jetzt eigentlich mit Änderungen am Trunk? Wirklich umschalten auf r/o und wenn ja, ab wann und wie lange?

Ich persönlich bin in die Migration nicht involviert. It's done, when it's done. Stand jetzt, keiner hat Zeit (und teilweise auch das Know-How), um sich richtig intensiv darum kümmern zu können. So wie ich es verstanden habe, hat Michael Heimpold sich um die Migration des Codes gekümmert. Ob er auch die Tickets/Wiki übernimmt, weiß ich nicht. Am besten einfach auf der Mailing-Liste fragen.

PeterPawn schrieb:
Wenn wirklich jetzt final auf GitHub migriert werden sollte, macht es ja für mich dann auch wieder Sinn, entsprechend zu forken bzw. Patches bereitzustellen

Es wird definitiv was git basiertes sein. Mit fast 100%-er Wahrscheinlichkeit wird es github sein.

PeterPawn · 29 Dez 2015

vice_pres schrieb:
soviel können wir ja schonmal festhalten wenn es bei dir mit der Stock 06.50 funktioniert

Bei der AVM-Firmware wird - wie schon weiter vorne mal geschrieben - auch schon länger kein "modprobe" mehr für Filesystem-Module gemacht, nur für "device driver" wie "storage" oder "sd_mod". Das ist nichts neues in der 06.50, nur die Namen für die Suche haben sich geändert und wurden zu "fs-irgendwas" unter dem 3er-Kernel.

Die Anmerkung von Gene weiter oben hast Du ja sicherlich gelesen ... bleibt die Frage, ob man sich mit dem Patch und dem "preloading" der Module zufrieden gibt oder doch versuchen will, die Ursache zu tracken.

Ich rate mal ganz simpel und vermute, daß Du beim Aufruf von "mount" ohne die Angabe von "-t type" ein Henne-Ei-Problem hast. Das "mount"-Kommando der Busybox versucht zwar, die Kernel-Funktion zum Mounten mit allen bisher bekannten Dateisystem-Typen der Reihe nach aufzurufen, bis ein Aufruf funktioniert ... aber diese "Liste der Versuche" baut es aus den bisher bekannten Typen (/proc/filesystems) zusammen und dort steht der noch nicht geladene Treiber eben nicht drin. Man muß bei so einem Mount also hingehen und vorher den Dateisystem-Typ ermitteln (eben z.B. mit blkid). Gibt man den dann beim Mount-Aufruf entsprechend an, ruft die Busybox auch die Kernel-Funktion nur mit diesem Typ auf und der Kernel lädt dann die notwendigen Module.

vice_pres · 29 Dez 2015

-t vfat habe ich am anfang auch probiert, ich wechsel jetzt gleich nochmal das image und probiere es nochmal - ich bin der meinung es ging nicht. Wie gesagt - nach dem Fix im trunk funktioniert das mounten ja auch (da der test ja nicht mehr fehlschlägt wird das modul ja auch geladen) - die Frage war halt auch für mich warum es unterschiedlich ist bei freetz im Gegensatz zum original AVM Verhalten. Wenn man natürlich sagt "wir haben das Problem gelöst, warum auch immer es da war" kann ich damit auch gut leben - letztendlich bin ich ja auch nur ein Anwender

Edit:
Die Fehlermeldung war ne andere, daran hatte ich nicht mehr gedacht:

Code:

root@fritz:/var/mod/root# mount /dev/sda1 /var/media/ftp/uStor01/
mount: mounting /dev/sda1 on /var/media/ftp/uStor01/ failed: Invalid argument
root@fritz:/var/mod/root# mount -t vfat /dev/sda1 /var/media/ftp/uStor01/
mount: mounting /dev/sda1 on /var/media/ftp/uStor01/ failed: No such device

PeterPawn · 29 Dez 2015

er13 schrieb:
It's done, when it's done.

Jetzt ist es wenigstens "offiziell" ...

Trac-Wiki schrieb:
Important Note: We are migrating source code repository, wiki and tickets to GitHub, so this Trac is read-only at the moment. We ask for your patience.

Ich hatte ja nur die Befürchtung, daß Ende Januar heranrückt und gar nichts passiert ... ein r/o-Repository können Interessenten ja immer noch klonen, ein abgeschaltetes wohl eher nicht.

Daher meine frühere Bemerkung mit "gut weglegen" - damit haben sich aber auch erst einmal weitere Commits zur Anpassung an 06.50 erledigt und vielleicht ist es keine schlechte Idee, diesen Thread hier dann doch zu beerdigen (schon die Eingangsthese stimmt ja nicht mehr seit r13503) und übergangsweise weitere Änderungen für die 06.50 in einem gesonderten neuen Thread zu sammeln.

PeterPawn · 2 Jan 2016

Ich habe das Thema nicht vergessen ... ich suche im Moment in den Freetz-Patches nach einer möglichen Ursache des WLAN-Problems.

Dabei ist mir aber noch ein weiteres potentielles Problem untergekommen:

Code:

ctlmgr stderr: libpng error: zlib failed to initialize compressor (IDAT) version error

Wie es aussieht, mag die AVM-Version der libpng15.so nicht mit einer aktuellen zlib-Version 1.2.8 aus der Freetz-Buildchain zusammenarbeiten - ich habe extra für die Fehlersuche mal die Freetz-Version benutzt.

Wenn diese Abhängigkeit bestehen sollte, müßte man wohl auch die libpng.so mit anpassen, wenn man die libz.so in Freetz austauscht bzw. die in der libz.so vorhandenen Algorithmen mal vergleichen.

Da es sich offenbar nicht um ein fehlendes Symbol handelt - zumindest klingt für mich die Fehlermeldung nicht danach, könnte aber natürlich auch ein fehlgeschlagenes dynamisches Laden über libdl.so sein -, würde ich da mehr ein "internes Problem" sehen als eine andere "externe Ausstattung" der libz. Auch die abweichende Dateigröße der libz.so (die von Freetz ist kleiner) legt da das Fehlen von Code nahe.

meiser79 · 2 Jan 2016

Wir tauschen in Freetz doch m.E. nicht die Libs aus, sondern packen die Freetz-Version der entsprechenden Library in /usr/lib/freetz, genau um solche Probleme zu vermeiden.

PeterPawn · 2 Jan 2016

Whoopie schrieb:
Wir tauschen in Freetz doch m.E. nicht die Libs aus, sondern packen die Freetz-Version der entsprechenden Library in /usr/lib/freetz, genau um solche Probleme zu vermeiden.

Auch die libz.so?

Da könnte ich dann einer "Spezialeinstellung" bei mir aufgesessen sein, ich habe "FREETZ_LIBRARY_PATH" tatsächlich (nach einem früheren Hinweis von er13, daß das so möglich wäre - ich will halt einen anderen RPATH haben) auf /lib gestellt, weil ich ja keine Freetz-Images verwende und dann habe ich in dem erzeugten "modified"-Verzeichnis nachgesehen, wo die libz.so.1.2.8 neben der libz.so.1.2.3 von AVM lag und die Symlinks auf die Freetz-Version zeigten. Wenn die von fwmod wegen des abweichenden FREETZ_LIBRARY_PATH dort ersetzt wurden, ist das Thema natürlich für Freetz mit dem gesonderten Verzeichnis schon gegessen ... ich selbst brauche halt für viele Gelegenheiten möglichst identische Libs (um die eben gegen die AVM-Versionen austauschen zu können), wenn ich mich nicht ständig mit "LD_LIBRARY_PATH" herumärgern will. Das generelle Setzen dieser Variablen für eine Shell-Session verhindert(e) dann wieder das korrekte Neustarten des ctlmgr in so einer Sitzung ... die Ursache habe ich auch noch nicht untersucht.

Wenn ich da noch einmal die Abhängigkeiten verfolge, gibt es bis jetzt allerdings auch für mich bei dem zusammengestrichenen Umfang gar keinen Grund mehr, die libz.so überhaupt zu ersetzen. Die Referenzen aus der libneon.so und libxml2.so kann auch die AVM-Version bedienen und die SquashFS-Tools muß ich nur - wie bisher auch - weiterhin statisch linken ... da wollte ich halt etwas "sparen", geht wohl nun (automatisch) nach hinten los. Ist halt blöd, wenn man von der eigenen Toolchain weg will hin zu Freetz ... manchmal sind die Unterschiede diffizil, aber mit erheblichen Auswirkungen - mein Skript zum Kopieren von Programmen inkl. abhängiger Libs war bisher der Meinung, daß solche geringen Differenzen bei den Versionen nichts bedeuten sollten ... wieder was gelernt, wird geändert.

Also, danke für den Hinweis ... bei Gelegenheit versuche ich trotzdem noch, den Unterschied zu finden. Das kann ja nur Konfiguration sein und solange die AVM-Version den von Freetz benötigten Funktionsumfang abdeckt, sehe ich nicht, warum man sie nicht mit einem späteren Stand (desselben Releases) ersetzen sollte, das sind ja i.d.R. mehr Fehlerkorrekturen, die da einfließen.

KingTutt · 5 Jan 2016

KingTutt schrieb:
Ich habe AVM auch einmal eine E-Mail geschrieben und gemäß ihren eigenen Leitlinien den Source Code angefordert. Mal sehen, ob es überhaupt eine Antwort gibt :gruebel:

Gute Neuigkeiten für alle die sehnsüchtig auf den Source Code warten. Ich habe heute Antwort von AVM erhalten.

Code:

...die zuständigen Kollegen sind noch im Weihnachsturlaub, aber wir spiegeln die OpenSourcefiles bis zum Ende der Woche auf den ftp-Server. Spätestens am Freitag finden Sie die Dateien unter...

der bekannten Adresse.

@PeterPawn & er13
dann könnt ihr Euren fähigkeiten wieder freien Laufe lassen

JohnDoe42 · 5 Jan 2016

PeterPawn schrieb:
... vielleicht ist es keine schlechte Idee, diesen Thread hier dann doch zu beerdigen (schon die Eingangsthese stimmt ja nicht mehr seit r13503) und übergangsweise weitere Änderungen für die 06.50 in einem gesonderten neuen Thread zu sammeln.

Gerne, ist auch schon seit längerem meine Idee. Ich wollte bloß den Konstruktionsfluß hier nicht stören ...

Ich setze dann das Präfix mal auf "gelöst", falls einer der Mods es für sinnvoll hält, kann wegen mir hier gerne geschlossen werden.

BenGurion_ · 7 Jan 2016

Sehe ich auch so. Es sollte dann aber auf einen neuen Thread verlinkt werden

PeterPawn · 8 Jan 2016

KingTutt schrieb:
aber wir spiegeln die OpenSourcefiles bis zum Ende der Woche auf den ftp-Server. Spätestens am Freitag finden Sie die Dateien unter...

Irgendwie ist der Upload-Prozess wohl ins Stocken geraten:

Code:

150 Here comes the directory listing.
drwxr-xr-x    2 ftp      ftp          4096 Jan 08 01:03 .
drwxr-xr-x    7 ftp      ftp          4096 Jun 25  2014 ..
[COLOR="#FF0000"]-rw-------    1 ftp      ftp      57442304 Jan 08 01:11 .source-files-FRITZ.Box_7490-06.50.tar.gz.SKgoIO[/COLOR]
-rw-r--r--    1 ftp      ftp      636181659 Oct 18  2013 source-files-FRITZ.Box_7490-05.59.tar.gz
-rw-r--r--    1 ftp      ftp      636184674 Dec 09  2013 source-files-FRITZ.Box_7490-06.01.tar.gz
-rw-r--r--    1 ftp      ftp      636193771 Mar 18  2014 source-files-FRITZ.Box_7490-06.05.tar.gz
-rw-r--r--    1 ftp      ftp      752407631 Sep 16  2014 source-files-FRITZ.Box_7490-06.20.tar.gz
-rw-rw-r--    1 ftp      ftp      752418079 Feb 19  2015 source-files-FRITZ.Box_7490-06.23.tar.gz
-rw-r--r--    1 ftp      ftp      752598382 Nov 20 12:43 source-files-FRITZ.Box_7490-06.30.tar.gz
-rw-r--r--    1 ftp      ftp      752558309 May 21  2014 source-files-FRITZ.Box_7490_Labor-06.10-27948.tar.gz
226 Directory send OK.

Daran ändert sich schon seit geraumer Zeit nichts mehr ... schade. Aber solange das am Freitag noch klappt und man am Wochenende mal draufschauen kann ...

berndy2001 · 8 Jan 2016

es wurde ein neuer versuch gestartet, file ist aber auch nicht komplett.

Code:

-rw------- 1 root root  57344000 Jan  8 10:03 .source-files-FRITZ.Box_7490-06.50.tar.gz.QdRb4Y

PeterPawn · 8 Jan 2016

Vielleicht ist ja der Server voll? :mrgreen:

Dann dauert das noch eine Weile, erst mal eine neue HDD bestellen (bzw. besser gleich zwei, ist ja bestimmt RAID1).

[Gelöst] FW 6.50 für 7490 in Trunk rev. 13490 - keine Auswahlmöglichkeit

IPPF-Urgestein

Mitglied

IPPF-Urgestein

IPPF-Urgestein

Aktives Mitglied

Mitglied

IPPF-Urgestein

Aktives Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

IPPF-Urgestein

Aktives Mitglied

IPPF-Urgestein

Mitglied

Aktives Mitglied

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Statistik des Forums