FB 6591 verschiedenes

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,707
Punkte für Reaktionen
28
Punkte
48
Es bringt ihr ohnehin nichts. Es funktioniert nicht.
 

stoney

Moderator
Teammitglied
Mitglied seit
7 Okt 2015
Beiträge
5,047
Punkte für Reaktionen
364
Punkte
83

depadre

Neuer User
Mitglied seit
12 Okt 2019
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
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

Neuer User
Mitglied seit
29 Apr 2007
Beiträge
95
Punkte für Reaktionen
10
Punkte
8
Korrekt: Funktioniert mit meiner "freien" 6591 auch nicht. Und bricht mit besagter CRC-Fehlermeldung ab.
 

depadre

Neuer User
Mitglied seit
12 Okt 2019
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Hast du mal versucht, den Datenverkehr, beispielsweise mit SMSNIFF aufzuzeichnen, während der Prozess läuft? Ggf. sind darin weitere Zugangsmöglichkeiten versteckt
 

jebeyer

Neuer User
Mitglied seit
29 Apr 2007
Beiträge
95
Punkte für Reaktionen
10
Punkte
8
Nö, noch nicht. Hat bei mir erst mal keine Prio. Gibt erst mal wichtigeres (privat)... ;)
 

Flole

Neuer User
Mitglied seit
23 Dez 2013
Beiträge
176
Punkte für Reaktionen
3
Punkte
18
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:

C:
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

Moderator
Teammitglied
Mitglied seit
17 Aug 2004
Beiträge
20,925
Punkte für Reaktionen
85
Punkte
48
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

Neuer User
Mitglied seit
27 Jan 2014
Beiträge
7
Punkte für Reaktionen
6
Punkte
3
So ... hab es nun auch endlich geschafft (keine Provider-Box - selber gekauft):

Code:
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.

Code:
### 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?

Code:
# 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:
Code:
# 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:

Code:
echo -n "" > /var/flash/fw_attrib
 
Zuletzt bearbeitet:

fesc

Mitglied
Mitglied seit
14 Mai 2016
Beiträge
221
Punkte für Reaktionen
29
Punkte
28
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..
 
  • Like
Reaktionen: YourNameInHere

depadre

Neuer User
Mitglied seit
12 Okt 2019
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
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

Mitglied
Mitglied seit
14 Mai 2016
Beiträge
221
Punkte für Reaktionen
29
Punkte
28
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.
 
Zuletzt bearbeitet:

fritz.fichtl

Neuer User
Mitglied seit
27 Dez 2018
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
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

Moderator
Teammitglied
Mitglied seit
7 Okt 2015
Beiträge
5,047
Punkte für Reaktionen
364
Punkte
83
  • Wow
Reaktionen: betaman2

jebeyer

Neuer User
Mitglied seit
29 Apr 2007
Beiträge
95
Punkte für Reaktionen
10
Punkte
8
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

Neuer User
Mitglied seit
23 Dez 2013
Beiträge
176
Punkte für Reaktionen
3
Punkte
18
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

Neuer User
Mitglied seit
11 Nov 2019
Beiträge
1
Punkte für Reaktionen
0
Punkte
1
@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

Mitglied
Mitglied seit
14 Mai 2017
Beiträge
220
Punkte für Reaktionen
21
Punkte
18
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
Code:
:~/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"
 
Zuletzt bearbeitet:

prisrak1

Mitglied
Mitglied seit
14 Mai 2017
Beiträge
220
Punkte für Reaktionen
21
Punkte
18
hab noch was:
Code:
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
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
233,328
Beiträge
2,032,859
Mitglieder
351,893
Neuestes Mitglied
erutuf