FB 6591 verschiedenes

[PeterPawn]

die Logfile mit dem frisch hochfahrenden System hier abgelegt.

Hier haben wir mal wieder ein sehr schönes Beispiel dafür, warum Links zu irgendwelchen Protokolldateien auf externen Plattformen absoluter Bullshit sind. Das betrifft eben auch nicht nur den o.a. Link, sondern alleine auf dieser der vorhergehenden Seite sind es drei davon - weiter habe ich gar nicht erst gesucht.

Solange man diese Veranstaltung hier im IPPF nicht nur als "Support für Einzelne" begreifen will, sondern als ein Medium, wo man sich über mögliche Probleme austauscht und zwar so, daß auch spätere Leser noch etwas davon haben, ist das absolut kontraproduktiv - oder wie soll sich jetzt jeder weitere Leser ein Bild davon machen, bis wohin die erwähnte Reboot-Schleife nun ging bzw. was im Backtrace vor dem Reboot noch geloggt wurde?

Ist hier schon mal jemand darauf hingewiesen worden, daß irgendwelche Protokoll-Dateien "nicht erwünscht" wären als Anhang für einen eigenen Beitrag - zumal die max. Größe bei pastebin.com nun üblicherweise auch noch 512 KB sind (10 MB sind's nur mit einem "pro account"), was meines Wissens weit unterhalb der Grenze dessen liegt, was hier als Größe für einen Anhang akzeptiert wird? Warum muß man dann solche Daten bei einem externen Dienst hinterlegen - zumal man hier auch noch wunderbar sehen kann, wie dadurch "orphaned links" geradezu forciert werden?

Oder warum löscht man als derjenige, der solche Dateien veröffentlicht hat, diese dann wieder, nachdem das eigene Problem "erledigt" ist? Denn bei pastebin.com kann man ja i.d.R. nur Inhalte löschen, die man unter einem eigenen Account erstellt hat oder sie verschwinden von alleine, wenn man beim Erstellen bereits ein Verfallsdatum vorgegeben hat - beides erfordert aber (soweit ich das kenne, ich lasse mich ja gerne korrigieren) vorsätzliches Handeln und es sind ja noch nicht einmal vier Wochen vergangen, seitdem diese Links hier veröffentlicht wurden.

Ich würde es halt gerne verstehen ... im Moment fällt mir selbst jedenfalls keine plausible Erklärung dafür ein.

 

[eisbaerin]

alleine auf dieser Seite sind es drei davon

IMO nur einer in deinem Zitat. DuW

Oder bist du schon so genial, daß du 19 Beiträge in die Zukunft schauen kannst?

 

[PeterPawn]

Stimmt, das war dann auf der vorhergehenden - jetzt muß ich mal suchen, welchen Beitrag ich dort "zum Löschen melden" kann, damit ich doch noch recht behalte.

Oder ich korrigiere das dann doch noch oben ... ist irgendwie "fairer".

 

[Brenner Willi]

Hallo wollte mal fragen wie ich das Freetz auf die 6591 drauf bekomme ist meine Box von mir im Laden gekauft
gibt es da eine Anleitung bei der 6490 habe ich das mit TC gemacht wie ist das mit der 6591 geht das schon überhaupt
habe so viel gelesen bin aber nicht schlauer geworden
Danke MFG Frank

 

[Flole]

Dann solltest am besten nochmal lesen, insbesondere die Seiten 2 und 5 sind vielleicht "wertvoll". Zumindest wenn man schon ein Image generiert hat....

 

[tommes604]

Hallo @fesc ,
danke für die super Arbeit in diesem Forum.

Ich habe gerade für meine 6591 die Firmware gebaut:

Output vom Build:
--
PACK firmware-update.uimg
/home/ffritz/build/puma7/uimage/part_02_ATOM_KERNEL.bin size=9437184 crc=0xa8050479
/home/ffritz/build/puma7/uimage/part_03_ATOM_ROOTFS.bin size=29884416 crc=0xeb33b8c9
/home/ffritz/build/puma7/uimage/part_08_ARM_KERNEL.bin size=2761984 crc=0x4393f696
/home/ffritz/build/puma7/uimage/part_09_ARM_ROOTFS.bin size=15757312 crc=0xdc360975
/home/ffritz/build/puma7/uimage/part_10_GWFS.bin size=870400 crc=0x56d1a825
PACK /home/ffritz/build/puma7/fb6591_7.21-28.tar
--

Laut der Readme https://bitbucket.org/fesc2000/ffritz/src/6591/README-6591.md
gibt es nur vier .bin Dateien, jedoch kommt in diesem Build noch die Datei

part_10_GWFS.bin

hinzu. Ich möchte (und kann) meine Box laut Bios via ftp flashen.

Wie ist mit der part_10_GWFS.bin zu verfahren - ignorieren oder auf welche Partition muss diese abhaengig von der aktiven Bootbank geschrieben werden?

Meine Box sagt als OEM avm obwohl sie eine Providerbox von Pyur ist - ist dann der Oem Patch überhaupt sinnvoll/notwendig?

Beste Grüße & Danke
Tommes

 

[fesc]

Diese partition kann man via ftp nicht programmieren, sie ist aber auch nicht wirklich relevant. Letztlich ist das der Inhalt des install tarfiles u.A. mit den Versionsinformationen.
Um das auch noch zu programmieren kann man nach dem initialen flashen über eva nochmal eine "richtiges" update mittels shell und burnuimg machen.

Der patch ist nicht nötig wenn firmware_version schon avm ist.

 

[Brenner Willi]

Dann solltest am besten nochmal lesen, insbesondere die Seiten 2 und 5 sind vielleicht "wertvoll". Zumindest wenn man schon ein Image generiert hat....

Habe nichts lesen können wie ich das genau machen kann
gibt es eine genaue Anleitung danke
mfg Frank

 

[tommes604]

Der patch ist nicht nötig wenn firmware_version schon avm ist.

Habe beide Varianten probiert mit verschiedenen ftp-Programmen - leider kein Erfolg.

FYI:
3.12.74
DMC RTL=n
HWRevision 233
HWSubRevision 8
ProductID Fritz_Box_HW233
SerialNumber XXX
annex Kabel
autoload yes
bootloaderVersion 1.3614
country 049
crash [0]0,0,0[1]28e96702,5f90b85d,6[2]0,0,0[3]0,0,0
firstfreeaddress 0x3D3C4C00
firmware_info 161.07.13
firmware_version avm
language de
linux_fs_start 0
.....
[ 0.000000] DMI: Intel Corporation PUMA 7 C0 PLATFORM/TBD, BIOS CGM2.86C.627075.R.1910091149 10/09/2019

Trotz dem korrekten Bios scheint es bei dieser Box (Mat. 20002844 - Pyur) keine Chance via FTP zu geben:

yafc [email protected]:~> put --output=mtd\; part_03_ATOM_ROOTFS.bin
Command not implemented

Gibt es bekannte Erfolge bei einer ähnlichen Pyur Box?

 

[PeterPawn]

Wie wäre es denn, wenn Du es anstelle irgendeines FTP-Clients (und yafc ist schon für sich ziemlich "exotisch") einfach zunächst mal mit "raw commands" (z.B. innerhalb einer "nc"-Session) versuchst und überprüfst, ob die Meldung tatsächlich von einem "501" aus der Box her rührt (und die generelle Reaktion auf ein "STOR" - obendrein auch noch nach entsprechendem "PASV" - ist) oder doch von irgendwelchen Präliminarien stammt, die yafc da erst mal "abhandeln" möchte und mit denen der (sehr rudimentäre) FTP-Server nichts anfangen kann?

Es ist zwar nicht unmöglich, daß diese Box tatsächlich noch einen "ganz besonderen Bootloader" hat - aber die Wahrscheinlichkeit ist (nach meiner Ansicht zumindest) eher gering und so sollte man die Ursache für auftretende Probleme als erstes beim eigenen Verständnis und beim eigenen Vorgehen suchen und nicht (zumindest nicht bis zum "Beweis", daß es tatsächlich so ist und den erbringt man eher mit einem Test "von Hand" und nicht mit vielen weiteren FTP-Clients, die alle irgendetwas anderes machen) gleich davon ausgehen, daß am Ende die Box schuld sein MUSS.

Es gibt genug FTP-Clients, die von sich aus erst mal versuchen, "smart" zu sein und bei einer Übertragung einer Datei zunächst mal ergründen wollen, ob die vielleicht am Ziel schon existiert - schon da würde der FTP-Server in der Box abwinken. Und yafc gehört (wenn ich mich richtig erinnere) zu diesen Kandidaten, die sowohl "globbing" als auch "resume" und Rekursionen bei einem "put" unterstützten - dazu muß der FTP-Client aber selbst jede Menge Infos vom Server sammeln (bis hin zum Anlegen von Verzeichnissen, wenn rekursiv kopiert werden soll) und für all das braucht es FTP-Kommandos, von denen dieser rudimentäre FTP-Server in EVA gar keinen Schimmer hat.

mit verschiedenen ftp-Programmen

Nun weiß natürlich hier niemand, was damit genau gemeint sein könnte ... aber wenn yafc da auch in der Auswahl war und diese "verschiedenen" alle von demselben Kaliber waren, dann hast Du vermutlich die Informationen aus diesem Board nicht wirklich gut und intensiv gelesen. Es ist zwar nur für "yafc" zu sehen und ich habe es tatsächlich noch nicht selbst damit probiert (der ist so alt, den kennt fast niemand mehr - und ich werde es deshalb auch mal nicht prüfen, sondern mich auf mein Gedächtnis verlassen) - aber ich würde fast Wetten darauf abschließen, daß der als potentieller Client für den FTP-Zugriff auf EVA eine der schlechtesten Wahlmöglichkeiten war, weil er selbst versucht, viel zu "intelligent" zu sein und Details des FTP-Protokolls vor dem Benutzer zu verstecken.

 

[tommes604]

Wie wäre es denn, wenn Du es anstelle irgendeines FTP-Clients (und yafc ist schon für sich ziemlich "exotisch") einfach zunächst mal mit "raw commands" (z.B. innerhalb einer "nc"-Session) versuchst und überprüfst, ob die Meldung tatsächlich von einem "501" aus der Box her rührt (und die generelle Reaktion auf ein "STOR" - obendrein auch noch nach entsprechendem "PASV" - ist) oder doch von irgendwelchen Präliminarien stammt, die yafc da erst mal "abhandeln" möchte und mit denen der (sehr rudimentäre) FTP-Server nichts anfangen kann?

Ich habe mich zuerst strikt in die Anleitung / Empfehlung gehalten und den standard ftp client von debian(stretch) und ubuntu(18.04) verwendet (beides via wsl2 bzw. wsl1). Beide clients haben leider nichts gebracht - nach dem ersten put meckern beide instant rum. Danach habe ich es mit ncftp (put -z probiert) und zum Abschluß halt yafc.

Ich kann gerne noch ein paar Protokolle mitschneiden.

 

[PeterPawn]

Mach's doch erst mal wie von mir vorgeschlagen ... die Kommandos von Hand eingeben (also ohne FTP-Client) und dann die Reaktion der Box darauf protokollieren.

Daß Du nun ausgerechnet yafc als "Beispiel" für den verwendeten FTP-Client genutzt hast, ist halt Pech - wie geschrieben: Ich würde wetten, daß es damit nicht funktionieren KANN.

Ansonsten gibt es ja auch - jenseits der "kompletten FTP-Clients" - ein paar Implementierungen, die sich speziell mit den Eigenheiten von EVA auskennen und die protokollieren dann auch die (FTP-)Session einigermaßen genau. Wenn ich hier etwas von "WSL1" oder "WSL2" lese, frage ich mich natürlich auch gleich, warum man das dann nicht gleich mit der PowerShell machen sollte und was hier der "Umweg" über einen FTP-Client bringen sollte.

 

[tommes604]

Ansonsten gibt es ja auch - jenseits der "kompletten FTP-Clients" - ein paar Implementierungen, die sich speziell mit den Eigenheiten von EVA auskennen und die protokollieren dann auch die (FTP-)Session einigermaßen genau. Wenn ich hier etwas von "WSL1" oder "WSL2" lese, frage ich mich natürlich auch gleich, warum man das dann nicht gleich mit der PowerShell machen sollte und was hier der "Umweg" über einen FTP-Client bringen sollte.

Ich versuche so gut es geht mich am Setup von fesc zu orientieren...
Ich habe es nun mit netcat versucht und ja der ftp Daemon reagierte auf STOR.
Danach habe ich noch etwas mit dem normalen ftp ausprobiert und musste feststellen das der Schreibvorgang startet sofern ich nicht den Punkt vier der Anleitung ausführe: GETENV linux_fs_start sondern direkt
mit dem put des ersten Imagefiles beginne. Scheinbar kommt der Daemon in der Session durch das GETENV durcheinander.
Sehr guter Hinweis, danke!

mit GETENV:

ftp> bin
200 Type set to BINARY
ftp> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> passive
Passive mode on.
ftp> quote GETENV linux_fs_start
linux_fs_start 0
ftp> put part_03_ATOM_ROOTFS.bin mtd;
local: part_03_ATOM_ROOTFS.bin remote: mtd;

Passive mode refused.
ftp> put part_03_ATOM_ROOTFS.bin mtd;
local: part_03_ATOM_ROOTFS.bin remote: mtd;
200 GETENV command successful
Passive mode address scan failure.Shouldn't happen!
ftp> put part_03_ATOM_ROOTFS.bin mtd;
local: part_03_ATOM_ROOTFS.bin remote: mtd;
227 Entering Passive Mode (192,168,178,1,176,130)
227 Entering Passive Mode (192,168,178,1,176,130)
ftp>
............

Ohne GETENV:
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:tommes): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> bin
200 Type set to BINARY
ftp> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> passive
Passive mode on.
ftp> put part_03_ATOM_ROOTFS.bin mtd;
local: part_03_ATOM_ROOTFS.bin remote: mtd;
227 Entering Passive Mode (192,168,178,1,176,130)
150 Opening BINARY data connection
226 Transfer complete
29880320 bytes sent in 271.82 secs (107.3522 kB/s)
ftp> put part_02_ATOM_KERNEL.bin mtd<
local: part_02_ATOM_KERNEL.bin remote: mtd<
227 Entering Passive Mode (192,168,178,1,7,213)
150 Opening BINARY data connection
226 Transfer complete
9437184 bytes sent in 90.07 secs (102.3244 kB/s)
ftp> put part_09_ARM_ROOTFS.bin mtd=
local: part_09_ARM_ROOTFS.bin remote: mtd=
227 Entering Passive Mode (192,168,178,1,217,91)
150 Opening BINARY data connection
226 Transfer complete
15757312 bytes sent in 140.42 secs (109.5851 kB/s)
ftp> put part_08_ARM_KERNEL.bin mtd>
local: part_08_ARM_KERNEL.bin remote: mtd>
227 Entering Passive Mode (192,168,178,1,127,37)
150 Opening BINARY data connection
226 Transfer complete
2761984 bytes sent in 23.48 secs (114.8750 kB/s)
ftp> quote SETENV linux_fs_start 1
200 SETENV command successful
ftp> quote REBOOT
221 Thank you for using the FTP service on ADAM2


Leider kommt das Fritz!OS 7.21 trotzdem nicht hoch.

Nach dem quote REBOOT geht die Box vom Netz (kein ping), nach 10 Minuten habe ich sie vom Storm genommen, danach startet dann wieder das alte OS 7.13.

 

[fesc]

DMC RTL=n

Das ist also eine nicht-retail box mit firmware_version=avm. Ich meine mich zu erinnern dass eine solche in diesem thread oder forum schon mal vorkam, und auch ein patch der die Erkennung wegmacht.
Das flashen an sich hat wohl funktioniert.
Wenn das image von meinem repository gebaut ist, dann schau mal ob die version aktuell ist, da war zwischendurch ein kleiner bug drinnen.

Oder eine retail-box kaufen.

 

[tommes604]

Oder eine retail-box kaufen.

Ich habe noch etwas rumgespielt: ich habe das Spiel mit dem Bootbank-Wechsel ein paar mal via ftp versucht ohne Erfolg.
Mit leichter Frustation habe ich mir noch einen Gnadenschuss via netcat erlaubt und siehe da auf einmal bootete die Box mit der 7.21.
Vielen Dank für eure Hinweise - super Arbeit!

PS: was für einen Patch meinst du - den oem Patch oder einen speziellen anderen? Ich hab das ganzen Thread dieser Tage überflogen und kann mich an nichts dergleichen erinnern?!

 

[Flole]

Ein RTL=y-patch bringt im Prinzip doch gar nichts. Klar, man kann (ein) Update(s) übers Webinterface einspielen, die dann den Patch nicht mehr enthalten und damit verbaut man sich die Möglichkeit in der Version wieder. Und für eine Möglichkeit einmalig per Webinterface aktualisieren zu können finde ich das alles ziemlich unsinnig. Der einzige Grund so etwas zu tun der mir einfällt wäre die Box so als freie Box zu verkaufen und dann ist der Käufer beim ersten Update danach der Dumme (bzw. er merkt es erst beim zweiten wenn er nach dem ersten nicht mehr schaut obs die Option gibt weil man die ja sonst nicht braucht). Man selbst ist in der Zwischenzeit schon "über alle Berge". Darüber wie legal (oder eher illegal) das ganze ist brauchen wir wohl nicht zu reden, aber vielleicht darüber ob es nicht doch noch einen anderen Vorteil gibt den ich grad einfach übersehe (und damit auch einen legales Ziel was durch den Einsatz eines solchen Patches erreicht wird). Dann könnte man auch mit einem guten Gewissen helfen.

 

[tommes604]

Man selbst ist in der Zwischenzeit schon "über alle Berge". Darüber wie legal (oder eher illegal) das ganze ist brauchen wir wohl nicht zu reden, aber vielleicht darüber ob es nicht doch noch einen anderen Vorteil gibt den ich grad einfach übersehe (und damit auch einen legales Ziel was durch den Einsatz eines solchen Patches erreicht wird). Dann könnte man auch mit einem guten Gewissen helfen.

Deine Argumente machen definitiv Sinn. Ich selbst habe die Box über den Flohmarkt erworben in Erwartung das diese frei und Updatefähig ist. Das es über diesen Weg nun funktioniert macht mich soweit happy und wenn es keine weiteren Nachteile hat, kann ich damit definitiv leben die Updates weiterhin manuell durchzuführen - zudem die Box ja nun auch ein paar extra Features hat.

 

[Knogle]

Ich grüße euch Freunde. Habe nun auch eine Retailbox und bin auch sehr bastelfreudig unterwegs gewesen und habe Geräte auf OpenWRT geportet. Nun scheint das hier ja ein anderes Kaliber zu sein mit Atom Architektur, echt überrascht dass das keine MIPS Büchse ist.
Nun bin ich auf der Suche nach einem "Modem" bzw. möchte der Fritzbox beibringen als Modem oder im Bridge-Mode zu arbeiten. Ich möchte nicht auf die Standardlösung der schwer zu bekommenen DOCSIS 3.1 Modems ausweichen sondern zumindest mal ein bisschen Ausprobieren.
Meint ihr es ist möglich über UART eine root Konsole reinzukriegen, oder gibt es andere Möglichkeiten Zugriff zu bekommen? Gibt es bereits Custom-FWs welche ggf. solch eine Funktion schon mitbringen?

 

[Flole]

Du solltest vielleicht einfach mal diesen Thread lesen. Es ist auch nicht nur eine Atom CPU sondern eine Atom/ARM Kombination.

 

[jha4711]

Meint ihr es ist möglich über UART eine root Konsole reinzukriegen

Mit diesem Post auf Seite 2 könnte Deine "Reise" zu einer eigenen Firmware mit Root-Access und SSH-Daemon auf einer 6591 beginnen. Zumindest war das bei mir der Fall.