[Info] FRITZ!Box 7580 - Firmware 153.06.90 - Telnet-Service freischalten (geht auch für 7560 und 7590)

Habe extra nachgeschaut, du meinst vermutlich die PN vom 05.05.2016. Irgendeine Nachfrage nach den Schreibberechtigungen kann ich da nicht erkennen und die Bedingungen, an die du die von Dir vorgestellte "Zusammenarbeit" knüpfst, sind für mich nicht akzeptabel.

Wenn du aber weiter was beitragen möchtest, kannst du gern (so wie jeder andere ohne Schreibrechte) die von dir gewünschten Patches über trac/github push-requests zukommen lassen. Diese werden gereviewed und, wenn alles passt, auch eingepflegt (so wie das mit den Patches passiert ist, die du per PN bzw. in den Forum-Posts hast zukommen lassen).

@Sinnhaftigkeit des Forks:
Entweder mach ein Fork und stelle deine Arbeit den anderen zu Verfügung oder verzichte bitte aufs Prahlen "WLAN Repeater / Powerline Geräte werden in dem nicht offiziellen Fork schon lange unterstützt" und die Aussagen
Halt nur nicht im offiziellen Repo, da einer elitäre Gruppe dort den Deckel drauf hat
Der einzige Grund, warum die Leute es nicht nutzen können, ist, weil du den Code nicht veröffentlicht hast und nicht, weil "eine elitäre Gruppe" diesen nicht aufgenommen hat.
 
  • Like
Reaktionen: lowmaster
Da steht lediglich dass "nicht im offiziellen Repo" verfügbar ist, was ein Hinweis sein sollte. Alles andere ist erfunden.
Nein, da steht etwas anderes als nur ein Hinweis und zwar "nicht im offiziellen Repo, weil ...". Und als Grund hinter "weil" ist etwas angegeben, was zum einen nicht der Wahrheit entspricht (es ist schwer, was aufzunehmen, wenn man es nie gesehen hat) und zum anderen beleidigend ist.

Ich hab über 100 Patches
Wenn alle diese Patches die Qualität des angehängten busybox-Patches haben, dann ist es noch ein weiterer Grund, dir keine Schreibrechte zu geben.
  • schon nach wenigen Sekunden Drüberschauen weiß ich - die Version 1.27.2 wurde auf der Box (zumindest in der per-default den Usern angebotenen Konfiguration) nicht getestet - denn sonst wären einige ab 1.27.x zwingend notwendigen menuconfig selects da
  • mit den kernel-Versionen 2.6.13 bzw. 2.6.19 lässt sich deine Version nicht übersetzen
  • Anpassung von 420-copy_file_dev_node_fix.patch genau verkehrt rum
  • das "local"-Problem in den Freetz-Scripten nur teilweise behoben, für AVM-Scripte gar keine Lösung
  • das "source"-Problem gar nicht behandelt
  • bestimmt sonst noch was

Da ich jeweils noch Kommentar, Changelog und teilweise optionen fürs menuconfig nötig sind würde das einies an Zeit kosten. Unnötig mach ich mir den Aufwand nicht. Mergen wäre auch zeitaufwendig
Das mit Mergen habe ich nicht verstanden. Nach meinem Verständnis, vorausgesetzt du syncst ab und zu mal mit trunk, kommst du ums Mergen nicht herum, egal ob du deinen Code für dich behältst oder dich um die upstream-Aufnahme bemühst. Um deinen Merge-Aufwand zu minimieren, ist es sogar in deinem Interesse sich um möglichst zeitnahe upstream-Aufnahme zu bemühen. Grundsätzlich gilt aber - die upstream-Aufnahme ist immer mit Aufwand verbunden, schon allein wegen des Zukommen-Lassens des Codes bzw. Fragen beantworten, falls diese gestellt werden. Ist also deine Entscheidung, ob du diesen betreiben möchtest.

Wie bereits davor gesagt, kann ich dir versprechen, dich wie jeden anderen User ohne Schreibrechte zu behandeln und allein die Patches bzw. den in diesen enthaltenen Code zu beurteilen und in Abhängigkeit davon die Entscheidung bzgl. "Aufnahme Ja/Nein" zu treffen.

Das würde genau so enden wie mit den sf3978 Packages.
Und vermisst jemand diese? Alles, was davon vermisst wurde, wurde in den trunk aufgenommen. Und wenn jemand immer noch was vermisst, steht es ihm frei, sich um die Aufnahme in den trunk zu bemühen - ein (ggf. auf die aktuelle Upstream-Version aktualisierter) Patch würde dafür ausreichen.
 
Vielen Dank an Peter für diesen Thread.
Ich konnte damit den Telnet Zugang auf meiner neuen 7590 erfolgreich freischalten.
Firmware: 154.06.92
Wichtig zu erwähnen: das "socat" Paket muß installiert sein. Details siehe hier.
Der Abschnitt mit dem Umschalten der aktiven Partition hat bei mir nicht funktioniert.
Auch der FTP Zugiff auf die Box wie hier beschrieben klappt nicht.
 
"socat" steht ja bereits in #1 als Voraussetzung für die Verwendung von "eva_discover".

Warum der FTP-Zugriff auf EVA nicht funktionieren soll, verstehe ich allerdings nicht ... bei der 7590 gilt zwar sicherlich - wie bei der 7580 auch - noch, daß "reboot_status" bereits im Bootloader ausgewertet wird (wenn es nicht doch nur die falschen Initialisierung des Switches ist) und der FTP-Zugriff tatsächlich nur nach "power-off" funktioniert, aber ansonsten haben wir bisher von den 7590-Besitzern eigentlich noch nichts in dieser Richtung gelesen, daß der FTP-Server sich irgendwie anders verhalten würde (mal die Frage mit dem Environment und seiner Quelle - TFFS und/oder FDT - außen vor gelassen).
 
"power-off" - sprich Stecker gezogen - habe ich gemacht. Trotzdem (auch mit HOLD=1) klappte der FTP-Zugriff nicht.

Sorry, die Vorraussetzung mit "socat" hatte ich glatt überlesen.
 
Wie hast Du denn dann die eigene Firmware auf die Box gebracht? Das mit "HOLD=1" ist ohnehin keine empfohlene Lösung, weil die Bootloader alle unterschiedlich auf eine TCP-Verbindung über Port 21 reagieren, wenn dann doch kein FTP-Login erfolgt. Daher funktioniert das nur bei einigen ausgewählten Modellen mit "HOLD=1" problemlos und bei der Windows-Version in PowerShell habe ich ein "richtiges" FTP-Login eingebaut, damit das sauber arbeitet. Da "eva_discover" aber ansonsten nichts von FTP weiß, müßte man dort viel mehr Aufwand treiben.
 
Ich habe mit dem eva_discover Befehl etwas experimentiert, bis ich anhand des LED Status das richtige Timing gefunden habe, bei dem EVA_FOUND=1 zurückgegeben wird. Dann habe ich an dieser Stelle Deine ganze Befehlszeile inklusive eva_to_memory erfolgreich abgesetzt.
 
Hmm ... wenn "eva_to_memory" geht und "eva_discover" auch (oder verstehe ich hier etwas nicht?), dann ist doch alles in Butter? Wenn tatsächlich irgendwann mal "eva_discover" mit "EVA_FOUND=1" endet, wurde die Box ja gefunden. Daß es Probleme mit "HOLD=1" gibt bzw. geben kann, ist allerdings bekannt ... hängt aber eben auch vom jeweiligen Bootloader ab und genau das ist auch der Grund, warum ich normalerweise keine Beispiele mit "HOLD=1" mehr verwendet, sondern immer auf die Möglichkeit der "Verkettung" von Kommandos hinweise.

Ansonsten könnte ich mir nur noch irgendwelche Probleme mit dem Binden von "socat" an die lokale IP-Adresse vorstellen ... denn die muß halt explizit angegeben werden beim "socat", während sich das "nc" das alles selbst sucht.
 
"eva_discover" und "eva_to_memory" haben schließlich auch richtig funktioniert.
Ich wollte nur daufhinweisen, dass ich manuell weder mit "FTP", "nc" noch mit "socat" auf Port 21 zugreifen konnte.
Das hat, wie ich jetzt verstanden habe, wohl am falschen Timing gelegen.
 
Ah ja, jetzt habe ich es dann auch verstanden ... die GRX5-Modelle haben da eine größere Abweichung im Timing, was vermutlich/vielleicht an der Virtualisierung liegt. Im Prinzip muß man bis zum kurzen, gleichzeitigen Aufflackern aller LEDs warten (was bei den GRX-Boxen deutlich länger braucht als bei anderen Modellen) und dann erst geht das Blinken für die EVA-Bereitschaft los und auch die Zeit, in der man den FTP-Server kontaktieren kann. Die Beschreibung im "modfs"-Repository stammt noch aus der VR9-Zeit.
 
  • Like
Reaktionen: Smurfoclob
Bei den FB7581/7582 geht das unsquash nicht mehr:
Code:
# unsquashfs4 filesystem.image
Found TI checksum (0x65555339) at the end of the image.
Reading a different endian SQUASHFS filesystem on filesystem.image
Filesystem on filesystem.image is (4:0), which is a later filesystem version than I support!
#
Hast du da eine neue Version? Oder liegt es an etwas anderem?

EDIT: Bei der FB6890 geht es.
 
Zuletzt bearbeitet:
Ich rate mal, daß Du das wieder auf einer (MIPS-)Box ausführst und die 7581/7582 hat einen ARM-Core und nutzt vermutlich SquashFS4-Images mit LE-Speicherung (daher dann "different endian").

Du kannst mal probieren, das mit einem "ganz normalen" Programm für "unsquashfs" aus irgendeiner x86/x64-Distro zu entpacken (natürlich auf einem passenden Host dann) - wenn es LE ist, sollte das funktionieren und die neuesten Formate bei der Komprimierung (seit 2 Monaten ist da auch "zstd" verbaut im Upstream von SquashFS4) werden sicherlich auch bei AVM noch nicht genutzt.

Eine Version zum Entpacken von LE-Images auf MIPS-Boxen habe ich im Moment nicht im Angebot - im Freetz-Trunk ist zwar seit Anfang November auch ein SquashFS4-LE-Paket enthalten (https://github.com/Freetz/freetz/commit/9fe58a9fcf1e489d5aad88685738245fb4c761e0), aber ich habe für MIPS keine Builds seitdem ausgeführt bzw. schon lange keinen Merge mehr für den Freetz-Master bei mir im Fork gemacht.
 
Ich habe heute die neue INTERN für die FB7580 (153.06.98-50842) getestet und feststellen müssen, daß der NAS (/var/media/ftp) jetzt noexec ist.
Bisher kannte ich nur, daß die USB Geräte mit noexec gemountet werden. Seit wann macht AVM das aber auch mit dem NAS? Für mich die erste FW wo das so ist.
Das geht bei mir gar nicht, da im NAS alle binarys und scripte liegen, auch modfs. Die scripte könnte man ja noch mit sh davor aufrufen, aber die binarys müßte ich dann immer erst in den RAM kopieren ...

Jetzt habe ich schon versucht den NAS neu zu mounten:
Code:
#mount | grep ubi
/dev/ubi0_3 on /var/media/ftp type ubifs (rw,sync,noexec,relatime)

#umount /var/media/ftp/

#mount -t ubifs -o sync /dev/ubi0_3 /var/media/ftp

#mount | grep ubi
/dev/ubi0_3 on /var/media/ftp type ubifs (rw,sync,relatime)
Aber danach ist der NAS gar nicht mehr erreichbar.

Wie muß ich richtig mounten, damit der NAS wieder erreichbar ist?
und
Wo kann ich das ändern, damit es beim booten gleich ohne noexec gemountet wird?
Die udev-mount-sd ist doch IMO dafür nicht zuständig.
 
Zuletzt bearbeitet:
Ich muß mir erst mal die Version in aller Ruhe laden und die Änderungen vergleichen (bin nicht so der Labor-Junkie)... aber normalerweise sollte ein "mount -o exec,remount /var/media/ftp" bereits reichen, dafür muß man gar nichts Komplizierteres suchen.

Das Mounten des NAND-Flashs erfolgt irgendwo in einer "/etc/init.d/Sxx-something" und das auch schon relativ früh ... der wird von verschiedenen AVM-Komponenten ja bereits benötigt. Ich würde mal mit einem "grep" im erwähnten Verzeichnis danach suchen ... das muß irgendwo da sein, wo auch das "recovered=n" ausgewertet wird, weil vor dem Mounten noch entschieden werden sollte, ob die Daten zuerst gelöscht werden oder nicht.
 
Danke! Werde ich bei der nächsten versuchen ...
 
Zuletzt bearbeitet:
Meines Wissens nicht ... bliebe EJTAG, wenn Du die Ausrüstung hast und auf dem PCB irgendwo die Schnittstelle zu finden ist (auf den Bildern von der Bauelemente-Seite ist schon mal keine zu sehen) und man die Informationen dafür irgendwo findet.

Ich habe auch schon lange keine Ausrüstung mehr dafür (die Zeiten, wo man sich die Boxen wirklich zerschießen konnte, sind eigentlich vorbei - schon der damals genutzte LPT-Port würde mir heute Probleme bereiten), vielleicht kann Dir ja @qwertz.asdfgh helfen?

Wobei ich nicht einmal sicher bin, daß man den NAND-Flash tatsächlich auch über die EJTAG-Schnittstelle (als MIPS-Abkömmling sollte der GRX5 eigentlich eine haben) programmieren könnte, denn das ist ja etwas vollkommen anderes als ein NOR-Flash, was direkt über den Data-Bus erreichbar ist. Hier liegt auch der Bootloader im NAND-Flash (mit mehreren Kopien) und der müßte eigentlich gegen Schreibzugriffe so weit abgeschirmt sein, daß er sich aus dem normalen System heraus gar nicht überschreiben läßt.

Wobei ich im Moment da gar nichts finden kann, daß irgendwelche Vorkehrungen gegen das Überschreiben des Urladers (über /proc/mtd) getroffen werden in den Sourcen ... dafür habe ich andere interessante Stellen gefunden, die mich erst mal beschäftigen und abgelenkt haben.
 
Danke, hat sich erledigt. morgen kommt die neue.:)
Mal sehen ob es eine 2,5A oder 3,5A ist.

Hier mal ein Bild von der Rückseite:
IMGP5367a.JPG
Aber du brauchst sie ja nur selber aufzuschrauben. ;)
Ach ne geht ja nicht, du warst doch der ohne Schraubenzieher und/oder den 2 linken Händen? :LOL:

Leicht rechts der Mitte müßte doch der EJTAG sein.
Und unten ganz rechts die Serielle?
 
Zuletzt bearbeitet:
Sieht schon wie ein 2x7-EJTAG-Connector aus ... was die unbestückten Lötpads rechts sein könnten, muß man wohl raten. Theoretisch hätten die Dialog Semiconductor-Chips für DECT auch zwei UART-Schnittstellen.

Oder es sind doch keine seriellen ... aber auf der Vorderseite ist da ja eigentlich weit und breit auch nichts zu sehen außer dem DECT-Chip.

Ansonsten weiß ich zwar, an welchem Ende der Schraubendreher heiß wird, aber meine Zeiten, wo ich alles auseinandernehmen mußte, um die Funktion zu verstehen, sind deutlich vorbei und machten auch nur unter mechanischen Gesichtspunkten so richtig Spaß. Wie so ein PCB funktioniert, sieht man halt so schlecht ...

Die scripte könnte man ja noch mit sh davor aufrufen, aber die binarys müßte ich dann immer erst in den RAM kopieren ...
Wobei Du bei der 7580 auch die Möglichkeit hättest, das mit einem "overlayfs" zu realisieren ... was das ist, steht im Internet und wie das geht (am Beispiel des Hinzufügens eines öffentlichen Schlüssels für die Signaturprüfung zum "/etc"-Verzeichnis), habe ich meinerseits mal in einem Skript gezeigt (https://github.com/PeterPawn/YourFritz/blob/framework/framework/implant_public_key#L250).

Da wird dann mal keine Kopie des gesamten "/etc"-Verzeichnisses erzeugt und mit "-o bind" an die Stelle des Originals gesetzt, sondern ein Overlay über das existierende Verzeichnis gemountet (die Spezialbehandlung für "/etc/mtab" ist nur für das "/etc"-Verzeichnis erforderlich) und dieses ist dann auch beschreibbar, wenn man das möchte. Da man das "upperdir" dabei auch auf einem USB-Stick haben kann (man muß dann nur etwas aufpassen, was die richtige Reihenfolge beim "dismount" im Rahmen von Reboots angeht - man muß also wieder richtig aufräumen beim Herunterfahren) und das "persistent" ist, reicht beim zweitem Mal auch das Mounten mithilfe eines früheren "upperdir" aus, um mit einem Schlag eigene, zusätzliche Dateien zu den überlagerten Verzeichnissen hinzuzufügen (die Inode-Nummern müssen halt passen, steht aber in den Beschreibungen im Internet, wie das genau funktioniert).

[ Man kann das Überlagern theoretisch sogar mit dem "rootfs" machen, wenn man sich in die "/etc/inittab" einklinkt - das sollte man aber erst dann in Angriff nehmen, wenn man ansonsten wirklich keine weiteren Schreibzugriffe auf ein solchermaßen überlagertes Verzeichnis mehr braucht ... sonst wird es recht kompliziert, weil die Prozesse am Ende unterschiedliche Sichten auf das Dateisystem haben, besonders bei den zusätzlichen Mountpoints unterhalb der Wurzel. Allerdings kann man hier (je nach Anwendungszweck) sogar seinen Vorteil draus ziehen ... wenn man wirklich unterschiedliche Namespaces verwenden möchte. ]
 
Zuletzt bearbeitet:
Eignet sich der beschriebene Flashvorgang eigentlich auch, um ein Freetz auf eine 7590 zu bringen?
Ich stehe da jetzt seit ein paar Stunden an und finde den Wald vor lauter Bäumen nicht.

Freetz Image ist kompiliert, der Haken ist, Linux läuft in einer VM (VMWare Player).

7590 ist im Bootloader Modus, krieg ich das Image unter Windows auf die Box?
EVA-FTP-Client.ps1 scheint mir bei einem .image nicht zu helfen, hab keine 4 Files für 4 Partitionen.

Die eva_tools krieg ich aus der VMWare _glaube_ ich nicht zum Laufen, da ich _glaube_ das Netzwerk nicht entsprechend konfigurieren zu können.

Ein Stups in die richtige Richtung wäre nett ...
 
Zuletzt bearbeitet:
Das geht exakt 1:1 auch für die 7590 ... wenn man das "in-memory"-Image nimmt, das von der Freetz-Toolchain erstellt wurde (muß man seit einiger Zeit wohl explizit einstellen, daß man das auch haben will), kann man das problemlos anstelle des selbsterzeugten Images verwenden und in #1 einfach an der Stelle fortsetzen, wo das Patchen der SheBang-Zeilen beschrieben ist.

Man kann das aber genauso auch unter Windows installieren lassen ... ich verstehe nur nicht, was mit "EVA-FTP-Client.ps1" und "4 Files für 4 Partitionen" gemeint sein soll.

Einfach mal auf einen einzelnen Weg festlegen (es geht praktisch auf jedem, sowohl aus der Linux-VM heraus als auch aus Windows, wenn das auf dem VM-Host läuft) und dann systematisch vorgehen ... die Benutzung der Linux-Skripte ist hier in #1 beschrieben und auch die Anwendung der PowerShell-Versionen habe ich hier irgendwo im Unterforum erklärt ... wahrscheinlich im Kontext "Kennwort vergessen" und in einem etwas längeren Text dazu "versteckt".

Link dahin müßte ich selbst erst suchen ... kann aber nicht so schwer zu finden sein und ist eine der wenigen Stellen, wo ich die Skripte ausführlich(er) beschrieben habe. Anders als die Linux-Skripte sind die PS-Skripte auch nicht nur ein "proof-of-concept", der zu trauriger Beliebtheit kam - da stehen auch Kommentare in den Dateien, anhand derer man die Arbeitsweise verstehen können sollte.
 
Zuletzt bearbeitet:
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.