[Gelöst] F!B 6591 Bootloop

Beim FTP müssen schon der Client und der Server ein GEMEINSAMES Verständnis der Datenübertragung haben. Ein quote P@SW schaltet zwar (erkennbar) den Server in den passiven Modus, aber der Client hat davon keine Ahnung (Kommandos werden mit quote eben direkt an den Server gesendet und gar nicht erst weiter analysiert) und der muß schließlich die Datenverbindung anwerfen.

Das Äquivalent zum serverseitigen RETR-Kommando (und man sieht ja auch, daß der Server den Dateinamen "verstanden" hat im Gegensatz zu cfg) ist dann auf dem Client ein get und sofern der sich ebenfalls im passiven Modus befindet, wird er VOR der Übermittling des RETR (im Ergebnis des get für ihn selbst) die passende Verbindung für den Data-Channel aufbauen, in die der Server die Daten dann schreiben kann.

Aber das ist FÜR ALLE Kommandos mit Übertragungen im Data-Channel dasselbe und mit dem oben gezeigten Ablauf, kriegst Du auch keine anderen "Dateien" in die oder aus der Box.

Man könnte natürlich auch einfach auf die EVA-Tools in meinem Yourfritz-Repository zurückgreifen, die sind EXTRA für diese Zwecke gedacht und gemacht.

Auf der Seriellen gibt es m.W. in EVA gar keine Dateiübertragungen (dazu müßte man ja ein passendes Wrapper-Protokoll implementieren, z.B. XMODEM: https://en.m.wikipedia.org/wiki/XMODEM) und dort sollte tatsächlich auch ein help die verfügbaren Kommandos auflisten.

Mist, jetzt ist der gespeicherte Entwurf meiner Antwort an den TO, den ich erst noch etwas sacken lassen wollte bzw. wo ich noch etwas mit meiner 6690 testen wollte, dieser Antwort zum Opfer gefallen. Mal sehen, ob ich das alles noch einmal schreibe …
 
Man könnte natürlich auch einfach auf die EVA-Tools in meinem Yourfritz-Repository zurückgreifen, die sind EXTRA für diese Zwecke gedacht und gemacht.
Danke für die Erläuterungen, nur ein script was ausser dem environment auch eine config (Urlader) ausliesst kann ich in deinem repository (dem öffentlichen Teil) nicht erkennen. Das Problem scheint zu sein, daß ein Ändern mtd3 mittels externem/internem Editor und anschließendem Zurückspielen irgendwie zu Problemen führt bei KDG-Gebrandeten Boxen, da die komplexe Bootoptionen mit Symbiose von Urlader und Bootloaderenvironment zum Teil flöten gehen und iirc die LGI-Firmwares auch mit avm-Branding zurecht kamen? (so meine Erfahrung aus 6490-Spielchen)
 
Zuletzt bearbeitet:
Danke für eure Antworten.

Ich hab auch RETR config probiert.

Danke für die Erläuterungen, nur ein script was ausser dem environment auch eine config (Urlader) ausliesst kann ich in deinem repository (dem öffentlichen Teil) nicht erkennen.
Dito, ich hab die Datei eva_get_environment als dirty hack angepasst um das von PeterPawn beschrieben FTP handling zu nutzen:
Diff:
diff --git a/eva_tools/eva_get_environment b/eva_tools/eva_get_environment
index 168d724..1592747 100755
--- a/eva_tools/eva_get_environment
+++ b/eva_tools/eva_get_environment
@@ -76,7 +76,7 @@ login_to_box()
 }
 get_environment()
 {
-    local instream="$1" outstream="$2" log="$3" lines=0 remote=${4:-env} subsys_id=$5
+    local instream="$1" outstream="$2" log="$3" lines=0 remote=${4:-config} subsys_id=$5
     write_ftp_command "TYPE I" $outstream $log
     line="$(read_ftp_response $instream $log)"
     ec=${line:0:3}

Und heureka es hat eine 256KB große Datei geschrieben. Vielen Dank @PeterPawn.

1714598671197.png

(von mir in rot sind nur die MAC Adressen / secrets ersetzt)

Die SerialNumber ist hier auf ..0000.. gesetzt. D.h. die wird später irgendwo gesetzt? Ist das richtig?

Könnte es sein, daß das Branding durch Editieren des gesicherten mtd3 und nur RTL=y verändert, sich die Box ein Stock-Image von kdg gezogen hat und aufgrund eines alten BIOS adam2 ins Leere läuft?
...
Noch ganz vergessen: Ich weiss nicht, ob es eine Rolle spielt, meine FB war ursprünglich 'lgi'.
 
Danke für den Tipp. Ich habe das env mal durch config ersetzt und als eva_get_config abgespeichert.

Code:
#! /bin/sh
# SPDX-License-Identifier: GPL-2.0-or-later
#The original script and merits belongs to PeterPawn alias Peter Hämmerlein and his smooth Github-Repository to find at
#https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/eva_get_environment
#Just a poor Try for Beginners to change argument who doesnt recognize/found the unique  www-source at an edited post in the very past
# Have look at https://www.ip-phone-forum.de/threads/6490-ohne-ansprechbaren-bootloader.303402/post-2381472
#So feel free to use or let it be
# 
#instead of enviroment
#
# read config from FRITZ!Box 
#
#
# check if incompatible shell is used, this will cause issues, so we rather exit
if ! ( printf "\n" | read -u 0 2>/dev/null ); then
    echo "wrong shell interpreter" 1>&2
    exit 1
fi
# some constants to be changed, if needed
#
box_ip=${2:-192.168.178.1} # EVA_IP may be the second parameter (the 1st is the virtual file name) and defaults to 192.168.178.1
( [ -z "$4" ] && ! [ "$3" = "0" ] && ! [ "$3" = "1" ] ) && box_media="$3" || box_media="${4:-SDRAM}"
box_port=21
box_user=adam2
box_pass=adam2
if [ x"$3" != x"0" -a x"$3" != x"1" ]; then # subsystem id may be the third argument
    subsys_id=""
else
    subsys_id="$3"
fi
passive_ftp="P@SW"
[ ${#TMP} -eq 0 ] && TMP=/tmp
tmpdir=$TMP/tmp_$(date +%s)_$$
writefifo=$tmpdir/write
readfifo=$tmpdir/read
storefifo=$tmpdir/store
outstream=7
instream=8
upstream=9
logstream=3
logfile=eva_get_config_session.log
configfile=$tmpdir/config
startaddress=0x80000000
#
# helper functions
#
read_ftp_response()
{
    local line="   -" rc=0 instream="$1" log="$2"
    while read -u $instream -r line; do
        [ ! -z "$log" ] && echo "$line" >&$log
        [ "${line:3:1}" != "-" ] && break
    done
    rc=$?
    echo "$line"
    return $rc
}
write_ftp_command()
{
    local outstream="$2" cmd="$1" log="$3"
    [ ! -z "$log" ] && echo "$cmd" >&$log
    echo "$cmd" >&$outstream
}
login_to_box()
{
    local instream="$1" outstream="$2" log="$3" lines=0
    write_ftp_command "USER $box_user" $outstream $log
    while [ $lines -lt 10 ]; do
        line="$(read_ftp_response $instream $log)"
        ec=${line:0:3}
        if [ x$ec == x331 ]; then
            write_ftp_command "PASS $box_pass" $outstream $log
        else
            if [ x$ec == x230 ]; then
                return 0
            elif [ x$ec == x530 ]; then
                return 1
            fi
            
        fi
        lines=$(( lines++ ))
    done
}
get_config()
{
    local instream="$1" outstream="$2" log="$3" lines=0 remote=${4:-config} subsys_id=$5
    write_ftp_command "TYPE I" $outstream $log
    line="$(read_ftp_response $instream $log)"
    ec=${line:0:3}
    if [ x$ec != x200 ]; then
        return 1
    fi
    write_ftp_command "MEDIA $box_media" $outstream $log
    line="$(read_ftp_response $instream $log)"
    ec=${line:0:3}
    if [ x$ec != x200 ]; then
        return 1
    fi
    if ! [ -z $subsys_id ]; then
        write_ftp_command "SETENV subsys_id $subsys_id" $outstream $log
        line="$(read_ftp_response $instream $log)"
        ec=${line:0:3}
        if [ x$ec != x200 ]; then
            return 1
        fi
    fi
    write_ftp_command "$passive_ftp" $outstream $log
    line="$(read_ftp_response $instream $log)"
    ec=${line:0:3}
    if [ x$ec == x227 ]; then
        data_conn=$(echo $line | sed -n -e 's/.*(\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\)).*/data_ip=\1.\2.\3.\4 data_port=\$(( \5 * 256 + \6 ))/p')
        if [ ${#data_conn} -eq 0 ]; then
            return 1 
        fi
        eval "$data_conn"
        nc -d -w 60 $data_ip $data_port >$configfile &
        data_connection=$!
        sleep 1
        write_ftp_command "RETR $remote" $outstream $log
        line="$(read_ftp_response $instream $log)"
        ec=${line:0:3}
        if [ x$ec == x150 ]; then
            line="$(read_ftp_response $instream $log)"
            ec=${line:0:3}
            if [ x$ec == x226 ]; then
                if [ -d /proc/$data_connection ]; then
                    kill $data_connection 2>/dev/null &
                    wait $data_connection 2>/dev/null
                fi
                data_connection=""
                echo $configfile
                return 0
            fi
        else
            return 1
        fi
    else
        return 1
    fi
}
#
# check, if "mkfifo" and "nc" are present and usable
#
mkfifo 2>/dev/null
if [ $? -eq 127 ]; then
    echo "Missing usable 'mkfifo' command."
    exit 1
fi
command -v nc 2>/dev/null 1>&2
if [ $? -ne 0 ]; then
    echo "Missing any 'nc' command, it's needed for network communication and the OpenBSD version is required."
    exit 1
fi
# there's no unique identity for the BSD version, so we check for GNU version here
nc -V 2>/dev/null | grep -q GNU
if [ $? -eq 0 ]; then
    echo "Found GNU version of 'nc' command, but the OpenBSD version is required."
    exit 1
fi
#
# build redirections for FTP with "nc"
#
mkdir -p $tmpdir
mkfifo $writefifo
rc=$?
if [ $rc -ne 0 ]; then
    echo "Error $rc creating write fifo $writefifo."
    rm -r $tmpdir
    exit 1
fi
mkfifo $readfifo
rc=$?
if [ $rc -ne 0 ]; then
    echo "Error $rc creating read fifo $readfifo."
    rm $writefifo
    rm -r $tmpdir
    exit 1
fi
mkfifo $storefifo
rc=$?
if [ $rc -ne 0 ]; then
    echo "Error $rc creating upload fifo $storefifo."
    rm $writefifo
    rm $readfifo
    rm -r $tmpdir
    exit 1
fi
eval "exec $outstream<>$writefifo"
rc=$?
if [ $rc -ne 0 ]; then
    echo "Error $rc connecting write fifo to output stream."
    rm $writefifo    
    rm $readfifo
    rm $storefifo
    rm -r $tmpdir
    exit 1
fi
eval "exec $instream<>$readfifo"
rc=$?
if [ $rc -ne 0 ]; then
    echo "Error $rc connecting read fifo to input stream."
    eval "exec $outstream>&-"
    rm $writefifo
    rm $readfifo
    rm $storefifo
    rm -r $tmpdir
    exit 1
fi
eval "exec $logstream<>$logfile"
rc=$?
if [ $rc -ne 0 ]; then
    echo "Error $rc connecting log stream to log file."
    eval "exec $instream>&-"
    eval "exec $outstream>&-"
    rm $writefifo
    rm $readfifo
    rm $storefifo
    rm -r $tmpdir
    exit 1
fi
#
# now open a connection to the box
#
nc $box_ip $box_port <&$outstream >&$instream 2>/dev/null &
control_connection=$!
data_connection=""
line="$(read_ftp_response $instream $logstream)"
ec=${line:0:3}
if [ x$ec == x220 ]; then
    login_to_box $instream $outstream $logstream
    if [ $? -eq 0 ]; then
        write_ftp_command "SYST" $outstream $logstream
        line="$(read_ftp_response $instream $logstream)"
        ec=${line:0:3}
        if [ x$ec == x215 ]; then    
            syst=$(echo "$line" | sed -n -e "s/.*\(AVM EVA\).*/\1/p")
            if [ ${#syst} -ne 0 ]; then
                echo "Found AVM bootloader: ${line:4}" 1>&2
                config=$(get_config $instream $outstream $logstream $1 $subsys_id)
                if [ $? -eq 0 ]; then
                    echo "config read from device:" 1>&2
                    cat $config
                fi
            else
                echo "Unexpected system found: ${line:4}"
            fi
        fi
    else
        echo "Login failed."
    fi
else
    echo "Error connecting to FRITZ!Box boot loader."
fi
if [ ${#data_connection} -ne 0 ]; then
    if [ -d /proc/$data_connection ]; then
        kill $data_connection 2>/dev/null &
        wait $data_connection 2>/dev/null
    fi
fi
if [ ${#control_connection} -ne 0 ]; then
    if [ -d /proc/$control_connection ]; then
        kill $control_connection 2>/dev/null &
        wait $control_connection 2>/dev/null
    fi
fi
eval "exec $logstream>&-"
eval "exec $instream>&-"
eval "exec $outstream>&-"
rm $writefifo
rm $readfifo
rm -r $tmpdir
exit 1
und das funktioniert mit einem bash davor bei mir sehr schön.

Auszug der log-datei
Code:
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.3614 0x0 0xF6001
TYPE I
200 Type set to BINARY
MEDIA 
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,59,99)
RETR config
150 Opening BINARY data connection
226 Transfer complete
Danke an PeterPawn für die schönen scripte.

Im oberen Teil hinter diversen aes-keys und Co sollten auch alle Daten komplett gelistet sein @porcupine

Code:
.cmac_kcexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx710 0�I�H�_ ��u�0k�5D��x/ji���/��W���f�`����
                                                                                                                           �maca2C:91:AB:xx:xx:xxmacb2C:91:AB:xx:xx:xx�macwlan2C:91:AB:xx:xx:xxacwlan22C:91:AB:xx:xx:xxmacdsl2C:91:AB:xx:xx:xx usb_board_mac2C:91:AB:xx:xx:xx usb_rndis_mac2C:91:AB:xx:xx:xxHWRevision233HWSubRevision8�ProductIDFritz_Box_HW233SerialNumberM17311111111111
                                                             annexKabelusb_device_id0x0000usb_device_nameUSB DSL Deviceusb_revision_id0x0000�usb_manufacturer_nameAVMfirmware_versionavmwlan_key1111111111111111111"wlan_ssidFRITZ!Box#6591#Cable#IN!tr069_serial00040E-2C91ABxxxxxxtr069_passphrase1blablablawebgui_passpeter1234

(Leider bringt mich das bei meinem Problem des fehlenden WLANs nicht weiter oder ich erkenne es in der config nicht. Laut der support-datei, werden wlan.bin "heruntergeladen" aus einem mir unbekannten Bereich und mit den verschiedenen WLAN-Chip-Hersteller-binaries zu einem eeprom verwurstet, was dann div. Einstellungen wie Sendestärke etc. vorhält.)

Sollte das bei dir @pocupine fehlerhaft sein, könnte es übel sein. Ansonsten nochmals mit einem geeigneten ftp-client zu flashen versuchen. Ich nutze stets die Anweisungen aus der fesc-Quelle. https://bitbucket.org/fesc2000/ffritz/src/6591/README-6591.md Mit Ubuntu funktioniert es hier auch ohne die eva-tools.

EDIT2: Der Header im Script wurde wunschgemäss nochmals angepasst
 
Zuletzt bearbeitet:
Danke.

Die aes-keys und Co sehe ich bei mir auch. Das sollte (hoffentlich) passen.

Aber hab grad noch festgestellt, dass es in der config-Datei zwei Bereiche gibt in denen DeviceInfos stehen:

  • Einmal bei Offset 0x000096A0
    • hier gibt es bei mir eine valide SerialNumber
    • DMC.RTL fehlt komplett
  • Einmal bei Offset 0x0003A000
    • hier ist die Serialnumber 0000000000000000
    • DMC.RTL=y
Ist das bei Dir vergleichbar @Queer-new?

Die config-Datei ist bis auf den Bereich mit den aes-keys und den zwei Bereichen für DeviceInfos ansonsten komplett leer.

(Leider bringt mich das bei meinem Problem des fehlenden WLANs nicht weiter oder ich erkenne es in der config nicht. Laut der support-datei, werden wlan.bin "heruntergeladen" aus einem mir unbekannten Bereich und mit den verschiedenen WLAN-Chip-Hersteller-binaries zu einem eeprom verwurstet, was dann div. Einstellungen wie Sendestärke etc. vorhält.)
Falls ich meine FB irgendwie doch wieder hinbekomme kann ich gern versuchen zu helfen.
D.h. Dein System bootet normal aber der WLAN Treiber schmiert ab?
 
Ist das bei Dir vergleichbar
Das sieht sowohl auf einer intakten als auch meiner Problembox identisch aus.
Falls ich meine FB irgendwie doch wieder hinbekomme kann ich gern versuchen zu helfen.
Danke, ich kann jede Hilfe gebrauchen.
D.h. Dein System bootet normal aber der WLAN Treiber schmiert ab?
Ja die Grundconfig wie SSID und Key werden geladen als cfg. Nur werden die richtigen Daten nicht gefunden?

Code:
BEGIN SECTION '/proc/avm/log_sd/crash'
----------
:01.07/[0067.600]:[INF]netlink_steering_messages_close:502: closing steering netlink socket 0
01:01.08/[0068.010]:[ERR]_system:212: command "killall -2 hostapd" returned 1 (called in cfg_hal_stop_hostapd, line 4070)
01:01.08/[0068.010]:[ERR]lib_hal_hardware_deinit:886: failed to stop hostapd or wpa_supplicant
01:01.08/[0068.040]:[ERR]lib_hal_hardware_deinit:899: failed to unload driver kernel modules
01:01.08/[0068.050]:[INF]wlanser_config_init:1040: ENTER(cfg_product='/etc/default/%s/wlan_product.cfg', cfg_profiles'/etc/default/%s/wlan_product_profiles.cfg', trans=0x0x6ed11018)
01:01.08/[0068.060]:[INF]wlanser_config_init:1062: Read and apply product config: Init transaction succeeded
01:01.08/[0068.070]:[ERR]_cfg_mgr_read_calibration_data:244: Failed to open '/proc/avm/calib/wlan2'
01:01.08/[0068.070]:[WRN]_cfg_mgr_get_calibration_data:358: Couldn't read '/proc/avm/calib/wlan2', ... never mind.
01:01.08/[0068.080]:[ERR]_cfg_mgr_read_calibration_data:244: Failed to open '/proc/avm/calib/wlan'
01:01.08/[0068.080]:[WRN]_cfg_mgr_get_calibration_data:358: Couldn't read '/proc/avm/calib/wlan', ... never mind.
01:01.08/[0068.120]:[WRN]cfg_hal_setup_eeprom:3993: no eeprom data in hw_info field 1
01:01.08/[0068.120]:[ERR]cfg_hal_setup_eeprom:3995: Failed to load firmware 1, no eeprom data in hw_info field
01:01.08/[0068.120]:[ERR]lib_hal_hardware_init:427: failed to create EEPROM device nodes
01:01.08/[0068.120]:[ERR]lib_hal_hardware_init:472: failed with status 0x80000001 (FAIL_GENERAL)
01:01.08/[0068.420]:[INF]sanity_chk_send_sanity_report:283: Sending crash report #2 with error 0401
01:01.10/[0070.430]:[INF]netlink_steering_messages_close:502: closing steering netlink socket -1
01:01.10/[0070.430]:[INF]netlink_steering_messages_close:505: steering netlink socket invalid (already closed?)
01:01.10/[0070.810]:[ERR]_system:212: command "killall -2 hostapd" returned 1 (called in cfg_hal_stop_hostapd, line 4070)
01:01.10/[0070.810]:[ERR]lib_hal_hardware_deinit:886: failed to stop hostapd or wpa_supplicant
01:01.10/[0070.810]:[ERR]lib_hal_hardware_deinit:899: failed to unload driver kernel modules
01:01.10/[0070.820]:[INF]wlanser_config_init:1040: ENTER(cfg_product='/etc/default/%s/wlan_product.cfg', cfg_profiles'/etc/default/%s/wlan_product_profiles.cfg', trans=0x0x6ed11018)
01:01.10/[0070.830]:[INF]wlanser_config_init:1062: Read and apply product config: Init transaction succeeded
01:01.10/[0070.850]:[ERR]_cfg_mgr_read_calibration_data:244: Failed to open '/proc/avm/calib/wlan2'
01:01.10/[0070.850]:[WRN]_cfg_mgr_get_calibration_data:358: Couldn't read '/proc/avm/calib/wlan2', ... never mind.
01:01.10/[0070.860]:[ERR]_cfg_mgr_read_calibration_data:244: Failed to open '/proc/avm/calib/wlan'
01:01.10/[0070.860]:[WRN]_cfg_mgr_get_calibration_data:358: Couldn't read '/proc/avm/calib/wlan', ... never mind.
01:01.10/[0070.930]:[WRN]cfg_hal_setup_eeprom:3993: no eeprom data in hw_info field 1
01:01.10/[0070.930]:[ERR]cfg_hal_setup_eeprom:3995: Failed to load firmware 1, no eeprom data in hw_info field
01:01.10/[0070.930]:[ERR]lib_hal_hardware_init:427: failed to create EEPROM device nodes
01:01.10/[0070.930]:[ERR]lib_hal_hardware_init:472: failed with status 0x80000001 (FAIL_GENERAL)

Vormals sah das so aus.

Code:
               Flash Download Address  c0000 
[   81.152570] ol_transfer_bin_file: flash data file defined
[   81.152654] ol_transfer_bin_file 3904: Download AVM WLAN EEPROM len 12064
[   81.152664] qc98xx_verify_checksum: flash checksum passed: 0x2d95
[   81.152667] ol_transfer_bin_file 4007: Download Flash data len 12064
[   81.152961] Board extended Data download address: 0x0
[   81.175307] 
                Board data initialized
[   81.175485] ol_ath_download_firmware: Download OTP, flash download ADDRESS 0xc0000
[   81.175490] 
                Selecting  OTP binary for CHIP Version 0
[   81.175544] ol_transfer_bin_file 3771: downloading file 0, Download data len 9212
[   81.205586]
wo aus dem FLASH was geladen und als funktionierend eingebunden wird. Irgendwie ist da etwas aus dem Lot geraten. Es könnte unter Umständen mit den Vodafone-Hotspots zusammenhängen, die bei den OEM-Modellen meines Wissens nicht aktivierbar sind.
 
ein script was ausser dem environment auch eine config (Urlader) ausliesst kann ich in deinem repository (dem öffentlichen Teil) nicht erkennen
Nun .. wenn ich einfach mal nach "retr config" eva_tools suchen lasse (https://www.google.com/search?q="retr+config"+eva_tools), dann findet man (ohne Werbung, die bei mir nicht stattfindet in den Ergebnissen einer Suche) genau eine einzige Fundstelle:
1714672178816.png
und da sollte man als aufmerksamer Leser auch sofort erkennen können, wie man für eva_get_environment einen alternativen ("entfernten") Dateinamen angibt, den man auslesen möchte ... und das ist dort auch noch genau config.

Tatsächlich fand (und finde) ich das soo offensichtlich (gerade auch für Leute, die sich das Skript ansehen und verstehen wollen, was da geschieht ... und zwar möglichst BEVOR sie es selbst ändern), was da als erster Parameter angegeben werden kann (man könnte sich ja auch fragen, warum vorne im Skript die Zuweisungen der "positional parameter" an Variablen erst mit $2 starten), daß ich (es ist ohnehin nur eine "Machbarkeitsstudie" wie man einen eigenen FTP-Client in Shell (bash) mittels netcat (bzw. nc) implementieren KÖNNTE) es nicht als erforderlich ansehe, neben den diversen Erklärungen in vielen Beiträgen (auch hier kann die Suche im Internet nach eva_get_environment gerne als "Beweis" selbst in Augenschein genommen werden) noch weiteres dazu (im Repository oder in den Skripten direkt) zu schreiben, was über den ohnehin vorhandenen Text in der readme.md (https://github.com/PeterPawn/YourFritz/tree/main/eva_tools#readme - die wird üblicherweise auch noch automatisch angezeigt beim HTTP-Zugriff auf das Unterverzeichnis im Repo) hinausgehen würde.

Es gibt dort genau vier (Shell-)Skripte dieses Typs (FTP-Kommunikation mit EVA) und mit denen werden praktisch alle relevanten Einsatzfälle abgedeckt und zwar mit so wenig wie möglich Redundanz im Code (wobei ein Abwägen zwischen dem Auslagern von Funktionen für den FTP-Zugriff und der Bequemlichkeit, die Datei(en) auch einzeln kopieren/laden zu können, erfolgen mußte). Sowohl das Schreiben und Lesen von "Dateien", als auch das Lesen und Setzen von Environment-Variablen und das Laden eines Image-Files in den RAM mit den dazu notwendigen Berechnungen werden exemplarisch gezeigt. Und dabei wird es auch bleiben - sorry.

Die Suche nach EIN PAAR Informationen (s.o.) halte ich absolut für zumutbar - bisher ist es auch schon vielen Benutzern gelungen, diese Hürden zu meistern. Auch der Name eva_get_environment ist (und bleibt) in meinen Augen gerechtfertigt, denn das genau ist es, was das Skript ausgibt, sofern man keinen anderen (gültigen!) Dateinamen beim Aufruf spezifiziert.



Aber egal ... wie man an sein Ziel kommt, spielt ja nur beim (eigenen) Aufwand eine Rolle und wer sich mit der Suche im Internet nicht auskennt, muß eben durch eine eher "harte Schule". Ich würde dennoch bitten, die "Vollversion" des geänderten Skripts in #24 mit klaren Hinweisen auf den Ursprung (der originalen Version) zu versehen (auch wenn das nur ein PoC ist/war) oder sie ggf. auch einfach mit Hinweis darauf, daß sie eigentlich überflüssig ist, zu entfernen. Denn auch dann, wenn sich einem menschlichen Leser bei kompletter Lektüre des Threads der Kontext erschließen mag, ist das bei einem Spider einer Suchmaschine noch lange nicht garantiert und da die Urheberinformationen sich nicht aus dem Skript selbst, sondern nur aus dem Repository, in dem das Original zu finden ist, ableiten lassen, könnten daraus Unklarheiten entstehen. Danke.



@porcupine:
Welche "Hintergedanken" hast Du denn beim Flashen? Warum überschreibst Du gleich immer beide Systeme (und das meint hier Slot 0 und Slot 1, nicht jeweils ARM+ATOM)? Hast Du jemals überprüft, ob ein Umschalten von linux_fs_start tatsächlich auch ohne Reboot von EVA wirksam wird? Denn das paßt eigentlich so gar nicht zu dem, was in Anleitungen stehen SOLLTE (mir ist auch klar, daß es viel zu viele falsche Nacherzählungen gibt) - üblicherweise schreibt man EIN System, das aus vier Partitionen besteht und WENN man das alternative (sprich: inaktive) Partition-Set beschrieben hat (den aktuellen Wert von linux_fs_start liest man eben VORHER aus und zwar möglichst in einer getrennten FTP-Session), dann ändert man vor dem Reboot noch den Wert von linux_fs_start.

Ich wollte ursprünglich noch einmal selbst mit meiner 6690 prüfen, ob sich Puma7-Geräte dabei ebenso wie Puma6-Boxen verhalten:
- aber da ich in diesem Punkt nicht sicher bin und im Moment nicht zum Testen komme, würde ich an Deiner Stelle einfach den "Weg der geringsten Gefahr" gehen, zuerst mal linux_fs_start auf 0 setzen und dann - nach einem Neustart des Routers, der nicht schaden kann - die Partitionen 0, 1, 6 und 7 "frisch" beschreiben (und zwar nur diese) und die Box dann neu booten, OHNE an linux_fs_start zu drehen.



Irgendwie ist da etwas aus dem Lot geraten.

Bei den Puma-Modellen werden zusätzliche Daten (u.a. eben das Zertifikat und natürlich auch der private Schlüssel dafür) in diesem Konfigurationsbereich abgelegt, dazu gehören auch Kalibrierungsdaten für die beiden WLAN-Adapter und DECT. Das wird dann von einem zusätzlichen Kernel-Treiber in BLOBs zerlegt, die unter /proc/avm in (Pseudo-)Unterverzeichnissen bereitgestellt werden.

Eigentlich kann man diese Infos nur dann beschädigen, wenn man irgendwelche Manipulationen am Bootloader vornimmt - so wäre jedenfalls MEIN Kenntnisstand. Nun kannst Du Dir ja mal überlegen, ob das bei Deiner Box der Fall sein könnte - denn offenbar funktionierte das zuvor ja noch, wie Deine Protokolle zeigen. Außerdem ist auch DAS ein (wenn nicht sogar: der) Grund, warum man nicht einfach 1:1 den Bootloader der einen auf eine andere Box übertragen kann (vielleicht weil man die CM-MAC und das Zertifikat ändern will, um die eigene Box doch noch beim Provider provisionieren zu lassen).



@fesc:
Sind die Zuordnungen bei Puma7 dynamisch (wie bei Puma6, denn m.W. gilt das von mir dazu Geschriebene - s. Link oben - auch für die 6590) oder sind die tatsächlich statisch, so daß 0, 1, 6 und 7 immer die Partitionen mit der 0 am Ende des Namens (also P2 bis P5) sind? Wenn Du das sicher weißt (weil Du es selbst getestet hast), kann ich mir den Test sparen.
 
Aber egal ... wie man an sein Ziel kommt, spielt ja nur beim (eigenen) Aufwand eine Rolle und wer sich mit der Suche im Internet nicht auskennt, muß eben durch eine eher "harte Schule". Ich würde dennoch bitten, die "Vollversion" des geänderten Skripts in #24 mit klaren Hinweisen auf den Ursprung (der originalen Version) zu versehen
Ich hoffe inständig, daß der korrigierte Header deinen Vorstellungen entspricht. (Eine Voranfrage schlug fehl, da PN abgelehnt?) Es lag mir fern, mich mit fremden Federn zu schmücken.

Die Suche nach EIN PAAR Informationen (s.o.) halte ich absolut für zumutbar - bisher ist es auch schon vielen Benutzern gelungen, diese Hürden zu meistern. Auch der Name eva_get_environment ist (und bleibt) in meinen Augen gerechtfertigt, denn das genau ist es, was das Skript ausgibt, sofern man keinen anderen (gültigen!) Dateinamen beim Aufruf spezifiziert.

Die Zahl der UserInnen, die die Abwandlung erfolgreich benutzen sind dir bekannt?
Ich habe wirklich keine Lust auf Disput, da ich Dazulernen möchte und mich nicht mit überholten, nichtmehr zeitgemässen "harten Schulen", auseinandersetzen möchte.

Das wird dann von einem zusätzlichen Kernel-Treiber in BLOBs zerlegt, die unter /proc/avm in (Pseudo-)Unterverzeichnissen bereitgestellt werden.

Eigentlich kann man diese Infos nur dann beschädigen, wenn man irgendwelche Manipulationen am Bootloader vornimmt

Genau dies habe ich versucht, indem ich den Bootloader gesichert hatte, mit nano editiert und dort only "firmware_version^@avm" von kdg auf avm und RTL=y gesetzt hatte und mit einem künen cat /var/media/ftp/bootloader.bin > /dev/mtdblock3 zum Erfolg zu führen als Debrandingmassnahme?

Das hatte schonmal funktioniert auf einer lgi-gebrandten 6591, weshalb ich halt konsterniert bin, weshalb nunmehr nur das WLAN streikt?

Edit: Ein Screenshot
 

Anhänge

  • Nano-Scrennshot.png
    Nano-Scrennshot.png
    34.5 KB · Aufrufe: 8
Zuletzt bearbeitet:
Die Zahl der UserInnen, die die Abwandlung erfolgreich benutzen sind dir bekannt?
Welche Abwandlung? Meinst Du tatsächlich die in diesem Thread seit dem (sehr) späten Mittwoch abend zu findende, gepatchte Version?

Und ganz ehrlich - ich bin mit dem geänderten Header nur so semi zufrieden … denn Dein Zusatz, der mit der von mir empfohlenen Suche gefundene Thread wäre die einzige Fundstelle im Internet, wo die Verwendung von eva_get_environment mit der Angabe von Dateinamen beschrieben wurde, ist beweisbar falsch. Es gibt genug andere "Fundstellen", wenn man (smart genug) danach sucht - selbst @porcupine müßte eigentlich schon zuvor davon gelesen haben, denn auch beim Zusammenbau eines eigenen TFFS-Images braucht man ja i.d.R. neben dem Environment noch die Zähler (selbst wenn die bei Puma-Chipsets keine sinnvollen Werte enthalten) und die meisten Anleitungen für build_tffs_image, die ich kenne, "erwähnen" die Verwendung von eva_get_environment in diesem Zusammenhang.

mich nicht mit überholten, nichtmehr zeitgemässen "harten Schulen", auseinandersetzen möchte
Wenn Du die eigenständige, zielgerichtete Recherche nach Informationen im Internet für "nicht mehr zeitgemäß" hältst, mag das ja Dein Standpunkt sein - ich hoffe aber inständig, daß dieser nicht von einer Mehrheit geteilt wird, denn nach meiner Überzeugung werden dadurch knappe Ressourcen, die auch von anderen benötigt werden, von rücksichtslosen Nutzern zu ihrem eigenen Vorteil über Gebühr beansprucht und ausgebeutet.

mit nano editiert
ICH frage mich ja eher, wieso jemand einen textorientierten Editor zum Ändern von binären Daten verwenden würde. Dafür gibt es spezialisierte Programme (sog. Hex-Editoren) und mit denen riskiert man dann auch nicht, unbeabsichtigt binäre Daten zu verändern.

Da Du ja sicherlich noch "das Original" des von Dir "gepatchten" Loaders hast, würde ich mich zunächst mal vergewissern, daß dort noch die Kalibrierungsdaten enthalten sind und - sofern das der Fall sein sollte - DAMIT noch einmal von vorne beginnen; vielleicht hast Du ja bei korrekter Handhabung dann mehr Glück (und das brauchst Du in meinen Augen).
 
aber da ich in diesem Punkt nicht sicher bin und im Moment nicht zum Testen komme, würde ich an Deiner Stelle einfach den "Weg der geringsten Gefahr" gehen, zuerst mal linux_fs_start auf 0 setzen und dann - nach einem Neustart des Routers, der nicht schaden kann - die Partitionen 0, 1, 6 und 7 "frisch" beschreiben (und zwar nur diese) und die Box dann neu booten, OHNE an linux_fs_start zu drehen.
Danke, ich hab es genau so nochmal probiert mit flashen. (Also ohne nochmal linux_fs_start zu setzen)

Ergebnis: Bootloop leider noch da. :/


Code:
PS E:\Workspace\YourFritz\eva_tools> ftp 192.168.178.1
Verbindung mit 192.168.178.1 wurde hergestellt.
220 ADAM2 FTP Server ready
530 not logged in
Benutzer (192.168.178.1:(none)): adam2
331 Password required for adam2
Kennwort:

230 User adam2 successfully logged in
ftp> quote GETENV linux_fs_start
linux_fs_start        0

200 GETENV command successful
ftp> quit
221 Thank you for using the FTP service on ADAM2
PS E:\Workspace\YourFritz\eva_tools> echo "reboot FB"
reboot FB
PS E:\Workspace\YourFritz\eva_tools> .\EVA-Discover.ps1
EVA_IP=192.168.178.1
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\firmware-update_03_ATOM_ROOTFS.bin mtd0 }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\firmware-update_03_ATOM_ROOTFS.bin' to 'mtd0' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,176,130)

================
DEBUG: Sent
STOR mtd0
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\firmware-update_02_ATOM_KERNEL.bin mtd1 }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\firmware-update_02_ATOM_KERNEL.bin' to 'mtd1' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,160,154)

================
DEBUG: Sent
STOR mtd1
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\firmware-update_09_ARM_ROOTFS.bin mtd6 }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\firmware-update_09_ARM_ROOTFS.bin' to 'mtd6' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,127,37)

================
DEBUG: Sent
STOR mtd6
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
PS E:\Workspace\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { UploadFlashFile .\firmware-update_08_ARM_KERNEL.bin mtd7 }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3614 0x0 0xF6001

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Uploading file '.\firmware-update_08_ARM_KERNEL.bin' to 'mtd7' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,73,28)

================
DEBUG: Sent
STOR mtd7
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Upload completed, waiting 15 seconds for acknowledgement ...
DEBUG: Response:
226 Transfer complete

================
True
 
Tja - dann sieht es mit dieser Box mittlerweile offenbar schlecht aus. Irgendetwas muß dann deutlich mehr zerstört sein, als das am Beginn dieses Threads noch der Fall war. Bleibt wohl nur noch die Serielle (jeweils für den ARM- und ATOM-Teil), wobei die m.W. in EVA ohnehin stummgeschaltet ist und erst dann helfen würde, wenn die Kernel geladen sind - was hier vermutlich schon nicht mehr funktioniert (oder wie ist das aktuelle Timing?).
 
(oder wie ist das aktuelle Timing?).
Aktuell ist es wieder dieses Pattern:

direkt nach dem PowerOn:
  1. grüne LED dauerhaft an15s
  2. alle LEDs an ~1s
  3. alle LEDs aus ~5s
  4. grüne LED blinkend 1x ~1s
  5. grüne LED dauerhaft an 10s
  6. grüne LED blinkend im Sekundentakt ~3min
  7. repeat
Bleibt wohl nur noch die Serielle (jeweils für den ARM- und ATOM-Teil),

Ich hab jetzt mittels quote SETENV kernel_args mute=0 den Output zu den seriellen Schnittstellen aktiviert. (und auch nochmal gecheckt ob das einen Reboot überlebt.)

Danach die FB aufgeschraubt und jeweils für ATOM/ARM Header probiert (jeweils ohne löten mit schiefem PIN-Header und 1.8V / 3.3V gesetzt ):
  • GND, RX, TX
  • RX TX getauscht
  • nur GND, RX
  • verschiedene Baudraten, 9600, 115200, 38400
  • verschiedene Baudraten während PowerOn_reset
Ergebnis: nix. Kein Output. :/

Sidenote: Der Kühlkörper wird auch überhaupt nicht warm.
 
Da Du ja sicherlich noch "das Original" des von Dir "gepatchten" Loaders hast, würde ich mich zunächst mal vergewissern, daß dort noch die Kalibrierungsdaten enthalten sind und - sofern das der Fall sein sollte - DAMIT noch einmal von vorne beginnen; vielleicht hast Du ja bei korrekter Handhabung dann mehr Glück (und das brauchst Du in meinen Augen).

Der goldrichtige Hinweis, einen richtigen HEX-Editor, wie z.B. Okteta, zu verwenden brachte letzendlich das gewünschte Ergebnis. Der Nano-Editor hat am Dateiende einen Punkt (HEX=0D) angehängt und unter Umständen noch andere Bereiche vertrimmt rund um die zu ändernden Stellen. Von daher nochmals meinen aufrichtigen Dank für deine Mühe trotz knapper Resource (Zeit) mir zu helfen. Oftmals hängt ein Problem halt an einer Kleinigkeit, auf die man selbst im stillen Kämmerlein und aufwändiger Recherche nicht wirklich kommt. Eine zielgerichtete Frage in einem Forum sähe ich nicht unbedingt als unverschämt, rücksichtlos oder ausbeuterisch an, zumal durch deinen kurzen Hinweis dank deiner grossen Erfahrung das Problem zu meiner grossen Freude gelöst ist.

Im Übrigen meinte ich, daß du selbst NUR eine einzige Fundstelle (eher als Randbemerkung in einem editieren Beitrag) für die Abwandlung deines Skriptes gefunden hast
dann findet man ... genau eine einzige Fundstelle:
weshalb davon auszugehen ist, daß bis dato nicht viele einfache Anwender, die Variation kannten und einsetzten. Die meisten hier nutzen deine Tools und Skripte eher "as is". Software-Entwickler kommen mit Abänderungen und eigenen Variationen da sicherlich einfacher zurecht. Ob du dies nun als Variation in deinen Github aufnimmst oder nicht, bleibt einzig und allein dir überlassen. Sieh es doch einfach als freundlichen Verbesserungsvorschlag an.

Ohne mich profund mit GPL2 auszukennen, könnte man das ja in einen eigenen Fork einpflegen, was mir dann doch zu aufwändig ist für die Kleinigkeit.

Ich hab jetzt mittels quote SETENV kernel_args mute=0 den Output zu den seriellen Schnittstellen aktiviert. (und auch nochmal gecheckt ob das einen Reboot überlebt.)

Ich weiss nicht, womit du den adam2-ftp-server bedienst. Ich habe des öfteren festgestellt, daß z.B. das Umschalten auf die alternative FW-Partitionen mit SETENV nicht angenommen wird. Unter Umständen auch bei dir mit den kernel-args? Ansonsten kannst du dich mal bei @chips melden.
 
Zuletzt bearbeitet:
Ich weiss nicht, womit du den adam2-ftp-server bedienst. Ich habe des öfteren festgestellt, daß z.B. das Umschalten auf die alternative FW-Partitionen mit SETENV nicht angenommen wird. Unter Umständen auch bei dir mit den kernel-args? Ansonsten kannst du dich mal bei @chips melden.
Danke, ich nutze den FTP-client der Powershell. (win11, PS 5.1)
Der scheint da keine Probleme zu bereiten. Zumindest bekomme ich die Response 200 SETENV command successful
 
daß du selbst NUR eine einzige Fundstelle (eher als Randbemerkung in einem editieren Beitrag) für die Abwandlung deines Skriptes gefunden hast
Das stimmt so aber nicht - ich habe Dir nur ein Beispiel für eine solche Suche gegeben, die in diesem Kontext logisch war(!) und die dann am Ende eine überschaubare Menge an Ergebnissen brachte. Mit einer anderen Suchanfrage - die sich dann eben nicht auf die Kombination von RETR und config mit einem Leerzeichen dazwischen und zusätzlich den Begriff eva_tools beschränkt - findet man selbstverständlich auch vollkommen andere Stellen und zwar selbst hier mit der boardeigenen Suche. Die findet schon (nur in diesem Board) für eva_get_environment mehr als sechs Seiten mit jeweils 20 Links zu Beiträgen, in denen das vorkommt. Ich wette mal, da sind auch mehrere dabei, in denen das Skript mit der Angabe des Dateinamens aufgerufen wird.

Im übrigen habe ich auch nichts gegen "zielgerichtete Fragen" - jedoch gegen Wiederholungen, die unnötig sind bzw. wären, wenn der Fragesteller*in einfach mal selbst suchen würde. Nichts anderes wollte ich mit meinen "Suchvorschlägen" zeigen und wenn Du solche eigenen Anstrengungen für "nicht mehr zeitgemäß" hältst, dann haben wir beide da ein Problem miteinander.



Aktuell ist es wieder dieses Pattern:
Das hast Du wohl vergessen "zu erwähnen". Wenn die Box da drei Minuten läuft, bevor sie neu startet, dann ARBEITET das installierte System ja in diesen drei Minuten und dann müßte auch nach jedem Durchlauf der Wert in firmware_info wieder restauriert werden mit der Versionsnummer des laufenden Systems.

Ist das tatsächlich der Fall (überprüfen und ZEIGEN), kannst Du Dir erst einmal weiteres Flashen anderer Systeme klemmen - die FUNKTIONIEREN dann nämlich und offensichtlich (da in drei Minuten MEHRERE "sync points" passiert werden) auch auf beiden Architekturen.

Vielleicht versuchst Du ja dann doch einmal, den Vorschlägen IN DER RICHTIGEN REIHENFOLGE nachzukommen und die Box mit der Angabe recovered=2 (die Versionsnummer braucht es nicht) in firmware_info zu starten und dabei sowohl den Inhalt von firmware_info VORHER und NACHHER zu dokumentieren(!), als auch die Signalisierung WÄHREND dieses Vorgangs zu filmen, damit Du sie anschließend - auf Nachfrage oder gar eigenständig und unaufgefordert - auch wieder zum Besten geben kannst.
 
Das hast Du wohl vergessen "zu erwähnen". Wenn die Box da drei Minuten läuft, bevor sie neu startet, dann ARBEITET das installierte System ja in diesen drei Minuten und dann müßte auch nach jedem Durchlauf der Wert in firmware_info wieder restauriert werden mit der Versionsnummer des laufenden Systems.
Ja das stimmt.
Vielleicht versuchst Du ja dann doch einmal, den Vorschlägen IN DER RICHTIGEN REIHENFOLGE nachzukommen und die Box mit der Angabe recovered=2 (die Versionsnummer braucht es nicht) in firmware_info zu starten und dabei sowohl den Inhalt von firmware_info VORHER und NACHHER zu dokumentieren(!), als auch die Signalisierung WÄHREND dieses Vorgangs zu filmen, damit Du sie anschließend - auf Nachfrage oder gar eigenständig und unaufgefordert - auch wieder zum Besten geben kannst.
Ich hab es jetzt nochmal probiert genau nach Deiner Anleitung: (und ich war auf Partition 1 unterwegs, die hatte ich nochmal im Zuge des Test mit der seriellen Schnittstelle probiert)
  • firmware_info 161.07.57
  • quote SETENV firmware_info recovered=2
  • reboot
es bootet wieder :eek: vielen Dank @PeterPawn :)


Ein paar Fragen bleiben aber noch:

Laut freetz-ng Webinterface ist FritzOS unknown für Partition 0 obwohl da eigentlich was sinnvolles drauf sein sollte. Hat es evtl. die zerhauen und ich hab immer mit der Partition 0 probiert? Evtl. probiere ich nochmal einen Flash auf die Partition 0 ... irgendwie traue ich dem Frieden nicht.

1714900948527.png

Aber bevor ich das tue noch eine andere Frage. Jetzt wo ich wieder per SSH drauf komme. Wie kann ich die FB *komplett* sichern um nach Möglichkeit einen weiteren Disaster vorzubeugen?
 
Weniger fragen, mehr suchen und lesen - was genau bleibt denn nach der Lektüre der readme-6591.md von @fesc noch unklar?

Da findet man dann auch die Infos zur korrekten Benutzung der seriellen Schnittstellen (mir ist ohnehin unklar, was @chips da helfen sollte - vermutlich nur das Löten zeigen, anstatt da mit "fliegender Verdrahtung" zu arbeiten?) und dann muß man wahrscheinlich nur sauber (und mit sicherer Kontaktierung der RICHTIGEN Anschlüsse) arbeiten, damit auch das noch funktioniert - wildes Probieren verschlimmert die Lage in aller Regel nur noch mehr.

Wobei die größte Hürde für die meisten sicherlich ein passender USB-Adapter wäre, da die "üblichen Verdächtigen" i.d.R. beim Pegel nur mit der Wahl zwischen 3,3V und 5V erhältlich sind, obwohl die verwendeten Chips auch mit 1,8V klar kämen. Aus Deutschland sind entsprechende Adapter auch schwer zu beziehen, da muß man häufig direkt in China kaufen.
 
Weniger fragen, mehr suchen und lesen - was genau bleibt denn nach der Lektüre der readme-6591.md von @fesc noch unklar?
Genügt es denn alle Partitionen der eMMC zu sichern?

vermutlich nur das Löten zeigen, anstatt da mit "fliegender Verdrahtung" zu arbeiten?) und dann muß man wahrscheinlich nur sauber (und mit sicherer Kontaktierung der RICHTIGEN Anschlüsse) arbeiten, damit auch das noch funktioniert
Da ich jetzt drauf komme, verzichte ich erstmal auf das Löten. Intressant wäre natürlich trotzdem die Antwort auf die Frage, warum ist es initial passiert?
Wobei die größte Hürde für die meisten sicherlich ein passender USB-Adapter wäre, da die "üblichen Verdächtigen" i.d.R. beim Pegel nur mit der Wahl zwischen 3,3V und 5V erhältlich sind, obwohl die verwendeten Chips auch mit 1,8V klar kämen. Aus Deutschland sind entsprechende Adapter auch schwer zu beziehen, da muß man häufig direkt in China kaufen.

Ich hab den hier:
USB>TTL
 
Genügt es denn alle Partitionen der eMMC zu sichern?
Wieso? Hat die Box denn keinen anderen Flash mehr?
Ich hab den hier:
Der würde ja passen - wenn jetzt die Kontakte auch noch sicher sind UND jeweils der korrekte Pegel verwendet wird, dann sollte auch innerhalb des von Dir als Punkt 5 beschriebenen Zeitraums etwas auf der Schnittstelle zu sehen sein - die Geschwindigkeit (und Bit-Anzahl + Parität) steht ja bei @fesc.
 
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.