FB 6591 verschiedenes

[Chatty]

Es bringt ihr ohnehin nichts. Es funktioniert nicht.

 

[stoney]

solche Anfragen sind eig. hier
[Sammlung] Suche Firmware & Recover-Images
zu platzieren.
(wurde nicht verschoben, wg dem Hinweis von @Chatty)

 

[depadre]

Vielen Dank für die Hinweise, bitte entschuldigt. Nachdem ich nun einen ersten Blick auf das Recovery werfen konnte - funktioniert dieses auch mit ungebrandeten Versionen nicht?

 

[jebeyer]

Korrekt: Funktioniert mit meiner "freien" 6591 auch nicht. Und bricht mit besagter CRC-Fehlermeldung ab.

 

[depadre]

Hast du mal versucht, den Datenverkehr, beispielsweise mit SMSNIFF aufzuzeichnen, während der Prozess läuft? Ggf. sind darin weitere Zugangsmöglichkeiten versteckt

 

[jebeyer]

Nö, noch nicht. Hat bei mir erst mal keine Prio. Gibt erst mal wichtigeres (privat)...

 

[Flole]

Wenn man einen Blick in den Bootloader wirft dann ist auch klar warum das nicht funktionieren kann. Um die Jumptable da drin mal in C Code auszudrücken findet man dort in etwa sowas:

switch(command) {
    case "STOR":
    case "RETR":
    case "CHECK":
        sendResponse("551 unknown Mediatype\r\n");
        break:
    case "...":
    .....
}

Ich weiß ja nicht nach was für Zugangsmöglichkeiten @depadre sucht aber die Suche sollte man besser im Bootloader fortsetzen als im Datenverkehr. Im übrigen wird der CRC Check mit ziemlich großer Wahrscheinlichkeit vor dem Schreiben der Firmware durchgeführt, es ist ja sinnfrei erstmal Mist reinzuschreiben und dann festzustellen das man grad Mist geschrieben hat.

 

[Novize]

Bitte hier keine Firmware anfragen und über den Sinn der Anfrage diskutieren - die betreffenden Beiträge sind ordnungsgemäß dem sortenreinen Recycling überführt worden.

 

[YourNameInHere]

So ... hab es nun auch endlich geschafft (keine Provider-Box - selber gekauft):

ssh [email protected]


BusyBox v1.24.2 (2019-08-16 14:06:18 CEST) built-in shell (ash)

# uname -a
Linux fritz.box 3.12.74 #1 SMP PREEMPT Wed Oct 2 10:57:19 CEST 2019 i686
# /etc/version
161.07.12
# id
uid=0(root) gid=0(root) groups=0(root)
#

Vielen Dank an @fesc für die Anleitung und die Bereitstellung der ffritz-Sourcen!

Ich habe das ganze via ATOM-Console gemacht und dabei einen USB2Serial-Adapter verwendet welcher gleich 1.8V kann (Modell: DSD TECH SH-U09C5 via amazon). Löten war nicht notwendig - es hat bei mir gereicht die 3 Pins (RX, TX und GND) ein wenig schief zu stecken.

Hier noch eine Info wie man den kompletten Datenbestand vorab sichert:

Benötigt wird dazu ein USB-Stick der mehr als 8GB Nutzdaten zulässt.
Ich habe diesen mit ext4 formatiert und an die FB6591 gesteckt.

### USBSTICK-Namen raussuchen (oder beim Einstecken aus dem Consolen-Output merken):

# mount | grep /dev/sda1

# mkdir -p /var/media/ftp/<USBSTICK-NAME>/dev

# find /dev -name mmcblk0* | while read line; do dd if="$line" of=/var/media/ftp/<USBSTICK-NAME>"$line"; done
4096+0 records in
4096+0 records out
4096+0 records in
4096+0 records out
dd: /dev/mmcblk0rpmb: Input/output error
6805471+0 records in
6805471+0 records out
262144+0 records in
262144+0 records out
16384+0 records in
16384+0 records out
16384+0 records in
16384+0 records out
16384+0 records in
16384+0 records out
16384+0 records in
16384+0 records out
81920+0 records in
81920+0 records out
38912+0 records in
38912+0 records out
10240+0 records in
10240+0 records out
147456+0 records in
147456+0 records out
18432+0 records in
18432+0 records out
256+0 records in
256+0 records out
81920+0 records in
81920+0 records out
38912+0 records in
38912+0 records out
10240+0 records in
10240+0 records out
147456+0 records in
147456+0 records out
18432+0 records in
18432+0 records out
256+0 records in
256+0 records out
7733248+0 records in
7733248+0 records out
#
# du -h /var/media/ftp/<USBSTICK-NAME>/dev/*
3.7G    mmcblk0
2.0M    mmcblk0boot0
2.0M    mmcblk0boot1
128.0K  mmcblk0p1
5.0M    mmcblk0p10
19.0M   mmcblk0p11
40.0M   mmcblk0p12
8.0M    mmcblk0p13
8.0M    mmcblk0p14
8.0M    mmcblk0p15
8.0M    mmcblk0p16
128.0M  mmcblk0p17
3.2G    mmcblk0p18
9.0M    mmcblk0p2
72.0M   mmcblk0p3
5.0M    mmcblk0p4
19.0M   mmcblk0p5
40.0M   mmcblk0p6
128.0K  mmcblk0p7
9.0M    mmcblk0p8
72.0M   mmcblk0p9
0       mmcblk0rpmb
# sync
# sync
# umount /dev/sda1

Danach kann der Stick entfernt werden.
Man hat jetzt einmal alle einzelnen Partitionen (ausser /dev/mmcblk0rpmb - was auch immer das ist) und mit "mmcblk0" nochmal den kompletten Inhalt des eMMC-Speichers.


@fesc sollte der ARM-Login von der ATOM-Console eigentlich funktionieren? Bei mir scheint weder telnetd noch dropbear im ARM-Kontext zu laufen oder habe ich einen Denkfehler?

# rpc sh -c "ps  | grep dropbear"
14496 root      2160 S    sh -c ps  | grep dropbear
14498 root      2160 S    grep dropbear

# rpc sh -c "sh -x /usr/bin/dropbear"
+ basename /usr/bin/dropbear
+ COMMAND=dropbear
+ readlink -f /usr/bin/dropbear
+ COMMAND_PATH=/usr/lib/ff/exec/ffwrap
+ dirname /usr/lib/ff/exec/ffwrap
+ EXEC_DIR=/usr/lib/ff/exec
+ readlink -f /usr/lib/ff/exec/../lib
+ export LD_LIBRARY_PATH=/usr/lib/ff/lib
+ exec /usr/lib/ff/exec/dropbear
/usr/bin/dropbear: exec: line 10: /usr/lib/ff/exec/dropbear: not found

# rpc sh -c "ls -la /usr/lib/ff/exec/dropbear"
-rwxr-xr-x    1 root     root        227476 Oct 31 11:35 /usr/lib/ff/exec/dropbear

Danke!

EDIT:
Ok es braucht wohl nur noch den Befehl "armconsole" damit man auf den ARM-Core kommt:

# armconsole

BusyBox v1.24.2 (2019-08-16 14:02:43 CEST) built-in shell (ash)

ermittle die aktuelle TTY
tty is "/dev/pts/1"
weitere telnet Verbindung aufgebaut
disable start/stop characters and flowcontrol
# uname -a
Linux fritz.box 3.12.74 #1 PREEMPT Wed Oct 2 11:02:48 CEST 2019 armv6b

wieder was gelernt

EDIT2:

Damit das FB-Webinterface nicht "Vom Hersteller nicht unterstützte Änderungen Weitere Informationen" anzeigt, hat bei mir folgendes geholfen:

echo -n "" > /var/flash/fw_attrib

 

[fesc]

sollte der ARM-Login von der ATOM-Console eigentlich funktionieren

Die ARM toolchain fuer 6591/Puma7 habe ich noch nicht in Angriff genommen, kommt irgendwann noch. Für den Alltagsbetrieb gibt es allerdings eh nix was man da sinnvolles laufen lassen könnte.
Im Gegenteil, das Design hätte es hergegeben dass man den DOCSIS/ARM Teil abriegelt (damit die Provider glücklich sind), und den Atom (Router/Anwendungen) öffnet.

Danke für den tip mit dem 1.8V dongle..

 

[depadre]

Habe ich es richtig verstanden, dass ich über die Atom-Konsole die 6591 debranden kann, wenn ich den Patch aus deinem Bitbucket benutze, der die ovm Variablenübername aus dem bootloader unterdrückt?

Ich weiß ja nicht nach was für Zugangsmöglichkeiten @depadre sucht aber die Suche sollte man besser im Bootloader fortsetzen als im Datenverkehr. Im übrigen wird der CRC Check mit ziemlich großer Wahrscheinlichkeit vor dem Schreiben der Firmware durchgeführt, es ist ja sinnfrei erstmal Mist reinzuschreiben und dann festzustellen das man grad Mist geschrieben hat.

Bitte verzeih mir mein offensichtlich beschränktes Wissen, aber wenn die Firmware das einzig kaputte in dem Recoverytool ist, so müsste das Programm doch einen anderen Zugangsweg eröffnen, als das Gehäuse aufschrauben zu müssen, ist der Gedanke so abwegig?

 

[fesc]

die 6591 debranden kann

Debranden im eigentlichen Sinne nicht, aber es gibt Gerüchte dass damit die Retail Firmware bootet ;-)
Ich kann allerdings nicht sagen ob das Nebenwirkungen an anderen Ecken hat, und automatischen update sollte man abschalten.

 

[fritz.fichtl]

Weiß hier jemand ob die Retail und Providerboxen der 6591 unterschiedliche Artikelnummern haben? Bei der 6490 hat es ja mindestens 6 verschiedene Artikelnummern gegeben.

 

[stoney]

FRITZ!Box 6591 Cable - BoxMatrix

boxmatrix.info

20002844 = Provider (welcher Provider oder ob es mehrer/verschiedene gibt.... ?!)

20002857 = Retail

 

[jebeyer]

Die 6591 gibt es mittlerweile von 3 KNB: VFKD, UM und seit neuesten auch von Pyur.

20002858: VFKD, möglicherweise gilt die jetzt auch für UM, die "Ur"-6591 von UM hatte ja eine silbergraue Frontblende.
Pyur habe ich jetzt erst mal nix gefunden.

 

[Flole]

Bitte verzeih mir mein offensichtlich beschränktes Wissen, aber wenn die Firmware das einzig kaputte in dem Recoverytool ist, so müsste das Programm doch einen anderen Zugangsweg eröffnen, als das Gehäuse aufschrauben zu müssen, ist der Gedanke so abwegig?

Schick mir das Ding mal zu dann kann will ich mir das gerne mal anschauen, aber ich bin mir fast sicher das es nicht funktionieren kann. Im übrigen gibt es ja auch schon eine Möglichkeit ohne öffnen des Gehäuses.....

 

[No0pe]

@Fiole: hab seit nem Monat ne 6591 zum testen hier und noch nichts bzgl. ausreichendem Software-Zugang gefunden. Hast du mehr Infos für uns?

Nebenbei:
KDG = 20002858

 

[prisrak1]

was fehlt? hab auch schon in:
mkdir -p dl/fw
zcat GPL-kernel.tar.gz | xz -zc9ev -T 0 > GPL-kernel.tar.xz
ls -l dl/fw

`git clone https://[email protected]/fesc2000/ffritz.git`
make

:~/freetz/ffritz$ make
fakeroot make clean
make: fakeroot: Kommando nicht gefunden
Makefile:196: recipe for target 'release' failed
make: *** [release] Error 127

und "git pull"

 

[YourNameInHere]

make: fakeroot: Kommando nicht gefunden

fakeroot scheint nicht installiert zu sein (debian/ubuntu):
sudo apt-get install -y fakeroot

 

[prisrak1]

hab noch was:

patching file etc/docsis/nvramdontremove
PATCH  arm/squashfs-root
PACK  arm/squashfs-root
/bin/sh: 1: unsquashfs: not found
Makefile:169: recipe for target 'atom/squashfs-root' failed
make[1]: *** [atom/squashfs-root] Error 127
make[1]: Leaving directory '/home/user/freetz/ffritz'
Makefile:196: recipe for target 'release' failed
make: *** [release] Error 2