FB 6591 verschiedenes

[fesc]

Hallo, hier schon mal ein Bild der 6591. Im Prinzip wie 6590, leider ohne PCIe module fuer die WiFi controller :-(


Edit Novize: Bild auf Miniatur geschrumpft

Zu meiner Frage: Weiss jemand die Belegung der beiden UART stecker auf der 6590? Bei beiden bekomme ich keine Ausgaben, der obere scheint 1.8V Pegel zu haben. Kann aber auch an meinem adapter liegen.
Antwort: s.u.

Ansonsten ein paar ausgewählte Daten aus der Supportdatei. Hübsch schnell der Atom.

Kernels
=======

##### BEGIN SECTION Support_Data Supportdata Linux fritz.box 3.12.59 #1 SMP PREEMPT Wed Jan 23 17:31:13 CET 2019 i686 Version 161.07.04
##### BEGIN SECTION Support_Data Supportdata Linux fritz.box 3.12.14 #1 PREEMPT Wed Jan 23 16:36:17 CET 2019 armv6b Version 161.07.04  (ARM)

Toolchain
=========
gcc version 5.4.0 (Buildroot 2016.05-gb708a47bb-dirty)

Product
=======
ProductID    Fritz_Box_HW233
firmware_info    161.07.04

Hardware/Atom
=============
AVM PA for Linux version 3.12.59 (jenkins@uildxiq17p2nl1xpuma7xMi2301xSSHID332C6MEJBFGWRFHBNS7XJTCNCVH) (gcc version 5.4.0 (Buildroot 2016.05-gb708a47bb-dirty)
[    3.327473] 00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    3.453382] Creating 4 MTD partitions on "intel-spi":
[    3.459041] 0x000000000000-0x000000001000 : "Descriptor"
[    3.465683] 0x000000124000-0x000000200000 : "BIOS"
[    3.471450] 0x000000001000-0x0000000e1000 : "ME"
[    3.477361] 0x0000000e1000-0x000000124000 : "Platform Data"

[    0.000000] SMBIOS 3.0 present.
[    0.000000] DMI: Intel Corporation PUMA 7 C0 PLATFORM/TBD, BIOS CGM2.86C.597968.R.1809251311 09/25/2018

[    0.002000] tsc: Detected 1999.936 MHz processor
[    0.000002] Calibrating delay loop (skipped), value calculated using timer frequency.. 3999.87 BogoMIPS (lpj=1999936)
[    0.289503] smpboot: Total of 2 processors activated (7999.74 BogoMIPS)

eMMC partition layout
=====================
179        0    3866624 mmcblk0
179        1        128 mmcblk0p1    PARTLABEL="SIGBLOCK0"
179        2       9216 mmcblk0p2    PARTLABEL="APP_CPU_KERNEL0"
179        3      73728 mmcblk0p3    PARTLABEL="APP_CPU_ROOTFS0"
179        4       5120 mmcblk0p4    PARTLABEL="NP_CPU_KERNEL0"
179        5      19456 mmcblk0p5    PARTLABEL="NP_CPU_ROOTFS0"
179        6      40960 mmcblk0p6    PARTLABEL="GW_FS0"
179        7        128 mmcblk0p7    PARTLABEL="SIGBLOCK1"
179        8       9216 mmcblk0p8    PARTLABEL="APP_CPU_KERNEL1" SEC_TYPE="msdos" TYPE="vfat"
179        9      73728 mmcblk0p9    PARTLABEL="APP_CPU_ROOTFS1" TYPE="squashfs"
179       10       5120 mmcblk0p10    PARTLABEL="NP_CPU_KERNEL1"
179       11      19456 mmcblk0p11    PARTLABEL="NP_CPU_ROOTFS1"
179       12      40960 mmcblk0p12    PARTLABEL="GW_FS1"
179       13       8192 mmcblk0p13    PARTLABEL="APP_CPU_NVRAM" LABEL="nvram-atomp7" TYPE="ext4" jbd2/mmcblk0p13    /nvram ext4
179       14       8192 mmcblk0p14    PARTLABEL="NP_CPU_NVRAM" LABEL="nvram-armp7" TYPE="ext3"
179       15       8192 mmcblk0p15    PARTLABEL="AVM_TFFS1"
179       16       8192 mmcblk0p16    PARTLABEL="AVM_TFFS2"
179       17     131072 mmcblk0p17    PARTLABEL="AVM_UPD_TMP"
179       18    3402735 mmcblk0p18    PARTLABEL="AVM_MEDIA" TYPE="ext4" jbd2/mmcblk0p18 /var/media/ftp ext4


BoxInfo
=======
<j:BoxInfo>
<j:Name>FRITZ!Box 6591 Cable</j:Name>
<j:HW>233</j:HW>
<j:Version>161.07.04</j:Version>
<j:Revision>65028</j:Revision>
<j:OEM>avm</j:OEM>
<j:Lang>de</j:Lang>
<j:Annex>Kabel</j:Annex>
<j:Lab/>
<j:Country>049</j:Country>
<j:Flag>mesh_master_no_trusted</j:Flag>
<j:UpdateConfig>1</j:UpdateConfig>
</j:BoxInfo>

Edit:
Mittlerer UART Stecker: (per default schweigsame) Atom : GND, Rx, Tx, 1.8V (von links nach rechts)
Oberer: ARM (3.3V, Tx, Rx, GND)

!! EditEdit: Sorry, Platine falsch herum gehalten. Es ist genau andersherum:
Oberer UART Stecker: Atom : 1.8V, Rx, Tx, GND (von links nach rechts)

 

[dg2drf]

Normalerweise liegen die Pegel bei 3,3V bzw 5 Volt. Andere Pegel sind mir noch nicht untergekommen.
Denke ein Adapter von TTL auf V24 hast du, und auch mit unterschiedlichen Baudraten probiert.

 

[KunterBunter]

Wikipedia kennt sogar noch ein paar mehr gängige Logikpegel, u.a. den oben genannten CMOS 1,8V.

 

[PeterPawn]

@fesc:
Hast Du schon mal geprüft, ob AVM bei der 6591 den Inhalt der Firmware-Partitionen kryptographisch sichert? Die Partition "ME" im SPI klingt ja schon irgendwie nach "Management Engine" (https://www.heise.de/select/ct/2018/6/1520827829694087) und das geht ggf. wieder in Richtung "trust zones" - ich glaube jedenfalls nicht daran, daß da irgendwelche sinnvollen Fernwartungsfunktionen in einem Edge-Router (der ja erst mal laufen muß, damit man aus der Ferne überhaupt zugreifen könnte, wenn er für das Herstellen der Internet-Verbindung verantwortlich ist) existieren könnten.

Passend dazu gäbe es in neueren "/var/install"-Skripts bei AVM auch einen Abschnitt, bei dem ein Programm namens "tzupdate" gesucht wird, was wohl dazu dienen dürfte, irgendwelche Signaturen nach einem Update (ob für den Bootloader und/oder das OS, wäre halt die Frage) zu erneuern (bzw. wohl eher zu speichern, denn lokales Berechnen einer Signatur wäre ja angreifbar).

Wäre das tatsächlich jetzt alles kryptographisch gesichert (ähnlich "Secure Boot"), wäre das sicherlich für so manchen auch ein Grund, von einem Kauf dieses Geräts eher Abstand zu nehmen ... einen "untrusted PC" kann man immer noch (netzwerktechnisch) in seinem LAN isolieren bzw. kontrollieren (im Sinne von "nur überwacht kommunizieren lassen"), aber bei einem Edge-Router wird das deutlich schwerer.

Wer würde sich aber schon freiwillig die Laus in den Pelz setzen, wenn das Gerät tatsächlich nur noch nach dem "trust me, I'm not evil"-Prinzip arbeitet und nicht mal mehr die kleinste Form der Kontrolle möglich ist?

Deshalb sollte das (m.E.) so schnell wie möglich geklärt werden ... die "technischen Daten", die AVM jeweils für die Geräte veröffentlicht, kann man ja in der Pfeife rauchen: https://avm.de/produkte/fritzbox/fritzbox-6591-cable/technische-daten/ - ob die Boxen noch mit eigener Firmware betrieben werden können (schon bei den vorherigen Cable-Modellen gibt AVM ja keine "Rettungsprogramme" mehr an die Retail-Kunden), findet man selbstverständlich NICHT als Information bei AVM ... bisher habe ich auch in der KB nichts dazu finden können.

 

[fesc]

Normalerweise liegen die Pegel bei 3,3V bzw 5 Volt. Andere Pegel sind mir noch nicht untergekommen

Der "obere" hat einen pegel von 1.8V. Ich habe einen wandler reingebastelt, kommt aber auch nichts. Habe auch mit einem Scope gemessen.
Der untere hat 3.3v.

Anhand der Puma7 Daten die ich habe bin ich mir ziemlich sicher das der 3.3V vom ARM, der 1.8V vom Atom kommt.

-- Aktualisiert --

Die Partition "ME" im SPI klingt ja schon irgendwie nach "Management Engine

Ja, Puma7/Atom bootet erst ein BIOS, dann erst eva (man sieht auch dass es laenger dauert bis der ftp server da ist).
Inwieweit die ME aktiv ist weiss ich nicht. Normalerweise sieht man das zur Laufzeit (wenn man ein Scope an die SPI leitungen haengt), da die ME immer wieder mal aufs flash zugreifen will. Ich habe das flash allerdings noch nicht gesucht/gefunden (entweder PCB Rueckseite, oder unter all den shieldings).

Solange ich noch kein update-image habe werde ich nicht versuchen was in die Partitionen zu schreiben .. und einen shell-zugang zu bekommen habe ich noch nicht ernsthaft versucht.

Sollte das wirklich gesichert sein bleibe ich bei 6x90, zumal auch nicht wie erhofft mini-PCIe slots fuer die WiFi module verbaut sind (WiFi Raus, SATA controller rein, und man haette ein schoenes NAS gehabt).
Dann muesste aber eigentlich auch ein TPM chip verbaut sein, was ich nicht glaube.

Noch eine technische Notiz: der link zum ethernet switch ist 2.5Gbit SGMII, d.h. man kann durchaus mehrere externe ports mit voller Bandbreite betreiben (bei entsprechend schneller Kabelverbindung).

 

[PeterPawn]

Dann muesste aber eigentlich auch ein TPM chip verbaut sein, was ich nicht glaube.

fTPM2.0 wäre als Funktion der ME zu haben ... Hardware-TPM braucht's nur, wenn man die Integrität der ME/des BIOS/des Bootloaders zusätzlich sichern will - denn die ME kann ja dann nicht selbst die TPM-Funktionen für die Verifikation ihrer eigenen Integrität bereitstellen.

Ich hätte (neben der seriellen Schnittstelle, die aber vermutlich auch wieder gelatched ist und abgeschaltet wird über irgendein Control-Bit) schon ein paar Ideen, wie man zu einer Shell-Session gelangen könnte ... weiß aber nicht, welcher Weg tatsächlich funktioniert. Ich assistiere gerne, würde das aber nicht unbedingt öffentlich diskutieren, bis der (oder zumindest "ein") Weg verifiziert und für funktionierend befunden wurde - allerdings brauchen die meisten Ideen tatsächlich den Zugriff (auch das Schreiben) auf die TFFS-Partitionen.

Das wäre aber ohnehin eine meiner ersten Aktionen nach dem Auspacken einer solchen Box gewesen, wenn ich eine erworben hätte ... das Überprüfen, ob das Zurücksetzen auf die Werkseinstellungen über ein eigenes TFFS-Image noch genauso abläuft, wie bei den anderen AVM-Modellen. Wenn nicht, würde ich auch nicht "experimentieren" und die Box umgehend wieder (sofern §312g BGB einschlägig/anwendbar ist) an den Händler zurückgehen lassen. Ich weiß nicht mehr genau, wie oft ich schon in anderen Cable-Boxen die Einstellungen zurücksetzen mußte, weil ein Versuch "schiefgegangen" ist - daher ist eine Box ohne diese Option für mich per se inakzeptabel.

 

[dg2drf]

Wikipedia kennt sogar noch ein paar mehr gängige Logikpegel, u.a. den oben genannten CMOS 1,8V.

Sucht man nach Pegelwandler, findet man zu 99,9 % welche, die auf 3,3 bzw 5 Volt arbeiten. Habe bewusst noch keinen gefunden, der auf 1,8 Volt Basis arbeitet. (Gibt es überhaupt z.B. WLAN Module auf 1,8 Volt Basis ?)
Aus Kostengründen glaube ich nicht, das die mit unterschiedlichen Spannungen bzw. Levelshiftern arbeiten.

 

[PeterPawn]

BTW ... ich bin nicht mal davon überzeugt, daß das Fehlen des TFFS-Dumps in den erweiterten Supportdaten bei der 6591 (denn die kann man ja wohl immer noch auswählen, oder?) auch wirklich Absicht ist.

Schaut man sich das Erzeugen dieses Dumps in anderen Firmware-Versionen (in "/bin/supportdata.tffs" - die findet man auch in den Kernel-Quellen) an, werden dort die TFFS-Partitionen (oder auch die einzelne bei NAND) ja über "/proc/mtd" gesucht. Nach der Partitionliste in #1 stehen die aber gar nicht länger in einer Flash-Partition, die über MTD-Mechanismen verwaltet wird, sondern sie sind in den eMMC-Speicher (auch wenn das natürlich ebenfalls ein Flash-Speicher ist) gewandert. Damit findet das Skript keine Partition und erzeugt so nicht einmal die Header-Zeilen.

Das KANN Absicht sein ... ich würde aber keine Wetten darauf abschließen.

 

[fesc]

denn die kann man ja wohl immer noch auswählen

Ja kann man. Und die Sektion ist dann durchaus in den erweiterten Supportdaten drinnen, nur leer, was deine Theorie bestaetigt.

Was die entsprechende mtd Nummerierung in eva ist, das ist jetzt natuerlich die Frage .. man will hier ja keinen Fehler beim schreiben machen.

 

[PeterPawn]

mtd Nummerierung in eva

Ausgehend von eine gewissen "Faulheit" (beim Anpassen der anderen Programme, die es bei AVM sonst noch so gibt), würde ich zwar ohnehin auf "mtd3" und "mtd4" tippen, aber man dürfte das am ehesten anhand der Größe der Partitionen sehen.

Ein 1:1-Mapping wird es ohnehin nicht geben - dafür gibt es in der AVM-Nametable zuwenige "mtd"-Einträge (0-15). Da AVM sicherlich auch bei der 6591 die Firmware mit dem Rest mixt (schon die "/etc/puma6_helper.sh" bei ALLEN Boxen ist ein deutliches Zeichen dafür, dort ist - trotz des Namens - ja auch der Puma7 in dem Modell mit der HWRevision 233 enthalten), sollten sich neue Einstellungen/Environment-Variablen auch bis zu den anderen Modellen herumsprechen und die neueste Name-Table (Version @M - aus den Quellen der 07.10 für die 6490) enthält auch nur "HardwareFeatures" und "macwlan3" als neue Einträge.

Bisher paßten m.W. die Größen der Partitionen im Environment immer halbwegs - wenn MTD3 und MTD4 also eine Größenangabe von 4 MB haben (8192 Blöcke a 512 Byte - wenn der NAS-Speicher in der 6591 ca. 1,6 GB frei hat, sind die Zahlenangaben jedenfalls 512-Byte-Blöcke) und es keine weiteren in dieser Größe gibt (ich vermute mal, die "nvram"-Partitionen werden in EVA nicht erreichbar sein - es gibt zumindest keinen offensichtlichen Grund dafür), ist diese Vermutung sicherlich legitim.

 

[fesc]

Man soll ja nicht nur Erfolge sondern auch Misserfolge melden (als Warnung an andere ...):

Nach Generierung eines tffs images hat sich die Frage gestellt ob es nach mtd3 zu schreiben ist oder nicht .. entweder ist die Numerierung gleich geblieben, oder ich würde mir (falls linux mmcblkp1..16 jetzt z.B. eva mtd0..15 entspricht) im schlimmsten Fall einen ARM kernel zerstören. Da die box von Werk mit zwei lauffähigen images kam bin ich das Risiko eingegangen.

Es ging schon los dass das RETR Kommando zum schreiben auf mtd3 ewig nicht fertig geworden ist. Es ging auch nichts ueber die Leitung (hatte wireshark mitlaufen).

Nach einer halben Stunde habe ich abgebrochen. Die box hat nach wie vor gebootet.

Testhalber habe ich dann linux_fs_start umgeschalten (1 -> 0) und musste feststellen dass beim booten ein reset stattfindet und wieder auf die alten partitionen umgeschalten wird. Es sieht also tatsächlich so aus als ob mtd3 _nicht_ mehr tffs1 ist!

Ich koennte jetzt probieren auf mtd14/15 zu schreiben, in der Hoffnung dass sich dort das TFFS befindet, aber dass ist mir im Augenblick zu heikel (auch weil das flashen scheinbar gar nicht funktioniert hat). Ich warte erstmal auf ein update image.


Man soll ja nicht spekulieren, aber schon bei der blosen Existenz der Partition

mmcblk0p17 PARTLABEL="AVM_UPD_TMP"

beschleicht mich der Verdacht dass sich beim Update-Vorgang etwas gundsätzlich geändert haben könnte. Zumal die genau so gross ist dass die beiden filesysteme und kernel reinpassen.

 

[PeterPawn]

Es ging schon los dass das RETR Kommando zum schreiben auf mtd3 ewig nicht fertig geworden ist.

Ich hoiffe mal, das war dann doch ein STOR?

Die temporäre Partition für das Update dient wohl tatsächlich der Ablage irgendwelcher Image-Dateien ... ihre Benutzung (sofern die Partition existiert) ist schon in sehr viel älteren Systemen zu sehen. Schau mal in älterer (Cable-)Firmware in die "E16-filesystem-update", da wird eine solche Partition (wenn sie in "/proc/avm_partitions" unter dem Namen "update_temp" gefunden wird) unter "/var/remote" gemountet und dient dann wohl der Kommunikation zwischen den beiden Systemen.Früher wurde halt das Verzeichnis "/var/remote" per NFS für das andere System freigegeben - das ist dann beim Umzug auf den ATOM-Kernel aber wohl auch irgendwie abhanden gekommen. Man muß hier auch mal die Mounts aus den beiden System betrachten, wenn man eine Idee bekommen will, wer da wie zugreift auf diese "scratch partition".

Wenn es nicht MTD3 ist, ist das halt "falsch geraten" ... aber ich sehe auch nirgends die kompletten "mtdX"-Einträge aus dem Bootloader-Environment. Da ist das zielgerichtete Raten dann schon sehr schwer ...

Ich verstehe jetzt nicht, welchen Zusammenhang Du zwischen dem Schreibversuch nach MTD3 und dem anschließenden "Reset" (was ist das denn genau?) herstellst ... wenn keine Daten übertragen wurden, könnte ja höchstens der Inhalt der eMMC-Partition vorher schon gelöscht worden sein, damit das einen Effekt hat.

Das paßt aber eher nicht zur generellen Verwaltung von eMMC-Speicher ... der hat ja i.d.R. seinen eigenen Controller, damit er sich wie ein stinknormales Storage-Device verhält und es gibt dort gar keine Notwendigkeit, irgendeine Partition vor dem Beschreiben mit neuen Daten irgendwie zu leeren. Mir fiele jetzt nicht mal ein anderer Weg als ein "mkfs" für eine eMMC-Partition ein, um die irgendwie "zu initialisieren".

Die Datenübertragung bei einem STOR-Kommando würde der Client aber tatsächlich erst starten, wenn er eine "150"-Antwort vom Server erhalten hat ... was war denn da genau im FTP-Dialog zu sehen bis zu dem Punkt, wo es nach Deiner Ansicht nicht mehr vorwärts ging? Wobei das "es geht nicht mehr vorwärts" ja zumindest mal kein Zeichen für ein falsches Format sein kann (komme ich gleich noch drauf), wenn da noch GAR KEINE Daten übertragen wurden - so rein "per Ahnung" kann die Box ja das neue TFFS-Image noch nicht ablehnen und wenn sie überhaupt einen Schreibvorgang für MTD3 zuläßt (hier wäre dann auch wieder das Problem, daß man mal beide Schreibweisen abklopfen sollte - sowohl groß- als auch kleingeschrieben), dann sollte ja zumindest erst mal auch eine Datenübertragung stattfinden. Ob so ein Schreibvorgang generell "akzeptiert" würde oder nicht, sagt dann eben wieder die entsprechende Antwort des FTP-Servers auf das "STOR"-Kommando aus.

--------------------------------------------------------------------------------------------------

Verstehe ich das richtig, daß die Box von Beginn an mit zwei Systemen ausgestattet war ... du konntest also sowohl mit "0" als auch mit "1" in "linux_fs_start" die Box laufen lassen? Auch so, daß tatsächlich bei "1" ein anderes System dauerhaft lief - wie hast Du die denn dann auseinandergehalten? Waren das verschiedene Versionen? Ansonsten wäre das ja - wenn die jetzt von Dir beobachtete "Umschaltung" auf "0" da auch schon automatisch erfolgte und Du sie nur nicht bemerkt hast - praktisch keine Änderung ggü. dem Ausgangszustand ... daß AVM (bzw. EVA) bei Ladeproblemen für ein System von sich aus auf das andere umschaltet und dann nach Reset und BIOS im nächsten Anlauf wieder das zuletzt vermutlich funktionierende geladen wird, wäre ja eine sinnvolle Änderung ... zumal es ja nicht sooo schwer ist zu erkennen, ob eine Partition nun einen gültigen Kernel enthält oder nicht (versuche ich beim "gui_bootmanager" ja auch und es klappt i.d.R. einigermaßen).

Ich bin halt etwas skeptisch hinsichtlich Deiner Beobachtung mit den zwei Systemen ab Werk, weil es bei der Produktion ja nun keinen wirklich einleuchtenden Grund gibt (wenn wir mal die Thesen zu signierter Firmware außen vor lassen), warum man sich die Zeit nehmen sollte, beide Systeme zu installieren (also 8 Partitionen zu beschreiben) - Zeit ist bekanntlich Geld und an so eine Art "failover" ab Werk mag ich fast nicht glauben.

--------------------------------------------------------------------------------------------------

Ich weiß allerdings auch nicht, ob sich AVM für die Speicherung des TFFS in einer eMMC-Partition nun noch ein anderes Format hat einfallen lassen und ob daher das Image-Format ein anderes sein müßte. Aber auch hier glaube ich wieder nicht so richtig daran, daß sich AVM übermäßig Arbeit aufhalst. So, wie die Boxen mit NAND-TFFS auch das "legacy format" (wie es bei der Speicherung in NOR oder SPI genutzt wird) verwenden, wenn nach "mtdnand" geschrieben wird (das setzt dann offensichtlich der Bootloader entsprechend um), würde ich weiterhin etwas ähnliches für TFFS im eMMC erwarten ... nur daß wohl auch hier eher auf ein ähnliches Format wie bei der Speicherung im NAND gesetzt werden könnte, weil ja beim eMMC-Speicher auch das "nachträgliche" Ändern von binären Einsen (im gelöschten Zustand) in binäre Nullen nichts so richtig bringt, da wieder der eMMC-Controller die Steuerung übernimmt (und alles andere, wie z.B. das Wear-Leveling, auch).

Bei NOR bzw. SPI wird ja durch Verknüpfen von neuem mit altem Inhalt erst einmal geprüft, ob man einen Schreibvorgang tatsächlich als "erase-write"-Zyklus ausführen muß (der die Lebensdauer verkürzt), weil sich mindestens ein Bit von "0" in "1" ändern müßte (was halt nur beim Löschen geht) oder ob alle Änderungen nur auf "1" in "0" hinauslaufen, dann wird einfach noch einmal "drübergeschrieben". Das passiert z.B. auch, wenn ein alter Eintrag für eine ID ungültig wird, weil irgendwo weiter hinten ein neuer (auch mit neuem Inhalt) erstellt wurde ... dann wird einfach im Block mit der alten ID ein Schreibvorgang ausgelöst, der die Speicherzellen mit der alten ID alle auf "0" schießt - im Ergebnis steht dann im ID-Feld "0x0000" und solche Einträge gelten als "gelöscht" und werden beim Lesen übersprungen.

Fazit: Es KÖNNTE zwar sein, daß AVM ein neues Format für die Speicherung verwendet - schließlich gibt es ein neues TFFS-Module, was sich "tffs_efi" nennt. Nur hätte ich jetzt nicht erwartet, daß damit die Speicherung des TFFS in einer eMMC-Partition gemeint ist ... eher wäre ich davon ausgegangen, daß dabei die NVRAM-Variablen eines EFI-BIOS für die Speicherung des Environments genutzt werden (https://man.cx/nvram(8)) und im TFFS nur noch die "Dateien" aus den TFFS-Nodes landen. Es könnte also auch sein, daß hier weder Name-Table noch Environment-Variable in ein TFFS-Image gehören ... aber ich würde einiges darauf wetten, daß der TFFS-Driver beim Start auch Auskunft darüber gibt, wo und wie er die Daten verwaltet - das sollte man noch locker in der "dmesg"-Ausgabe der Support-Daten finden, wenn man die einigermaßen zeitnah zum Reboot der Box zieht. Mit dieser Information kann man dann (anhand der Quellen für die Puma6-Boxen) schon wesentlich genauer spekulieren.

 

[fesc]

Ich hoiffe mal, das war dann doch ein STOR?

Äh ja (eva_store_tffs halt) .. es hat nur die version ausgegeben:
Found AVM bootloader: AVM EVA Version 4711.0815 0x0 0x76001

dem anschließenden "Reset" (was ist das denn genau?) herstellst

Ich pinge waehrend dem booten immer. Der "reset" wirkt sich dahingehend aus (nach umschalten auf linux_fs_start 0 und booten):
- nach ca. 10sek der normale ping auf eva (ca. 5 mal)
- dann Ruhe (normalerweise antwortet das OS nach einer minute)
- nach ca. 15 sekunden wieder 5 antworten von eva
- nach einer minute ist das OS wieder da (mit linux_fs_start=1)
Ich interpretiere das so dass der bootloader festgestellt hat dass in einer partition mist steht, umschaltet, und es mit der anderen versucht.

du konntest also sowohl mit "0" als auch mit "1" in "linux_fs_start" die Box laufen lassen

Ja. Aber da habe ich mir jetzt ein Ei gelegt, denn hier hatte obige Umschaltung auch zugeschlagen. Das wusste ich da nicht und habe angenommen dass beide programmiert sind.
Ich habe eben noch einmal in die Supportdaten geschaut die ich bei beiden versuchen erstellt hatte, sind tatsaechlich beide gleich (linux_fs_start=1).

Es wird/wurde also tatsaechlich gar nichts geschrieben oder geloescht. Das ist das letzte was sich am Netz tut.

24   13.271278   192.168.178.2   192.168.178.1   FTP   59   Request: P@SW
25   13.271595   192.168.178.1   192.168.178.2   TCP   60   21 → 60451 [ACK] Seq=198 Ack=51 Win=2097088 Len=0
26   13.272247   192.168.178.1   192.168.178.2   FTP   103   Response: 227 Entering Passive Mode (192,168,178,1,7,208)
27   13.279087   192.168.178.2   192.168.178.1   TCP   66   60452 → 2000 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
28   13.279394   192.168.178.1   192.168.178.2   TCP   62   2000 → 60452 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460 WS=64
29   13.279441   192.168.178.2   192.168.178.1   TCP   54   60452 → 2000 [ACK] Seq=1 Ack=1 Win=525568 Len=0
30   13.312618   192.168.178.2   192.168.178.1   TCP   54   60451 → 21 [ACK] Seq=51 Ack=247 Win=525312 Len=0
31   14.280080   192.168.178.2   192.168.178.1   FTP   64   Request: STOR mtd3
32   14.280250   192.168.178.1   192.168.178.2   TCP   60   21 → 60451 [ACK] Seq=247 Ack=61 Win=2097088 Len=0
43   193.377337   192.168.178.2   192.168.178.1   TCP   54   60452 → 2000 [RST, ACK] Seq=2 Ack=1 Win=0 Len=0

Passiver FTP funktioniert prinzipiell (RETR).

Im kernel log sind ein paar ausgaben die es so nicht in der 6490 gibt ..:

[    4.543942] tffs: Waiting for backend to be available
[    4.544061] [prom_getenv] request: kernel_args
[    4.564053] mmcblk0: mmc0:0001 004G60 3.68 GiB
[    4.569252] mmcblk0boot0: mmc0:0001 004G60 partition 1 2.00 MiB
[    4.576219] mmcblk0boot1: mmc0:0001 004G60 partition 2 2.00 MiB
[    4.582993] mmcblk0rpmb: mmc0:0001 004G60 partition 3 512 KiB
[    4.595064]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18
[    4.606624]  mmcblk0boot1: unknown partition table
[    4.612707]  mmcblk0boot0: unknown partition table
[    4.619824] mtd_add_tffs: tffs partition found
[    4.624811] [prom_getenv] request: firmware_info
[    4.630072] [prom_getenv] value: 161.07.04
[    4.634662] [prom_getenv] request: HWRevision
[    4.639617] [prom_getenv] value: 233
[    4.643623] [prom_getenv] request: HWSubRevision
[    4.648800] [prom_getenv] value: 7
[    5.265434] [avm_prom_tffs_sync] called
[    7.459534] [prom_getenv] request: HWSubRevision
[    7.464803] [prom_getenv] value: 7
[   53.394659] [prom_getenv] request: kernel_args
[   58.045883] [prom_getenv] request: firmware_version
[   58.046210] [prom_getenv] value: avm

 

[PeterPawn]

#eva_store_tffs:
Da die Box ja auf das STOR-Kommando offenbar nicht mit der notwendigen Antwort "150 Opening BINARY data connection" reagiert (https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/EVA_FTP.cs#L391), startet das Skript die Datenübertragung gar nicht erst.

Insofern zeigt der Netzwerkmitschnitt hier nichts Ungewöhnliches (wenn man von der fehlenden Antwort mal absieht), der 3-Way-Handshake nach dem "PASV" (Port ist ja 7 * 256 + 208 = 2000 nach der Antwort) ist noch erfolgreich.

Die Frage wäre jetzt (ich schaue mir die anderen Daten nachher noch mal an), ob man einfach mal versucht, die Datenverbindung zum Schreiben zu verwenden, auch ohne die Bestätigung durch den Server. Wenn die Box ihrerseits da nichts aus der Verbindung liest, wird auch nichts weiter passieren - erst recht werden dann keine ACK-Pakete von der Box kommen für die Daten.

Bei der Frage der TFFS-Speicherung muß ich erst noch mal in die kompletten Daten sehen ... da fehlt mir was an Messages im Auszug oben.

In den Quellen (der 07.10 für die 6490) sieht man in "tffs_core.c" (da steht auch die "Waiting for backend"-Message drin) den folgenden Abschnitt:

 560 #if IS_ENABLED(CONFIG_TFFS_DEV_REMOTE)
 561     #if defined(CONFIG_MACH_PUMA7)
 562         #if defined(CONFIG_X86_PUMA7)
 563         TFFS3_Register_SERVER(AVM_EVENT_TFFS_NODE_ARM);
 564         #else //PUMA7_arm
 565         TFFS3_Register_REMOTE(AVM_EVENT_TFFS_NODE_ATOM);
 566     #endif
 567     #endif
 568 #endif

Bei der 6591 verwaltet also offensichtlich auch ein System die TFFS-Speicherung und stellt einen Server (vermutlich über die IPC-Mechanismen auf den internen 169.254.1.0/30-Adressen, die es wahrscheinlich auch immer noch geben wird) bereit, mit dem das andere System dann kommunizieren kann.

Da müßte man noch mal in die Quellen schauen, ob der Name der aufgerufenen Funktion jetzt die Rolle des lokalen TFFS-Moduls beschreibt (also der ATOM der Server ist) oder die Rolle des Komplementärs (der ATOM sich also BEIM Server auf dem ARM registriert bzw. für den Empfang der entsprechenden Events) - das weiß ich aus dem Kopf nicht mehr; es wird wohl so sein, wie bei den Puma6-Modellen auch.

Nur zur Frage, wo die Speicherung jetzt erfolgt und welches Backend es ist, auf das der Core oben wartet, steht da (in den Auszügen) nichts ... irgendeine "TFFS3_irgendwas"-Zeile müßte da existieren - ggf. aber eben auch auf dem ARM-Core, wenn der wirklich das Backend zur Speicherung verwalten sollte. Vielleicht hast Du diese Zeilen nicht erwischt, weil Du das Log mit "grep" o.ä. (und dann ohne "-i") durchgepflügt hast (nur so als spontane Idee, warum da so wenig zum TFFS steht)?

 

[PeterPawn]

Ich habe von jemandem die Support-Daten einer 6591 erhalten ... was soll ich sagen? Einiges ist neu, einiges bekannt ... ich bin bisher nur noch nicht dazu gekommen, das zusammenzuschreiben.

Ganz kurz nur soviel: Da die Verwaltung des TFFS jetzt eben in einer eMMC-Partition erfolgt, wird dort eine MTD-Emulation auf einem Block-Device verwendet (https://git.kernel.org/pub/scm/linu...tree/drivers/mtd/devices/block2mtd.c?h=v5.1.5). Das Speicherformat in diesem MTD-Device ist dann dasselbe wie bei der Speicherung in NAND-Flash.

Ich bin mir im Moment nicht einmal sicher, ob AVM tatsächlich die Fähigkeiten aus dieser "block2mtd.c" in den Bootloader eingebaut hat - denn der müßte natürlich auch über den eMMC-Controller zugreifen. Einfach 1:1 wird AVM ihn ja wohl kaum übernommen haben ... da der Quellcode für "block2mtd.c" unter GPL steht, müßte AVM dann auch die EVA-Quellen veröffentlichen.

Theoretisch kommt der Recovery-Prozess auch ohne den Zugriff auf das TFFS aus (der Lesezugriff über den Bootloader geht ja schon lange nicht mehr) ... wenn die Environment-Variablen woanders gespeichert werden ("efivarfs" ist auf jeden Fall mal gemountet) und irgendein Flag darin noch für "Reset" aller anderen TFFS-Daten sorgt (es gibt ja noch genug ungenutzte bzw. nicht mehr benutzte Variablen im Environment, irgendein Zusatz zu DMC wäre auch denkbar), dann braucht der Bootloader eigentlich keinen Zugriff auf das TFFS zu haben.

Ich würde also - bis das abschließend geklärt ist - von Schreibversuchen für ein TFFS-Image über den Bootloader Abstand nehmen ... die Verwaltung der Environment-Variablen könnte stinknormal (wie bisher auch möglich, aber von AVM nur zum Setzen von Werten genutzt, soweit ich das verfolgt habe) über GETENV/SETENV/UNSETENV erfolgen und die funktionieren ja zumindest noch, nach den Berichten oben.

Gänzlich unlogisch wäre das auch nicht, denn ein geänderter TFFS-Inhalt ist ein Angriffsvektor, wie schon mehrfach (mit jeweils anderen Modifikationen am Inhalt) gezeigt. Denkbar also, daß AVM für alles jenseits der drei (auch erst mal auf vollen Arbeitsumfang zu testenden) FTP-Befehle auch weitere Vorkehrungen getroffen hat. Wer also mit seiner neuen 6591 etwas herumprobieren will, der sollte entsprechende Vorsicht walten lassen ... ich würde glatt vorschlagen, alles bisherigen Erkenntnisse zur 6490 und 6590 erst einmal so lange zu vergessen bzw. komplett infrage zu stellen, bis sie für die 6591 ganz neu bestätigt wurden.

 

[f666]

Bei den Kerneln für die 6{4,5}90 sind alle Ein-/Ausgaben auf der seriellen Schnittstelle durch die AVM .config deaktiviert (CONFIG_SERIAL_8250_CONSULE_MUTE). Wahrscheinlich wird das bei der 6591 ebenso der Fall sein. EVA gibt auch nix aus, somit könnte deine Verkabelung auch richtig sein, und du siehst trotzdem nichts.
Das würde sich nur mit einem eigenen Kernel herausfinden lassen.

In den Kernelquellen für die 6490 Version 07.10 gibt es ein neues Modul drivers/char/tffs/tffs_nand_noob, könnte einen Blick wert sein.

 

[fesc]

Zur info, 6591 sourcen fuer FW 7.04 liegen in

ftp://ftp.ffesh.de/pub/ffritz/AVM/

 

[fesc]

Inzwischen habe ich es geschafft die squashfs images zu extrahieren. Es sieht allerdings so aus als ob AVM mal wieder was geaendert hat, weder das arm noch das atom image laesst sich mit den mir bekannten tools auspacken. Einige pointer (z.B. id und fragment table) im squashfs superblock zeigen einfach ins leere (dort stehen nur nullen), was unsquashfs natuerlich mit einem fehler quittiert.
Der header an sich sieht noch OK aus:

Found a valid big endian SQUASHFS 4:0 superblock on sqfs_arm.bin.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 12343.98 Kbytes (12.05 Mbytes)
Compression xz   <-- Neu im vergleich zu 6490
Block size 65536
Filesystem is exportable via NFS <-- Neu im vergleich zu 6490
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 120  <- wie kann dann die fragment table 0 sein??
Number of inodes 1095
Number of ids 1

Vielleicht habe ich mal wieder was verpasst, aber ist sowas auch schon auf anderen Boxen aufgefallen und es gibt evtl schon angepasste tools?
Ansonsten werde ich mal anhand der kernel sourcen schauen ob sich was getan hat ...

Edit: Hier stand Bloedsinn .. alles wie gehabt.

 

[fesc]

.. und anhand der aktuellen Erkenntisse hier eine Warnung:

Die (boot/update)Architektur bei der 6591 ist tatsaechlich anders als bei 6490/6590, bzw. komplett anders als bei den DSL boxen. Inkl. Signaturpruefung der eMMC Partitionen.

Ohne genau zu wissen was man tut (bzw. ohne bewusst in Kauf zu nehmen dass man sich evtl. seine Box "brickt") wuerde ich vorerst davon abraten mit irgendwelchen bekannten Tools und Mechanismen (z.b. Schreiben von partitionen per EVA) Versuche anzustellen.

 

[fesc]

Anbei ein paar Forschungsergebnisse zur 6591

Die gute Nachricht: Secure Boot ist (noch?) nicht aktiv, es findet (noch?) keine Signaturpruefung der boot images statt.

Die schlechte Nachricht: Ein update/modifikation ueber EVA wie bei 6x90 scheint nicht mehr moeglich, zumindest ist es mir bisher nicht gelungen. Wie schon oben geschrieben, alle Schreibvorgaenge via EVA werden sofort terminiert.

Wer also keinen Loetkolben (u.A.) in die Hand nehmen will der hat momentan schlechte Karten.
Sollte sich in irgendeiner Version eine Luecke auftun die man zum ausfuehren von Fremdsoftware ausnutzen kann, dann gibt es von da ab einen upgrade-Pfad geben.
Als Anreiz, in meinem repository sind die ueblichen Modifikationen um telnet/dropbear in ein original image zu integrieren, siehe 6591 branch (README und insbesondere die Warnung beachten!).

Ein paar technische infos ..

eMMC partitionen (aus der GPT):

#  Content            Type         Start End    Size   Start    End       Block device
   idx=linux_fs_start              LBA   LBA    LBA    Offset   Offset
-- ------------------ ------------ ----- ------ ------ -------- --------- ---------------
1  SIGBLOCK0          raw/empty    800   8FF    100    100000   11FE00    /dev/mmcblk0p1
2  APP_CPU_KERNEL0    uefi/fat     1000  57FF   4800   200000   AFFE00    /dev/mmcblk0p2
3  APP_CPU_ROOTFS0    squashfs     5800  297FF  24000  B00000   52FFE00   /dev/mmcblk0p3
4  NP_CPU_KERNEL0     raw/bzImage  29800 2BFFF  2800   5300000  57FFE00   /dev/mmcblk0p4
5  NP_CPU_ROOTFS0     squashfs_be  2C000 357FF  9800   5800000  6AFFE00   /dev/mmcblk0p5
6  GW_FS0             ??/empty     35800 497FF  14000  6B00000  92FFE00   /dev/mmcblk0p6
7  SIGBLOCK1          raw/empty    49800 498FF  100    9300000  931FE00   /dev/mmcblk0p7
8  APP_CPU_KERNEL1    uefi/fat     4A000 4E7FF  4800   9400000  9CFFE00   /dev/mmcblk0p8
9  APP_CPU_ROOTFS1    squashfs     4E800 727FF  24000  9D00000  E4FFE00   /dev/mmcblk0p9
10 NP_CPU_KERNEL1     raw/bzImage  72800 74FFF  2800   E500000  E9FFE00   /dev/mmcblk0p10
11 NP_CPU_ROOTFS1     squashfs_be  75000 7E7FF  9800   EA00000  FCFFE00   /dev/mmcblk0p11
12 GW_FS1             ??/empty     7E800 927FF  14000  FD00000  124FFE00  /dev/mmcblk0p12
13 APP_CPU_NVRAM      ext4         92800 967FF  4000   12500000 12CFFE00  /dev/mmcblk0p13
14 NP_CPU_NVRAM       ext4         96800 9A7FF  4000   12D00000 134FFE00  /dev/mmcblk0p14
15 AVM_TFFS1          tffs         9A800 9E7FF  4000   13500000 13CFFE00  /dev/mmcblk0p15
16 AVM_TFFS2          tffs         9E800 A27FF  4000   13D00000 144FFE00  /dev/mmcblk0p16
17 AVM_UPD_TMP        none/ext4    A2800 E27FF  40000  14500000 1C4FFE00  /dev/mmcblk0p17
18 AVM_MEDIA          ext4         E2800 75FFDE 67D7DF 1C500000 EBFFBC00  /dev/mmcblk0p18

Die SIGBLOCK partitionen sind wohl fuer die image-signaturen gedacht, momentan aber leer.

Die ganze tffs/Konfigurations Geschichte verwirrt mich noch etwas. In der Tat sind alle Variablen in /sys/firmware/efi/efivars verfuegbar, aber auch in /var/flash (die meisten als files, mache als tffs device nodes), teile auch in /proc/sys/urlader/environment.
Das muesste besser der "Spezialist" analysieren ;-)

Was die toolchain betrifft, die gravierendste Aenderung ist dass von uClibc auf glibc gewechselt wurde.

Sucht man nach Pegelwandler, findet man zu 99,9 % welche, die auf 3,3 bzw 5 Volt arbeiten. Habe bewusst noch keinen gefunden, der auf 1,8 Volt Basis arbeitet. (Gibt es überhaupt z.B. WLAN Module auf 1,8 Volt Basis ?)

Da tun es ganz einfache von jedem Makershop (auch wenn sie mit 3.3V angegeben sind), zumindest wenn man einen 3.3V UART dongle hat.