[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Nimm die Beta. Und eine Fehlermeldung bitte im Repo und mit dem Log.
 
Meine FB 7490 steht als Repeater in eine Mesh Umgebung von der FB 7590 Router (FW 7.27 INT).
Jetzt ist die FB7490 automatisch auf die FW 7.26 gebracht, ohne MODFS.
Dadurch habe ich kein Telnet Zugang mehr.

Kein Problem dachte ich, das habe ich früher noch vor gehabt, setze die variable linux_fs_start und komme damit in die vorherige FW 7.21.

Aber was ich auch versuche ich komme nicht mehr in den Bootloader (ADAM2)
Sowohl via cmd oder powershell und ftp 192.168.178.1 einige Sekunden nach dem power on, komme ich niemals in den Bootloader. Nach Zeit, wenn der FB 7490 ganz ist hochgefahren, habe ich dann doch ftp Zugang und auch das Anmelden via Browser Oberfläche. Das zeigt doch das die direkte LAN Verbindung ok ist.

Hat sich da etwas geändert mit der FW 7.26? Ist vielleicht der Zugang zur Bootloader gesperrt worden?
 
[Edit Novize: Überflüssiges Fullquote des Beitrag direkt darüber gelöscht - siehe Forumsregeln]
Aktuell (7.21) zeigt meine Box folgendes an:
FRITZ!Box 7490-B-172403-060231-115663-176417-197902-1130721-81779-avm

Für die 7.27 müsste ich erst nochmal flashen, da ich ja wegen dem nicht funktionierendem telnet die Box auf 7.21 zürückgesetzt habe.

Würde es dann gerne mit der beta versuchen, falls 0.64 die aktuelle beta ist.
 
Zuletzt bearbeitet von einem Moderator:
@alfa_ajx732 :
Da hat sich eher nichts geändert - zwar ist die 07.26 sehr schnell wieder vom Markt verschwunden, weil die 07.27 nachgeschoben wurde, aber ein Urlader-Update über das "normale" Image ist bei AVM auch eher selten.

Zum Suchen der Box gibt es die entsprechenden Tools (eva_discover bzw. EVA-Discovery.ps1) - bitte hört endlich mit diesem Unsinn auf, die startenden Boxen immer mit dem "richtigen Timing" zu erreichen. Es gibt Gründe, warum auch das AVM-Recovery-Programm richtig(!) nach der startenden Box sucht ... das könnte (wenn es Lust hat, nicht zuverlässig zu funktionieren) auch irgendwelche TCP-SYNs an 192.168.178.1:21 senden und hoffen, daß eines davon schon ankommen wird. Genau das macht es aber nicht ... u.a. sicherlich auch, weil schon die Annahme mit der 192.168.178.1 in einer Mesh-Konfiguration Blödsinn ist, falls der Edge-Router dort die 192.168.178.1 benutzt.

In einem LAN, was tatsächlich noch diesen "Standardwert" von AVM nutzt, muß man natürlich auch ein anderes IP-Segment verwenden, wenn man eine andere FRITZ!Box kontaktieren will ... das habe ich alles mal versucht zu erklären in den entsprechenden Threads zum Recovery-Programm. Hier setzt man einfach sein Netzwerkinterface auf irgendeine (passende) Adresse oder ändert die Verkabelung so, daß tatsächlich nur der Rechner und die Box über einen Switch verbunden sind - dann kriegt auch ein Windows-PC (in der Grundeinstellung) seine APIPA-Adresse und das Recovery-Programm (danach gestartet) paßt die Broadcasts entsprechend an. Das kann man natürlich auch von Hand beim Aufruf eines der Discovery-Skripte machen ... man muß nur zuvor die automatisch zugewiesene Adresse ermitteln.

@webspyder:
yourfritz.de/modfs-0.6.4-beta.tgz ist richtig ... bisher ist der modfs.tgz-Symlink immer noch die modfs-0.6.3.tgz und da ist die Änderung der abgefragten Variablen für die "versteckten Funktionen" noch nicht enthalten - also geht da auch die Aktivierung über die Telefon-Codes (steht alles hier irgendwo) noch nicht.

Und noch einmal an alle ... bitte das Repo nutzen. Darum bitte ich jetzt schon seit dem Beginn des Jahres und es gibt noch nicht einen einzigen Beitrag dort - weder als "Discussion" noch als "Issue", wobei es schon richtig ist, erst mal das Problem zu klären (Discussion) und danach einen Fehlerbericht (Issue) daraus zu machen.
 
Aktuell (7.21) zeigt meine Box folgendes an:
FRITZ!Box 7490-B-172403-060231-115663-176417-197902-1130721-81779-avm
Ja, wenn telnet geht wird da nix weiter angezeigt.
Wir brauchen die Anzeige wenn telnet nicht geht.
Dann müßte da etwas mehr kommen.
 
Und noch einmal für all diejenigen, die eine zweite FRITZ!Box in ihrem Netzwerk haben und diese auch erreichen wollen, ohne erst irgendwelche Kabel umstecken zu müssen (wobei diese zweite Box jetzt der Einfachheit halber bitte auch mit einem Ethernet-Kabel angeschlossen ist und nicht nur als WLAN-Bridge - in EVA funktioniert kein WLAN): Nehmt bitte einfach das für Euer OS passende Discovery-Skript und startet das mit den richtigen Parametern ... nämlich einmal Eurer eigenen IP-Adresse (beim PS-Skript nur selten erforderlich, solange der Rechner nicht mehrere Interfaces hat) und - das ist das Entscheidende - der auch ansonsten von dieser zweiten (oder dritten oder vierten usw.) Box verwendeten Adresse als "Ziel". Dann wird auch der Bootloader so eingestellt, daß die Box unter dieser IP-Adresse erreichbar ist und sie beißt sich nicht mit irgendwelchen anderen FRITZ!Boxen - und alles das auch, ohne daß man die Verkabelung (in > 95% aller Fälle) anfassen müßte.

Wenn das aus irgendeinem Grund nicht funktionieren sollte, ist es allemal auch schlauer, nach der echten Ursache des Problems zu suchen (von falschen Parametern bis zu irgendwelchen Firewall-Einstellungen oder gar vorgeblichen "Security-Suites"), als sich dann auf irgendeinen anderen Weg stürzen zu wollen. Dieses Vorgehen ist wirklich das Einzige, was den Erfolg (ich wage die Behauptung: zu 100%) garantiert und alle die Probleme, die ein zuverlässiges Auffinden einer startenden FRITZ!Box verhindern, werden nur mit sehr, sehr viel Glück bei einem anderen Vorgehen keine weitere Rolle spielen.

Haltet Euch einfach an die entsprechenden Schritte und die allermeisten Probleme treten gar nicht erst auf bzw. liegen dann tatsächlich am verwendeten PC und was dabei zu beachten ist, ist nun wirklich oft genug beschrieben.
 
Lasse gerade 0.6.4-beta laufen, sobald die Box gestartet ist, kommt die Info

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Also, die beta ändert nichts. Telnet geht nicht
System_Status zeigt:

FRITZ!Box 7490-B-182403-060300-115663-176417-197902-1130727-88562-avm
Unable to detect environment setting 'CONFIG_BUILDTYPE=998'.

Ich hab das modfs im Debug-Modus laufen gehabt, aber keine offensichtlichen Fehlermeldungen. Die debug-Datei habe ich vorliegen...

Mache gerne eine Discussion im GitHub auf, muss mich dort erst registrieren...
 
Zuletzt bearbeitet von einem Moderator:
Dann aktiviere mal das modscript mod_enable_calllog mit.
 
OK, dann muss ich aber wohl erst einmal wieder auf 7.21 zurück, denn auf die Box komm ich nicht mehr...
 
Ich habe in der rc.user immer ein "/usr/sbin/telnetd -l /sbin/ar7login" mit drin stehen und damit wird das telnet fast immer zuverlässig gestartet.
 
Zuletzt bearbeitet:
wieder auf 7.21 zurück
Das sollte ja kein Problem sein, wenn man den Boot-Manager mit einbauen läßt.

Und ich verweise noch einmal darauf, daß die ganze Geschichte mit den Änderungen an den Variablen zur Erkennung der "Inhouse-Versionen" (nur da gehen die Codes bzw. der Telnet-Start noch) hier auf den letzten Seiten steht ... die Änderung in der mod_enable_calllog sogar direkt auf der vorherigen Seite. Ich schreibe die vorgenommenen Änderungen ja (hoffentlich) nicht umsonst so ausführlich nieder - wenn das niemand liest oder lesen will, kann ich mir das künftig auch schenken.
 
Ich habe in der rc.user immer ein "/usr/sbin/telnetd" mit drin stehen und damit wird das telnet fast immer zuverlässig gestartet.

Nur um sicher zu gehen, die rc.user ist in /etc/init.d, oder?
Hatte vergessen, das volatil.../var/tmp/rc.user...


Das sollte ja kein Problem sein, wenn man den Boot-Manager mit einbauen läßt.

Und ich verweise noch einmal darauf, daß die ganze Geschichte mit den Änderungen an den Variablen zur Erkennung der "Inhouse-Versionen" (nur da gehen die Codes bzw. der Telnet-Start noch) hier auf den letzten Seiten steht ... die Änderung in der mod_enable_calllog sogar direkt auf der vorherigen Seite. Ich schreibe die vorgenommenen Änderungen ja (hoffentlich) nicht umsonst so ausführlich nieder - wenn das niemand liest oder lesen will, kann ich mir das künftig auch schenken.
Sorry, PeterPawn, aber manchmal sieht man den Wald vor lauter Bäumen nicht, und Bäume gibt es hier wahrlich viele;-)
 
Zuletzt bearbeitet:
Nur um sicher zu gehen, die rc.user ist in /etc/init.d, oder?
Nein, dort steht die rc.conf.
Ich meine die eigene Datei unter /var/tmp/rc.user.
Die muß aber noch nach /var/flash transferiert werden mit edit_rcuser.
 
So, jetzt klappt zwar telnet, aber Benutzername und Passwort (wie vorher) klappen nicht.
 
Zuletzt bearbeitet:
[Edit Novize: Überflüssiges Fullquote des Beitrag direkt darüber gelöscht - siehe Forumsregeln]
????
Ich hatte da bisher immer den Benutzernamen, der in der Fritzbox als Admin eingetragen ist. Ich hab den "Standard-Admin" umbenannt. Was ist denn fritzxxx ??? Hab ich da was verpasst?
 
Zuletzt bearbeitet von einem Moderator:
Was ist denn fritzxxx ???
Wenn ich bisher keinen Benutzer angelegt hatte und nur mit PW rein bin,
dann hat die FB jetzt einen Benutzer dafür angelegt, der fritz1234 z.B. heißt.
Aber dein alter Admin sollte gehen. Loggst du dich mit dem auch in der GUI ein?
 
Was soll denn "jetzt klappt zwar Telnet" genau heißen?

Wie wäre es denn mit einer GENAUEN Beschreibung (auf die erbetenen Log-Dateien mag ich schon gar nicht mehr hoffen) dessen, was da gemacht wurde? Ich tippe einfach mal darauf, daß nur ein "telnetd" in irgendein Skript eingebaut wurde und damit der Daemon OHNE die korrekten Parameter gestartet wird.

Irgendwie macht das als "Ping-Pong"-Spiel nur wenig Sinn bzw. das ist seit Mitte der Siebziger aus der Mode (als "Telespiel") ... ist es tatsächlich sooo schwer, die Probleme und das bisherige Vorgehen "ordentlich" zu beschreiben?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.