[Problem] Fritzbox 7362SL keine Funktion mit 6.50 Fw

Hallo Gismotro,
könntest Du mal das Crash- oder Panic-Log publizieren;
einfach FW 06.30 booten und dann per Telnet folgende Befehle absetzen:
"cat /proc/avm_panic_cr" bzw. "/proc/avm_panic_sd"

LG Riverhopper


EDIT: Freetz .config ist in #1 vorhanden

Ok, daß der Inhalt der angehangenen Dateien in #13 (EDIT: Ich meinte natürlich #17, den Beitrag von gismotro) nicht zur Darstellung im Beitrag passen könnte (da steht das "killall telnetd" ja noch deutlich sichtbar im "CODE"-Kasten) ... auf diese Idee bin ich dann doch nicht gekommen.

Nach dem Inhalt der angehangenen Datei wird dann das neue System tatsächlich erfolgreich geschrieben, damit fällt die Idee mit dem Fehler beim Flashen aus und es ist wohl wieder irgendetwas mit der Busybox und dem erzeugten Kernel. Wenn das Dateisystem passen sollte und die Abarbeitung der /etc/init.d/rc.S in die Gänge kommen sollte, würde ziemlich am Beginn schon der Inhalt von "firmware_info" neu geschrieben ... so weit kommt die Box dann wohl schon nicht mehr.

@Laci:
Die nachträglich angehangene Datei habe ich auch erst jetzt zur Kenntnis genommen (das hat sich mit meiner Nachfrage überschnitten und bei einer nachträglichen Änderung gibt es ja auch keine neue Benachrichtigung per E-Mail) ... da war vermutlich noch das Problem der "killall telnetd"-Zeile vorhanden, das die "Überwachung" bis zum eigentlichen Schreiben der Firmware vereitelt hat. Wenn das bei Dir ähnlich wie bei @gismotro ist, dürfte auch dort der Kernel nicht starten (bzw. wahrscheinlich tut er das schon, wenn da 15 Sekunden (zzgl. der 5 Sekunden "EVA time", das ist das Blinken direkt nach dem Start) zwischen den Neustarts liegen. In dieser Zeit sollte der Kernel starten und sich auf die Suche nach seinem FS gemacht haben.

Hier wäre dann jetzt wirklich eine Box mit serieller Schnittstelle die beste Lösung ... dort sollte man sehen können, woran der Start des Systems scheitert. Dem Grund jetzt durch die Kontrolle des Kernels und des "Start-Dateisystems" hinterher zu rennen, ist eher mühsam ... man könnte noch prüfen, ob die Busybox im "wrapper"-Teil (mit den Libs die dort auch liegen) zur Arbeit zu bewegen wäre, wenn man sie herauskopiert.

Ich würde da ohnehin (auch künftig) eher hingehen und auf das Ersetzen der Busybox in der Wrapper-Partition ganz verzichten oder dort eine "universelle" Version verwenden, die gleich statisch gelinkt ist und damit keine Probleme mit fehlenden Libs kriegen kann. Die muß ja nur die ersten Schritte in der /etc/inittab richtig können und das sollte das AVM-Original ja können - es sei denn, das Memory-Management würde für beide /bin/busybox-Inodes (also die Datei in /wrapper/bin und die in /bin - deren Inode-Nummern eigentlich unterschiedlich sein sollten, die aber beim Module-Management wohl beide als "/bin/busybox" bekannt sein werden, weil das "pivot_root" erst erfolgen kann, wenn die erste Busybox-Instanz aus der Wrapper-Partition schon aktiv war/ist) denselben "shared memory content" in die später gestarteten Prozesse mappen ... das kann ich aber irgendwie nicht glauben (müßte es aber auch erst definitiv testen, bevor ich es für unmöglich deklariere).

EDIT:
Wer mal die Idee ausprobieren will, die Busybox in der wrapper-Partition unangetastet zu lassen (nur Theorie, nicht daß jemand denkt, das wären getestete Änderungen meinerseits), der kann folgende Zeilen in der "fwmod" mal auskommentieren:

1041-1043
1054
1096

Wenn ich nichts übersehen habe, wird damit der Austausch der Busybox und der AVM-Libraries in der Wrapper-Partition verhindert und es sollte zumindest bis zum Mounten des Root-Dateisystems weiterlaufen.

Noch mal deutlich: Theoretische Überlegungen ... nicht daß mir jemand hinterher erklärt, ich hätte geschrieben, daß es so definitiv funktionieren würde.

opto schrieb:

Mit diesen Patches kann alles komplett Rückgänig gamcht werden (patschen mit "-R"), hab ich seit langem so in Benutzung: Anhang anzeigen 85899

Zum Vergrößern anklicken....

Ich weiß zwar wegen des "epic fail" (Attachment fehlt - EDIT: zumindest für mich, s. Screenshot) nicht genau, was da als Patch dranhängen sollte ... aber ich bin zugegebenermaßen etwas skeptisch, daß ein "reverse" Patchen (das wäre ja -R) in der Lage ist, den Austausch der Busybox und der dafür benötigten Libraries (das wären im Mimimum die libc, der dynloader ld-irgendwas und die libuclibc - ggf. auch noch die libutil und im schlechtesten Falle sogar die libm, wenn da irgendwelche Arithmetik in der Busybox laufen sollte, die diese Lib auch noch braucht) in der wrapper-Partition rückgängig zu machen. Daher würde mich schon brennend interessieren, was in der fehlenden Datei (oder sind es mehrere) wohl stehen mag.

Anhang anzeigen 85900

@opto:
Ich komme mir zugegebenermaßen etwas veralbert vor ... warum?

1. Ich kann nicht genau erkennen, ob solche Sachen wie "Rainer Blödsinn" nun als Wortspiel (und damit als Scherz) gedacht sind oder tatsächlich ernsthaft gemeint sind und sich in eine Reihe mit "gamcht" und "patschen" stellen lassen.

2. Die 4 Patch-Files in dem tar-File machen ja auch genau nichts anderes, als einige Kommandos (die von mir angeführten Stellen) in der fwmod (dann günstigerweise vor deren Ausführung) zu deaktivieren bzw. wieder komplett zu entfernen.

3. Ich würde noch verstehen, wenn Du den Verweis auf die zusätzlich auszukommentierenden Zeilen 12 und 35-38 in der Datei "patches/scripts/140-remove_uclibc.sh" angebracht hättest, dort würden tatsächlich Links gelöscht, die nicht neu eingerichtet werden nach meinem Testvorschlag ... das verteilt sich (ohne daß direkte Zusammenhänge zu erkennen sind - jedenfalls für mich) an dieser Stelle auf zwei verschiedene Stellen/Verfahren/Zeitpunkte (fwmod und diese 140-remove_uclibc.patch) und ich hatte es übersehen.

4. Nach meiner Ansicht (da darf ja jeder seine eigene haben) ist es für einen Test immer noch einfacher (und effektiver), wenn man tatsächlich weiß, was man da geändert hat und da ist das Auskommentieren von fünf genau angegebenen Zeilen in der einen und fünf weiteren in einer anderen Datei immer noch einfacher und nachvollziehbarer (wie gesagt, meine Ansicht) als das Reverse-Patchen mit irgendwelchen Dateien, deren Inhalt man auch erst einmal unter die Lupe nehmen muß (zumindest dann, wenn man ihn verstehen will).

Insofern würde ich "Vielleicht geht es mit den Patch-Files in dieser Datei sogar einfacher ..." und "Das muß dann so und so ausgeführt werden." sogar noch verstehen ... aber "Rainer Blödsinn" kann mein Vorschlag ja dann doch irgendwie nicht sein, denn die Patch-Files machen am Ende auch nur wenig anderes ... sie entfernen halt noch ein paar Schleifen, die aber beim Auskommentieren vermutlich auch unschädlich sind, weil sie ohnehin dann nur einmal durchlaufen werden (außer ich habe noch etwas anderes Fundamentales übersehen).

Also möge sich jeder selbst entscheiden, ob er nun lieber für den Test die angeführten Stellen auskommentieren will (dann die in der 140-... aus diesem Beitrag oben auch nicht vergessen) oder - nachdem er sich Dein tar-File besorgt hat - die 4 Patches "reverse" ausführen will (die kann er natürlich auch aus dem Freetz-Trac beziehen, wenn er will). Wenn man das regelmäßig macht, hätte ich mir ohnehin schon längst ein größeres einzelnes Patch-File erzeugt, das diese Änderungen dann auch nach jeder Aktualisierung aus dem Trunk erneut vornimmt, ohne daß man auf "merge" verzichten muß oder von Hand event. Widersprüche/Konflikte beseitigen muß - schon deshalb, weil sich dann die Anwendung der Patches auf ein einzelnes unkompliziertes Kommando reduzieren läßt ... was sicherlich auch für diese 4 Dateien als "Einzeiler" machbar ist, aber mit etwas mehr Aufwand, wenn man die Reihenfolge einhalten will/muß.

Vielleicht sollte man für die Zukunft dann trotzdem darüber nachdenken, ob man das Konglomerat aus Libraries und Busybox in der wrapper-Partition überhaupt anfassen muß (das braucht sicherlich auch noch etwas Zeit zum Testen, was das Module-Management da wirklich macht) ... da das ohnehin nur für die ersten zwei Zeilen der /etc/inittab in der wrapper-Partition gelten sollte (außer ich irre mich beim Memory-Management so fundamental und die BB aus der wrapper-Partition würde die aus dem rootfs für die gesamte Laufzeit des Systems quasi überlagern), braucht es da weder eine "full blown"-Version der Busybox noch die ganzen Symlinks für alle Applets in dieser Partition - außer ich übersehe irgendeinen wichtigen Punkt, dann wäre die Frage, welcher das ist.

U.U. paßt @er13 dann auch gleich noch die Zeile 1033 in der fwmod an - im Moment werden dort die meisten Libraries nicht gefunden und in das resultierende System kopiert, wenn "FREETZ_LIBRARY_DIR" nicht auf eines der Verzeichnisse in der "for"-Liste zeigt; ähnliches würde für das Kopieren von "terminfo" und "tabsets" ab 1067 gelten, wenn man die Zielverzeichnisse dafür ebenfalls anpassen könnte: https://github.com/PeterPawn/freetz/commit/125843b9ada5d7b41caa71019a2839d7814dd08a - wobei die "tabset"-Files eventuell ohnehin nicht richtig kopiert werden vom derzeitigen Stand.

Zwar ist diese FREETZ_LIBRARY_DIR-Option ja wohl genau dafür gedacht, daß man auch Pakete für die Verwendung außerhalb von Freetz übersetzen kann ... aber wenn damit jemand aus /usr/lib/freetz nur ein anderes Verzeichnis machen will (wie wäre es denn mit /usr/lib/fratz), wird das resultierende Image mit hoher Wahrscheinlichkeit mangels kopierter Bibliotheken dann auch nicht funktionieren.

EDIT: Wobei ich beim "Trockentest" im Moment ohnehin nicht sehe, daß da mehr als die ld-uclibc und die libuClibc in die wrapper-Partition kopiert werden (Zeile 1041) ... das dürfte spätestens dann scheppern, wenn die Busybox tatsächlich auch noch von der libm abhängt, weil man z.B. "awk" mit entsprechenden Optionen konfiguriert hat.,

@opto:
Ich habe den Sinn und Zweck der 4 Dateien im tar-Archiv ja durchaus verstanden (das sollte aus dem von mir Geschriebenen ja erkennbar sein) ... was ich nicht so richtig sehe, ist der Grund für Dich, da mit "Rainer Blödsinn" (inzwischen stellt sich m.E. die Frage Wortspiel (= lustiger/intelligenter Umgang mit Sprache) eher nicht mehr, dann hättest Du ja bereits Gelegenheit gehabt, das zu bestätigen oder zu erläutern) zu antworten.

Da kann ich Dir dann auch die Nachfrage nicht ersparen, was der (im ersten Teil ja noch interpretierbare, wenn auch ebenfalls nicht so ganz präzise) Satz

opto schrieb:

Der Inhalt mach das Ändern in der Wrapperpatition rückgängig, nämlich genau so wie svn.

Zum Vergrößern anklicken....

im Satzteil nach dem Komma eigentlich aussagen soll.

Liest man das wortwörtlich, kommt man zu der Feststellung, daß SVN das Ändern in der Wrapper-Partition irgendwie rückgängig macht und dann stellt sich wieder die Frage, wie und wann SVN das denn machen könnte, wenn es dann eigentlich ein Programm zur Versionsverwaltung von Projekten ist.

Maximal könnte man ja noch attestieren, daß durch die Patch-Files die Änderungen im SVN, die dann die erzeugte Busybox und die Libraries aus dem Staging-Bereich auch in die Wrapper-Partition kopieren, rückgängig gemacht werden können, wenn man sie richtig anwendet (also gleich mit "-R" startet oder die i.d.R. erfolgende Nachfrage, ob auf "reverse" umgeschaltet werden soll, bejaht).

Das ist aber (zumindest nach meinem Verständnis) schon ein gewaltiger Unterschied und bei allem Verständnis dafür, daß so ein Forenbeitrag keine "große Literatur" sein muß, sollte man doch so schreiben, daß die Aussagen unzweideutig sind - das erspart auch einiges an Zweifeln und Kopfschütteln beim Leser.

Die Begründung "deshalb auch das -R" für die Feststellung "Die Nummrn im Dateiname sind Revisionen" geht irgendwie für mich in dieselbe Richtung ... sie wirft mehr Fragen auf als sie beantwortet. Das "-R" steht bei jedem "normalen" patch-Programm für das "Wechseln der Richtung der Änderungen" (eben "reverse", die bereits vorhandenen Änderungen an den im Patch-File adressierten Dateien werden rückgängig gemacht) - was hat das jetzt damit zu tun, wie die Dateinamen aufgebaut sind? Ich fürchte, bei der Herstellung dieses Zusammenhangs kann ich nicht ganz folgen.

Ansonsten stimmen die Busybox-Versionen von AVM in der Wrapper-Partition und im SquashFS-Image nach meinen bisherigen Erfahrungen überein (auch wenn ich das nicht bei jeder Version explizit neu überprüfe, hatte ich es in den Vorbereitungen und der langfristigen Benutzung des Prinzips von "modfs-Starter" recht ausführlich untersucht) - das wäre m.E. die eine Möglichkeit des Vergleichs der beiden Busyboxen, die Du ansprechen könntest - und den Vergleich der Busybox-Applets zwischen der AVM-Version und der aus Freetz heraus erstellten Version - die andere Variante, die ich mir vorstellen könnte - hatten wir (wenn auch nicht für die 7362SL, sondern für die 7490) erst um Weihnachten 2015 herum als Thema.

Insofern verstehe ich

opto schrieb:

Da bislang niemand die Applets der beiden BB verglichen hat

Zum Vergrößern anklicken....

auch nicht so richtig ... das ändert also irgendwie auch nichts daran, daß ich mir "veräppelt" vorkomme - jenseits des (dankbar aufgenommenen) Hinweises, daß die 140-remove_uclibc.patch ebenfalls angefaßt werden müßte für einen Test.

Diese "Unsicherheit" meinerseits geht bei Deiner Wortwahl in #24 los und endet mit der "Erklärung" in #28 auch noch nicht.

PS/EDIT: Das Thema "Module-Management" und die Eventualität, daß die Busybox in der wrapper-Partition die im SquashFS-Image "überlagern" könnte, habe ich auch nur aus "Rainer Vorsicht" (das ist jetzt Absicht, falls sich jemand wundern sollte) angeführt. Da ich eigentlich schon so lange, wie ich das "modfs"-Prinzip verwende, auch die Busybox im SquashFS-Image durch eine eigene Version ersetze und dabei die Busybox in der wrapper-Partition grundsätzlich bei mir unangetastet bleibt, habe ich mit dem Verwenden unterschiedlicher Busyboxen bislang noch keinerlei negative Erfahrungen gemacht ... aber ich verwende eben auch nicht alle Teile des FRITZ!OS (AHA ist bei mir z.B. komplett außen vor) und daher wollte ich nicht so unvorsichtig sein und das mit absoluter Sicherheit für alle Lebenslagen behaupten.

Ansonsten habe ich bisher noch nie Probleme beim Starten eines Systems gehabt, wenn die Busybox in der yaffs2-Partition eine andere war als die im Wurzeldateisystem des laufenden Systems - daher auch das Plädoyer für eine Abkehr von Änderungen dort, jedenfalls im Rahmen des "normalen" Freetz-Mods ... u.a. auch wegen der (erst nachträglich hinzugekommenen) denkbaren Abhängigkeit von der libm und dem (m.E.) bisher fehlenden Kopieren aller notwendigen Bibliotheken (könnte man ja z.B. mit passendem "ldd" ermitteln).

Daher auch die Überlegung/Fragestellung, ob man dann nicht besser eine weitere "generische" Busybox (mit fester .config bei deren Übersetzung, die der Benutzer auch nicht wirklich ändern kann) und der Beschränkung auf die tatsächlich benötigten Applets - dafür aber statisch gelinkt, weil die dann mit höherer Sicherheit gestartet werden kann - in die yaffs2-Partition einbauen sollte, wenn man es in Freetz schon ändern will (oder vielleicht muß, es wäre ja immer noch denkbar, daß es gute Gründe dafür gibt).

Ich hänge mich mal mit dran, weil mir etwas ähnliches passiert ist...
Ich hatte Probleme mit ipv6 und dachte mir kompiliere ich mal die 06.50 und flashe die...
Nach dem Reboot hing die Box mit einem Dauerleuchten der Power/DSL LED so dass ich recovern musste, im Downloadbereich von AVM hab ich dann die Recover 06.50 gezogen und nach dem Recovern musste ich feststellen dass ich weder ein Image flashen noch sonst wie auf die Box komme um das zu tun (ruKernelTool geht auch nicht).
Bin ich jetzt endgültig ausgesperrt und gezwungen die originale Software zu nutzen?
Ich bin ganz schön sauer und enttäuscht von AVM dass die jetzt solche Wege gehen!

Danke für die Hilfe

Das wäre allerdings vollkommen neu, wenn nach Recovery mit dem AVM-Programm auch der Bootloader aktualisiert würde, so daß auch das ruKernelTool nicht mehr funktioniert.

Das ist zweifellos möglich - es wurde ja auch schon gemacht (also das Überschreiben des Bootloaders) - aber ich würde dann doch eher auf einen Layer8-Fehler tippen.

Nicht alles, was machbar ist, wird AVM auch umsetzen ... wobei ich dann zunächst mal klären würde, ob denn der Bootloader tatsächlich in einer neueren Version geschrieben wurde.

Das findet man dann wieder in den Support-Daten (die aktuelle Version) und die vergleicht man dann einfach mit den Daten, die man sich vorher gesichert hatte (weil ja hoffentlich niemand an das Flashen einer Freetz-Version geht, bevor er sich so richtig schlau gemacht hat, was er da als FRITZ!Box vor sich hat).

Was ich ja richtig gut fände, wäre der FTP-Zugang zur EVA nur dann, wenn der Benutzer in den ersten fünf Sekunden auch noch eine der Tasten gedrückt hat. Das wäre wirklich ein Highlight ... vielleicht fehlt es ja nur an der passenden Dokumentation? Wahrscheinlich aber eher nicht ... jedoch wird man ja noch träumen dürfen.

Jedenfalls dürfte ohne Update des Bootloaders das Versagen des ruKernelTools eher andere Ursachen haben ... über die Frage des Updates mit unsignierter Firmware und das Abschaffen von Downgrades muß man ja nicht erneut diskutieren und bei der 06.50 für die 7362SL steht das explizit in der info.txt drin (Zeile 261). Wer es nicht liest, ist am Ende selbst schuld.

Bei der FB 7362SL funktioniert das normale ruKernelTool nicht.
Es funktioniert nur das noch nicht veröffentliche ruKernelToolX.
Nachrfragen sind sinnlos!!

@Wired_Life:

Frage: Warum machst Du kein Fallback auf das alte Firmware-Image ?
dies sollte bei FB7362SL wie bei anderen NAND-Boxen nach "Update-Flash-Vorgang" noch im alternate Flashspeicher vorliegen;

Umschaltung sollte kein Problem sein; einfach bei Booten in EVA/ADAM2 einloggen und Environment Variable "linux_fs_start" anpassen;

anschließend kann dann in Ruhe ein weiteres Freetz-Image gebacken werden.

LG Riverhopper

Wäldler schrieb:

Bei der FB 7362SL funktioniert das normale ruKernelTool nicht.

Zum Vergrößern anklicken....

Zum Flashen mag das ja sein ... aber um überhaupt erst einmal in den Bootloader zu kommen, sollte man es schon verwenden können, oder?

Ich kenne es (wie mehrfach betont) in aktuellen Versionen nicht mehr ... aber ich kann mich noch gut an die Option "In Adam2 halten" (o.ä.) erinnern und m.E. wurde mehrfach betont, daß das auch bei NAND-Modellen funktionieren soll.

Ansonsten bleibt ja noch der Tipp von @Riverhopper, wobei der natürlich ebenfalls den Zugriff auf den Bootloader voraussetzt ... und der soll ja (nach dem, was @Wired_Life in #30 geschrieben hat) nicht mehr funktionieren. Die Formulierung

Wired_Life schrieb:

noch sonst wie auf die Box komme um das zu tun (ruKernelTool geht auch nicht).

Zum Vergrößern anklicken....

kann man ja eigentlich nicht mißverstehen.

Wenn er noch an den Bootloader kommt, kann er ja auch das Freetz-Image ganz normal über den Bootloader installieren lassen ... wie das funktioniert, ist ja bekannt (und beschrieben) - selbst wenn es bei NAND-Modellen eben anders läuft.

Vielleicht ist es ja auch eine Überlegung wert, wenn man für Freetz eine zusätzliche Einstellung schafft, bei der genau das Image-Format erzeugt wird, welches für das "in-memory image" gebraucht wird (Kernel ohne tichksum + Filesystem als ext2 im Pseudo-SquashFS (ich bleibe aber dabei, daß dort der bisher verwendete Scanner-Code auch direkt ein SquashFS-Image erkennen würde) dahinter, immer noch ohne tichksum). Dann kann man auch hingehen und entweder das alte Perl-Skript zum Update von Linux aus in Freetz wiederbeleben und entsprechend anpassen oder man überlegt sich einen anderen Weg, wie man das auf die Box bekommt. Leider scheidet ein "normaler FTP-Client" ja aus, weil der die zweigeteilte Angabe beim STOR-Kommando normalerweise nicht kennt.

Das würde zumindest dem "Neuling" den Umweg über ein Downgrade auf < 06.50 ersparen ... irgendwann in nicht allzu ferner Zukunft wird es auch albern, wenn man ein Downgrade auf irgendwelche Asbach-Versionen empfiehlt und keiner so richtig weiß, wie er an diese Versionen gelangen soll. Dann läuft am Ende "Suche Firmware" über ...

Ja,"In Adam2 halten",funktioniert auch mit dem normalen ruKernelTool.

Ahhh vielen Dank euch!
Der Trick von Riverhopper hat geklappt.
Wusste gar nicht dass da immer noch das alte System drauf bleibt, das ist echt super!
Bin nicht so tief in der Materie drinne wie ihr, hatte mir eigentlich nur freetz geflasht damit ich per dnsmasq DHCP Server statische IPs vergeben und gucken kann welcher Client das Internet belastet (iftop).
War so dumm und hatte das Image über WLAN geflasht was bisher aber nie Probleme gemacht hat... Naja habs dann nach dem linux_fs_start Trick noch mal über Kabel versucht, aber irgendwie muss das Image nen Ding haben, schade.
Bleiben die Einstellungen eigentlich erhalten wenn man das System mit linux_fs_start wechselt oder werden die immer auf Werk gesetzt?
Hatte ja leider die Recover.exe genutzt die mir alles platt gemacht hat.
Und gibt es eine Option mit der man freetz 06.50 nicht kompilieren sollte? Mein Image ist ja scheinbar fehlerhaft...

Keiner mehr da?

@Wired_Life:
Was erwartest Du jetzt von uns?

Die Geschichte mit "linux_fs_start", den Hintergründen und was man damit machen kann, ist oft genug diskutiert und beschrieben. Wenn Du die entsprechenden Stellen nicht findest, suchst Du vermutlich falsch.

Da nirgendwo steht, wie Du gesucht hast, kann man das schlecht vernünftig einschätzen und somit auch nicht korrigieren, solltest Du dabei Fehler gemacht haben.

Da Du ja sicherlich gesucht hast und dabei nicht fündig geworden bist, steigt die Wahrscheinlichkeit solcher Fehler stark an, denn - viele der hier Antwortenden wissen das recht genau - es wurde genug dazu geschrieben und das läßt sich tatsächlich auch finden ... sicherlich nicht mit einer Trefferliste "1 aus 1", aber das ist auch nicht immer das erstrebenswerteste Ziel, weil es durchaus divergierende Meinungen/Ansätze zur Lösung eines gestellten Problems geben mag/wird/sollte.

Deine zum Ausdruck gebrachte Enttäuschung über AVM (#30) kann man teilen oder nicht, ich selbst habe nicht einmal verstanden, worüber Du nun genau enttäuscht bist - nur von wem dieses einschneidende Erlebnis (ich hoffe, es artet nicht in allgemeinen "Weltschmerz" aus) in Dein Leben getragen wurde und das nehme auch ich AVM übel, wenn man so mit den Hoffnungen und Erwartungen der Kundschaft umgeht und sie einfach enttäuscht. Das macht man nicht ... aber sie werden schon sehen, was sie davon haben.

Wired_Life schrieb:

Und gibt es eine Option mit der man freetz 06.50 nicht kompilieren sollte? Mein Image ist ja scheinbar fehlerhaft...

Zum Vergrößern anklicken....

Anscheinend machst Du Dir ja Gedanken über Dein Image ... wenn Du Dich immer an die Forenregeln und ein paar allgemein zugängliche Hinweise/Erklärungen hältst und hier in halbwegs korrekten Sätzen schreibst, ist Dein Image kaum in Gefahr.

OT: So etwas passiert nur den Leuten, die andere für sich arbeiten lassen wollen und an die Stelle der eigenen Recherche (das sind ja immer zwei, miteinander verknüpfte Schritte ... einmal die Suche und dann sollte noch das verstehende Lesen der Fundstellen dazukommen) lieber die eigene Nachfrage stellen ... sei es in der Annahme, daß vor ihnen noch niemand auf diese Frage gekommen sein kann (schließlich halten sie sich - im Wortsinn - für originell) oder weil sie der Meinung sind, daß es nicht oft genug wiederholt werden kann und schließlich werden sie ja (wenn sie schon nicht der/die Erste mit dieser Frage waren, wird es ja trotzdem niemand künftig wagen, sich auf eine Stufe mit ihnen zu stellen und einfach auch noch einmal dasselbe zu fragen, immerhin ist das ja nach der Antwort auf ihre eigene Frage dann quasi abschließend geklärt) der/die Letzte sein, dem man das noch einmal ordentlich aufbereiten soll (Warum gibt es hier eigentlich so wenige "HowTo"-Threads, fühlt sich denn in diesem Forum niemand dafür zuständig?) und da sollte so eine Ausnahme schon mal drin sein. Selbst nach der schon vorhandenen Antwort suchen, können schließlich immer noch die anderen, die ihnen dann nachfolgen werden - die haben ja auch viel mehr Zeit und sind nicht so "busy", wie man selbst es ist. Draußen ist schönes Wetter, da will man ja nicht in der stickigen Bude vor dem Computer sitzen und seine eigenen Probleme auch selbst lösen ... es gibt schließlich jede Menge kleine Nerds, die ansonsten keine sozialen Kontakte haben und somit tut man am Ende ja noch etwas Gutes, wenn man ihnen das Gefühl vermittelt, sie könnten auch nützliche Mitglieder der Gesellschaft sein. /OT

Bleibt also nur noch eine "Frage" übrig: Ja, natürlich gibt es sehr viele Optionen, die man beim Erstellen eines Firmware-Images über Freetz nicht verwenden sollte ... bis zum Erscheinen von Freetz 06.50 gibt es vermutlich irgendwo dann auch mal eine Liste. Wenn Du bis dahin schon einmal selbst liest, was es so über Freetz zu wissen gäbe (das Wiki dort und die passenden Foren hier sind eine wahre Goldgrube, wenn man nach Informationen fragt sucht), dann bist ja vielleicht genau Du derjenige, der diese Liste erstellt und verwaltet.

Vielleicht kann ja auch mal jemand die Idee aufgreifen (ich glaube, ich habe diesen Vorschlag mal irgendwo gelesen, da ging es aber um die Allianz-Arena und man sollte sicherlich eine Nummer kleiner beginnen) und kostenpflichtige(!) Seminare zu den am häufigsten nachgefragten Themen hier anbieten ... man kann ja schon mal die Anmeldelisten für "early birds" öffnen.

Ich habe es heute noch mal mit der neusten 06.5x im trunk versucht, aber die Fritte ist wieder beim Booten hängen geblieben...
Es kann doch nicht sein dass ich so flashe wie sonst auch und es einfach nicht funktionieren will.
Muss ich irgendwas beachten? Vielleicht dass meine Box von 1und1 gekauft (nicht gemietet) ist und ich erst irgendein block oder branding entfernen muss?
Oder kann man einfach nicht von 06.30 auf 06.5x upgraden?

Die einzigen Sachen die ich vor dem Kompilieren auswähle sind:
Remove tr069
---Remove fwupdate
------Remove httpsdl

Dnsmasq
Dropbear
htop
ifstat
iftop
nmap
tcpdump

Der Rest ist alles auf default.

Hallo zusammen,

ich beziehe mich auf das in #1 von gismotro gemeldete Problem. Bei all den "compile-tested only" Commits ist mir ein dummer Fehler unterlaufen, der dazu geführt hat, dass das Symbol FREETZ_AVM_HAS_EXT2_SQUASHFS4_PACKAGING_SCHEME nicht gesetzt wurde, was wiederum dazu geführt hat, dass das Image zwar korrekt entpackt werden konnte (wegen autodetect) aber danach eben nicht mehr richtig zusammengepackt wurde.

In r13724 habe ich den Fehler korrigiert. Könnte bitte jemand mit 7362 bzw. mit einer anderen Box aus r13724 testen, inwieweit sich das Fehlerbild dadurch verändert hat. Danke!

Grüße,
Gene

Guten Abend in die Runde,

ich kann auch eine positive Rückmeldung geben. Hier läuft die 7362SL samt freetz, dnsmasq und openvpn prima mit 6.50.

Danke @er13

Viele Grüße, Jan Gerrit

Ich kann das nur teilweise bestätigen.
Fritzbox 7362SL, Freetz und die 6.50 mit OPENVPN,DNSMASQ,DROPBEAR herein compiliert.
Es sieht zunächst alles Super aus. Werden jedoch Verbindungen über den (erfolgreich laufenden) Openvpn Tunnel aufgebaut,
verliert die Box alle SIP Registrierungen (Telekom) mit "Die Verbindung mit der Rufnummer 0xxxxx konnte nicht hergestellt werden - Ursache DNS Fehler".
Auch wenn ich ohne DNSMASQ Arbeite, tritt der Fehler immer noch auf. Es scheint als würden dann alle DNS Anfragen von "VOIP" über
den Openvpn geleitet.
Mit der 6.30 trat der Fehler nicht auf und es wurden auch keine Änderungen an der config vorgenommen.
Die Fritzbox läuft als Openvpn im Client Tunnel Mode zu einem NETGEAR-R7000 und Tomato als Openvpn Server.
Es wäre noch zu sagen, dass auf der Server Seite explizit kein "respond to dns" b.z.w. "advertise dns to clients" aktiviert ist.