Fritzbox 6490 Cable Firmware Update?

[noob_noob]

Ich würde jetzt nach dem nicht erfolgreichen Upload des Firmware-Images (bzw. der "Pseudo-Firmware") erst einmal hingehen und (ohne Neustart, daher muß man sich etwas ranhalten, denn der kommt sicherlich dann unweigerlich von alleine innerhalb von max. drei Minuten nach dem fehlgeschlagenen Upload) noch einmal die Support-Daten direkt ausgeben lassen.

Dort sollte man dann den Inhalt der Verzeichnisse "/var" und "/var/tmp" sehen können und zumindest anhand der Existenz oder des Fehlens einer passenden Datei (es werden auch noch Protokoll-Dateien geschrieben, aber an deren Inhalt kommt man erst einmal nicht heran) darauf schließen können, was da nun am Image-File faul sein könnte und wo in etwa dieser ominöse Fehler 0 nun auftreten mag.

Wo kommt das Image gleich noch mal genau her?

neu starten tut sie nicht, nach den fehlschlägen.
inhalt meines telnet images steht in http://www.ip-phone-forum.de/showthread.php?t=286994&page=32&p=2179454&viewfull=1#post2179454 und dort ist auch die herkunft zu lesen.

/var/tmp:
drwxrwxrwx    5 root     root          1820 Jan  1 01:04 .
drwxr-x---   20 root     root          1200 Jan  1 01:04 ..
-rw-r--r--    1 root     root             0 Jan  1 01:00 Sync_Point_LAN_up
-rw-r--r--    1 root     root             0 Jan  1 01:01 Sync_Point_NFS_Server_running
-rw-r--r--    1 root     root             0 Jan  1 01:01 Sync_Point_NFS_filesystems_mounted
-rw-r--r--    1 root     root             9 Jan  1 01:00 app_cpu_state.txt
-rwSr-x--T    1 root     root             4 Jan  1 01:00 app_run
-rw-r--r--    1 root     root            21 Jan  1 01:00 avm-resolv.conf
-rw-r--r--    1 root     root             6 Jan  1 01:00 chrony.keys
srwxr-xr-x    1 root     root             0 Jan  1 01:00 cm_evmgr_ctrl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 cm_snmp_ctrl
lrwxrwxrwx    1 root     root            41 Jan  1 01:01 crossdomain.xml -> /etc/default/avm/crossdomain-template.xml
drwxr-xr-x    2 root     root           620 Jan  1 01:01 csem
-rw-r--r--    1 root     root          1698 Jan  1 01:04 ctlmgr0.slab
-rw-r--r--    1 root     root             0 Jan  1 01:03 ddnsdomains.txt
srwxr-xr-x    1 root     root             0 Jan  1 01:00 dispatcher_ctrl
-rw-r--r--    1 root     root             3 Jan  1 01:00 dmg_params
-rw-r--r--    1 root     root             0 Jan  1 01:00 dnsd_servers
-rw-r--r--    1 root     root           690 Jan  1 01:00 dnsddebug.txt
-rw-r--r--    1 root     root           123 Jan  1 01:01 dnsddyns.cfg
-rw-r--r--    1 root     root       1235797 Jan  1 01:04 docsis_boot.log
-rw-r--r--    1 root     root             0 Jan  1 01:00 docsis_boot_mng.pcap
-rw-r--r--    1 root     root          1443 Jan  1 01:04 dsld0.slab
-rw-r--r--    1 root     root            31 Jan  1 01:00 edocsis.state
srwxr-xr-x    1 root     root             0 Jan  1 01:00 foncontrol
-rwxrwxrwx    1 root     root             0 Apr 20  2015 gateways
-rwxrwxrwx    1 root     root            27 Jan  1 01:00 group
srwxr-xr-x    1 root     root             0 Jan  1 01:01 homeauto
-rwxrwxrwx    1 root     root            20 Apr 20  2015 hosts
-rwxrwxrwx    1 root     root            32 Apr 20  2015 hosts.allow
-rwxrwxrwx    1 root     root             9 Apr 20  2015 hosts.deny
-rw-r--r--    1 root     root             0 Jan  1 01:00 icc_handle
-rwxrwxrwx    1 root     root           142 Apr 20  2015 idmapd.conf
-rw-r--r--    1 root     root          3136 Jan  1 01:02 igddesc.xml
-rw-r--r--    1 root     root           165 Jan  1 01:02 inetd.conf
-rw-r--r--    1 root     root            14 Jan  1 01:00 l2tpstat
-rwxrwxrwx    1 root     root           418 Jan  1 01:01 load_userman_mod.sh
-rw-r--r--    1 root     root             0 Jan  1 01:00 lsdctrl.do.not.delete
-rw-r--r--    1 root     root            30 Jan  1 01:00 lsdctrl.log
-rw-r--r--    1 root     root          2643 Jan  1 01:00 lsddb_rt.ini
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me_TR064.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me__anony922-3547230171.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me_avm_home_external.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_avmipc_state.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me_ctlmgr.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:03 me_ddnsd.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_dsld.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me_dvb.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_igd.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_l2tpv3d.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me_libgsm.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me_logic.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_multid.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_remote.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_tcpproxyd.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me_tr064srv.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_upnpd.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 me_usermand.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 me_voipd.ctl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 mta_evmgr_ctrl
srwxr-xr-x    1 root     root             0 Jan  1 01:01 mta_snmp_ctrl
-rw-r--r--    1 root     root          1570 Jan  1 01:04 multid0.slab
-rw-r-----    1 root     root             0 Apr 20  2015 nohup.out
srwxr-xr-x    1 root     root             0 Jan  1 01:01 pacm_sec_sock
-rw-r--r--    1 root     root           411 Jan  1 01:02 passwd
srwxr-xr-x    1 root     root             0 Jan  1 01:00 pb_event
srwxr-xr-x    1 root     root             0 Jan  1 01:00 pbctrl
srwxr-xr-x    1 root     root             0 Jan  1 01:00 pbmsg
-rw-r--r--    1 root     root            22 Jan  1 01:03 pcpserver
srwxr-xr-x    1 root     root             0 Jan  1 01:01 plc_sock_if
srwxr-xr-x    1 root     root             0 Jan  1 01:00 ptestd_pipe
-rw-r--r--    1 root     root            21 Jan  1 01:00 resolv.conf
drwxrwxrwx    5 root     root           100 Mar  3  2015 samba
-rwxrwxrwx    1 root     root            25 Apr 20  2015 shadow
-rw-r--r--    1 root     root          7582 Jan  1 01:00 shmdb.log
-rw-r--r--    1 root     root          2048 Jan  1 01:01 sm_trace
srwxr-xr-x    1 root     root             0 Jan  1 01:00 tamlua
srwxr-xr-x    1 root     root             0 Jan  1 01:00 tel_ipc
-rw-r--r--    1 root     root         10770 Jan  1 01:02 tr64desc.xml
-rw-r--r--    1 root     root             0 Jan  1 01:03 update_error.log
-rw-r--r--    1 root     root             0 Jan  1 01:03 update_out.log
-rw-r--r--    1 root     root          1630 Jan  1 01:04 upnpd0.slab
drwxr-x---    2 root     root            40 Apr 20  2015 upnpwebsrv
-rw-r--r--    1 root     root          1447 Jan  1 01:04 usermand0.slab
-rw-r--r--    1 root     root           105 Jan  1 01:02 users.acl
-rw-r--r--    1 root     root            63 Jan  1 01:02 users.map
-rw-r--r--    1 root     root          1627 Jan  1 01:04 voipd0.slab
-rw-r--r--    1 root     root          1277 Jan  1 01:01 websrv_ssl_cert.pem
-rw-r--r--    1 root     root         74288 Jan  1 01:01 wlan_dynamic.cfg
-rw-r--r--    1 root     root          4315 Jan  1 01:01 wlan_roles
-rw-r--r--    1 root     root           559 Jan  1 01:01 wland_support.log

inhalt /var/tmp nach einem versuch mit dem script...
/var finde ich im supportlog nicht

 

[erst_nachdenken]

Den Inhalt des "install"-Skripts hatte ich schon gesehen und außer etwas hier schon Gelesenes zu bekräftigen (der ganze Restart-Kram ist bei der 6490 etwas anders zu regeln - aber das interessiert erst später), ist daran wenig auszusetzen.

Aber das trifft den Kern der Sache eben nicht ... dieses Skript ist ja nun in ein Tarball (also ein mittels "tar"-Kommando (und das muß schon das simple "ustar"-Format verwenden) erzeugtes Archiv) einzubetten. Da dort eben auch die verwendeten Pfade eine Rolle spielen können, würde ich gerne selbst mal sehen, wie das originale Image-File nun aussieht und den "versprochenen Link" kann ich in dem Beitrag nicht entdecken.

 

[noob_noob]

http://www.antary.de/wp-content/uploads/2015/07/telnet-1.tar

 

[erst_nachdenken]

Macht zwar wenig Sinn, wenn das Skript gleich noch den LCR versucht zu laden ... aber sei's drum.

Was auffällt, ist die fehlende Signatur-Datei. Nun funktioniert das zwar bei anderen Versionen auch irgendwie, aber auch wenn wir von Deiner jetzt die Revision wissen (30308 war das weiter vorne), kann das trotzdem einen Unterschied machen.

Ich habe einfach mal das Archiv von antary.de geladen (Du weißt schon, daß "das Original" hier im IPPF zu finden ist?) und es nach dem Umpacken noch um eine Signatur-Datei ergänzt.

Wird vermutlich auch nichts bringen ... wobei schon die Frage, warum bei Dir kein Neustart ausgeführt wird, recht interessant ist.

Normalerweise würde der Upload und die Verarbeitung über "firmwarecfg" einen Watchdog-Timer starten, der auch dann einen Neustart auslöst, wenn man das Fenster mit dem Update-Fehler einfach stehen läßt und ignoriert. Wenn schon dieser Watchdog nicht gestartet wird, könnte tatsächlich ein Format-Fehler der hochgeladenen Datei die Ursache sein ... der würde dann auch noch vor der Feststellung "unsigniertes Image" (bzw. anstelle dieser) erscheinen.

Aber die Support-Daten sollten dann trotzdem in /var/tmp ein paar Dateien enthalten, deren Existenz Auskunft über den Fortschritt beim Update gibt:

/var/tmp/fw_ip
/var/tmp/fwupdate.log
/var/tmp/firmware_error_status
/var/tmp/firmware_update_started
/var/tmp/install_out.log
/var/tmp/install_error.log
/var/tmp/firmware_stream_result
/var/tmp/fwsign.log

Die Frage nach den Einstellungen in der ar7.cfg hast Du auch noch nicht beantwortet ... es wäre durchaus denkbar, daß da von wilhelm.tel weitere Einstellungen vorgenommen wurden (also die Update-Menüs noch einmal "versteckt" wurden, obwohl die bei der 6490 ja bereits ausfallen wegen "is nich".

Wenn diese Einstellung tatsächlich noch einmal abgefragt wird beim Upload bzw. bei der Prüfung in "firmwarecfg" (bei den DSL-Modellen wird halt das "Verstecken" wieder aufgehoben und dann funktioniert das Update dort - keiner macht das über HTML-Manipulationen bei versteckter Update-Funktion), dann wäre das auch noch eine Möglichkeit, wo das Problem liegen könnte ... denn diese "provider additive"-Konfiguration ist bisher hier etwas ziemlich Einmaliges. Das ist aber durch einfachen Export festzustellen und ggf. durch Import einer geänderten Datei zu beheben, ob/wenn da Seiten im Web-Interface "versteckt" wurden.

PS: Da das Forum keine "image"-Dateien mag, ist das noch einmal mit "gzip" gepackt ... nur vorsichtshalber, sieht man ja eigentlich deutlich.

 

[noob_noob]

leider führt dein image zum identischen ergebnis.
magst du mir vlt die gesuchten parameter dazu in der ar7.cfg geben? dann kann ich dort mal nachsehen.

 

[erst_nachdenken]

"ar7.cfg" war eigentlich/vermutlich falsch ... es findet sich trotzdem in der Export-Datei.

Da ich selbst an dem Inhalt der "provider_additive.tar" schwer interessiert bin, "löse" ich mal ... bei den DSL-Boxen wird das Update über eine Einstellung "UpgradesManaged = yes" in der tr069.cfg beeinflußt. Ist der Wert "yes", werden die Seiten im GUI ausgeblendet, weil eben Firmware-Updates vom Anbieter per TR-069 übernommen werden sollen.

Es ist aber nicht sicher, ob das bei wilhelm.tel auch wirklich gesetzt ist - ist es der Fall, könnte das zuständige Programm beim Upload (firmwarecfg) auch diese Einstellung noch abfragen und das etwas unerwartete Problem des "Fehler 0" könnte damit zusammenhängen.

Merkwürdigerweise verhält sich die Firmware bei Dir ja genau so, wie man es erwarten würde, wenn AVM das Firmware-Update über den Datei-Upload generell gesperrt hätte - es gab hier ja schon Verwunderung, daß so ein "Pseudo-Update" mit der 6490 überhaupt funktioniert bei einer 06.2x-Version.

Einen Versuch wäre es wohl auch noch wert, der Firmware einfach tatsächlich mal ein AVM-Update vorzusetzen. Nimmt man dafür die 06.62 vom AVM-Server (das ist immer noch dieselbe seit ihrer Veröffentlichung), kann man die Reaktion auf eine sicher korrekt aufgebaute und signierte Datei beobachten. Weigert sich die Firmware auch, diese Datei zu akzeptieren, ist etwas generell "abgeschaltet" in der Firmware und es ginge darum, diesen "Schalter" zu finden.

Wenn das Update funktionieren sollte, verlierst Du auch nichts ... Deine Box hat ja bisher offensichtlich kein alternatives System, was dabei überschrieben werden könnte. Bleibt das Update irgendwann (ich sag mal 10 Minuten Warten sind die sichere Variante) hängen (dann kommt aber nicht sofort dieser "Fehler 0"), funktioniert vermutlich der Download neuer Zertifikate am Ende des Updates (erwartbar) nicht. Dann einfach die Box (gib ihr die erwähnte Zeit) manuell neu starten und nachsehen, ob in der alternativen Partition (linux_fs_start 1) nun ein System installiert ist.

Klappt das mit dem Update, hast Du von diesem anderen System aus die Möglichkeit, den Dump des TFFS im Rahmen der erweiterten Support-Daten auszulesen ... das Zurückschalten auf "linux_fs_start 0" bleibt Dir ja immer noch - auch wenn das Update funktioniert - und somit ändert sich praktisch nichts zum Schlechteren.

Zumindest weiß man dann, ob das dateibasierte Update bei Deiner OS-Version überhaupt möglich ist ... gerade dann, wenn das wirklich nicht geht, wird diese Box immer spannender, denn dann bliebe die Frage, woran das liegen mag und was diese Box nun von den Modellen bei den beiden großen Providern unterscheidet, daß sich die Firmware-Version 06.24 so anders verhält.

In dem "nachgereichten" Inhalt des Verzeichnisses /var/tmp ist jedenfalls nichts zu erkennen, was auch nur im entferntesten auf ein gestartetes Datei-Update hindeutet. Die beiden Dateien "update_*.log" sind zwar nicht vollkommen zu erklären, die beim dateibasierten Update entstehenden heißen aber "install_*.log". Das stützt die Theorie, daß die Firmware das gar nicht als Update in Erwägung zieht und da stellt sich die Frage, warum das so ist.

Man könnte auch noch etwas tricksen und den Upload der Datei an einer Stelle so weit verzögern (so ein TCP-Timeout braucht auch seine Zeit), daß man während der Upload noch läuft, mal die Prozessliste aus den Support-Daten ausliest und sich dort ansieht, was die Firmware nun mit dem Update eigentlich genau macht (das dann besser auch mit einer größeren Update-Datei, sonst wird das Stoppen des Uploads schwierig, denn Stoppen heißt nicht Abbrechen).

Da das alles über Pipes "hintereinander geschaltet" ist, spart man sich die Zwischenspeicherung so einer Datei im ersten Schritt - aber das heißt eigentlich auch, daß man die komplette Kommandokette in der "ps"-Ausgabe sehen kann. Die Erkenntnis, wo man bei KMS das CVC-Image finden konnte, hatte @fesc ja auch aus so einer Prozessliste.

PS: Bei Deinem Inhalt von /var/tmp würde ich fast bezweifeln wollen, daß die Box überhaupt die LEDs auf "Update-Modus" schaltet. Wie sehen die denn aus, wenn der Upload erledigt ist bzw. wie ändern die sich im Verlauf so eines Versuches?

 

[noob_noob]

moin,

das mit der 6.62 hab ich schon versucht, failt auch...

@info-led: richtig. die schweigt. komplett...
@tr069.cfg

tr069cfg {
        enabled = yes;
        litemode = no;
        tr181_support = no;
        dhcp43_support = yes;
        igd {
                DeviceInfo {
                        ProvisioningCode = "CM-Unreg";
                        FirstUseDate = "1970-01-01 01:00:00";
                }
                managementserver {
                        url = "https://acs.wtnet.de:7547";
                        username = "SECRET";
                        password = "SECRET";
                        URLAlreadyContacted = no;
                        LastInformReq = "1970-01-01 01:00:00";
                        LastSuccessfulContact = "1970-01-01 01:00:00";
                        URLbyDHCPIface = "";
                        PeriodicInformEnable = no;
                        PeriodicInformInterval = 0;
                        PeriodicInformTime = "1970-01-01 01:00:00";
                        UpgradesManaged = yes;
                        ACSInitiationEnable = yes;
                        SessionTerminationWithEmptyPost = no;
                        ConnectionRequestUsername = "";
                        ConnectionRequestPassword = "";
                        dnsprefer = tr069dnsprefer_ipv4;
                }
        }
        FirmwareDownload {
                enabled = yes;
                enabled_converted = yes;
                upload_enabled = no;
                valid = no;
                suppress_notify = no;
                status = 0;
                StartTime = "1970-01-01 01:00:00";
                CompleteTime = "1970-01-01 01:00:00";
                method = Download_Method_DL;
        }
        RebootRequest = no;
        RebootRequest_CommandKey = "";
        ACS_SSL {
                verify_server = no;
        }
        Download_SSL {
                verify_server = no;
        }
        guimode = guimode_hidden;
        PDCVersion = "20150806";
}

ist es hier nur das upload_enabled = yes/no ???
hier würden mich die möglichen RICHTIGEN settings für ein mögliches fw-update interessieren. kann wer mal den part aus seinem export file posten, bei dem das flashen des telnet.images funktioniert?

zum thema upload verzögern, wie mache ich das im pimp script? sorry, shell script ist nicht meines...

 

[erst_nachdenken]

das mit der 6.62 hab ich schon versucht, failt auch...

Dann wird das Pseudo-Update ja erst recht nicht funktionieren und das ist hier alles mehr oder weniger "Beschäftigungstherapie". Es wäre nett, wenn Du so etwas dann mal unaufgefordert (und so, daß man es auch verstehen kann) mitteilen könntest ... das hätte ja nun einige Überlegungen gleich von Beginn an überflüssig gemacht. Das ist ja nun nicht nur pure Neugierde, wenn Dich hier jemand nach Einzelheiten fragt und eine Antwort in vollständigen Sätzen führt dann ja auch irgendwie dazu, daß man vorankommt, wie die letzten Beiträge meines Erachtens zeigten. Das klappt aber nur, wenn Du auch "mitarbeitest" ... ansonsten ist das reine Zeitverschwendung.

Dazu gehört dann leider auch, daß Du solche Sachen wie

seite heute morgen hat avm wohl den dl link für die 6.62 weggenommen. vor dem we war die fw dort noch downloadbar unter https://avm.de/service/downloads/?product=FRITZ%21Box+6490+Cable

entweder belegst (solange ich mich zurückerinnern kann, stand dort immer nur der Link zu einer Erklärung, wie man das Update über das GUI startet) oder unterläßt ... es bringt die anderen Leser nur vollkommen unnötig durcheinander.

Man kann die URL des Updates immer noch ermitteln (wie, steht in #411) und da kommt auch immer noch eine Adresse:

# jason_boxfirmwareupdatecheck C80E14CAFEEE avm de Kabel 049 141.06.60 33980 213 'FRITZ!Box 6490 Cable' | sed -n -e "\$p" | xmllint --format -
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
  <soap:Body ID="Body">
    <BoxFirmwareUpdateCheckResponse xmlns="http://jason.avm.de/updatecheck/">
      <BoxFirmwareUpdateCheckResult>
        <ResponseHeader>
          <Nonce>LrrvwoMHjxl7EjSk2W+g6Q==</Nonce>
        </ResponseHeader>
        <UpdateCheckResult>
          <CheckIntervall>8</CheckIntervall>
          <Found>true</Found>
          <Version>141.06.62</Version>
          <DownloadURL>[COLOR="#008000"]http://download.avm.de/firmware/6490/35727360/FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.06.62.image[/COLOR]</DownloadURL>
          <InfoURL>ftp://ftp.avm.de/fritz.box/fritzbox_6490_cable/firmware/deutsch/info.txt</InfoURL>
          <InfoText/>
          <HintURL/>
          <Priority>1</Priority>
          <AutoUpdateStartTime>7200</AutoUpdateStartTime>
          <AutoUpdateEndTime>18000</AutoUpdateEndTime>
          <AutoUpdateKeepServices>true</AutoUpdateKeepServices>
        </UpdateCheckResult>
      </BoxFirmwareUpdateCheckResult>
    </BoxFirmwareUpdateCheckResponse>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <Reference URI="#Body">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
          <DigestValue>4yey08TWzKvqb+ObzGufExhqDKY=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>cNFDx+AXz663xaerQvE6/i1HhX1OfEfpSQjgAYgs0KDihU1X158eA9zfokiiJIwbcfLQlrLGY4k0dWreBF5i6nD8VYrlJsiUbjTno274ZaEnYN/f4M7LTIofzy3/+GfRICJI5ny2zDqfuFYWA2M+LfLzUCYJwJ5HumYJebxq7G4=</SignatureValue>
    </Signature>
  </soap:Body>
</soap:Envelope>

Genau das habe ich auch vorher überprüft, bevor ich etwas dazu schrieb, daß sich die Version seit ihrer Veröffentlichung nicht geändert hätte.

Etwas mehr Sorgfalt und das Überprüfen solcher falschen Feststellungen auf mögliche eigene Fehler wäre echt nett ... es bringt andere Leser nur vollkommen unnötig auf die Idee, das Geschriebene könnte irgendwie stimmen.

Zur der Geschichte mit TR-069 ... ich weiß ja nicht, warum Du #673 nicht lesen willst. Die entscheidende Einstellung steht bereits im zweiten Satz und wie man in Deiner tr069.cfg ja sehen kann, stimmte auch meine Vermutung, daß diese Einstellung bei Deiner Box tatsächlich gesetzt sein könnte. War das nun nicht deutlich genug? Was hättest Du denn ansonsten noch gerne als Erklärung? Vielleicht hilft ja auch die Suche nach diesem "UpgradesManaged" und das Lesen anderer Threads, die sich mit dieser Einstellung befassen?

Der Beschreibung zum Ändern der Einstellungen über eine geänderte Import-Datei traue ich ebenfalls nicht ... entweder die Beschreibung stimmt schlicht nicht (weil sie mal wieder den zwischenzeitlichen Neustart einfach ausläßt, der nach einem erfolgreichen Import der Einstellungen automatisch erfolgt) oder der Import hat gar nicht funktioniert.

Das kann auch wieder an sinnlosen/syntaktisch falschen Änderungen am Inhalt liegen und ganz ehrlich, wenn Du hier Hilfe erwartest, solltest Du erstens mehr eigene Initiative entwickeln ("UpgradesManaged" suchen), zweitens gründlicher lesen ("UpgradesManaged" als Stichwort weiter vorne finden und auch die Threads lesen, wo diese Einstellung diskutiert wurde) und drittens selbst weitaus detaillierter beschreiben, was Du eigentlich machst. Mit "ich hab schon versucht darin was zu ändern" kann keiner hier etwas anfangen ... das könnte auch das Datum des Downloads sein.

Bei allem Interesse am Inhalt der provider_additive.tar ... wenn das hier in "an die Hand nehmen" ausartet, verliere ich die Lust. Wenn ich am Ende davon ausgehen muß, daß Tests nur "schlampig" gemacht werden (so, wie eben auch falsche Feststellungen zu nicht mehr vorhandenen Updates auftauchen), werden falsche Ergebnisse wahrscheinlicher und dann sind die ganzen Tests ziemlich wertlos ... am Ende nicht nur Zeitverschwendung für Dich, sondern auch für jeden anderen, der seinerseits versucht, sich in Dein Problem hineinzudenken.

Das mußte ich mal loswerden, zurück zum Problem ... nun stünde eben die Änderung von "UpgradesManaged" an und wenn so eine Änderung mit den verwendeten Werkzeugen nicht funktionieren will, testet man entweder eine andere Einstellung (z.B. den Boxnamen) oder andere Werkzeuge. Auch hier kann wieder niemand realistisch einschätzen, ob das Problem bei Dir am Werkzeug oder am Inhalt der Änderungen liegt.

 

[fesc]

Hallo,

sorry für die Unterbrechung, soll keine Eigenwerbung sein, aber ich habe während meines Urlaubs ziemlich viele Anfragen bekommen ...
Ich habe hier ein kleines git repository mit meinem "mod" angelegt: https://bitbucket.org/fesc2000/ffritz
Das nimmt ein original 6.50 oder 6.62 image (beides getestet) und macht folgende Aenderungen:
- telnet an (arm und atom)
- ssh support fuer ARM (dropbear, README beachten)
- IPv6 native Auswahl immer an (noch rudimentär, nach einem neustart der box muss IPv6 immer erst wieder aktiviert werden. Aber es funktioniert (bis auf ICMPv6, warum auch immer).
Das image ins Verzeichnis über dem repo legen und make release sollte reichen (evtl. ORIG im Makefile ändern).

 

[noob_noob]

danke für deine geduld.
sie wird bald belohnt, durch das provider_additive.tar. telnet läuft.
das mit dem upgrades managed = yes / no war es. telnet läuft.
ich werd nu mal versuchen, die datei zu sichern. gibt es sonst noch was, was von dieser box interessiert?
@pokemon20021: das script funktioniert mit der 6.24 bestens....

 

[erst_nachdenken]

telnet an (arm und atom)

Wenn lediglich der Symlink bei der AVM-BusyBox in /usr/sbin angelegt wird, erfolgt der Start des Telnet-Daemons weiterhin über den "telefon"-Daemon der originalen Firmware. Damit kann man dann mit den bekannten Telefon-Codes den Telnet-Service aus- und einschalten. Auch das hat zweifellos seine Vorteile ... so ein Telnet-Zugang (der ständig offen steht) ist auch eine Sicherheitslücke. Hier sollte man sorgfältig abwägen, ein Start über den direkten Aufruf bewirkt eben immer die Verfügbarkeit.

---

-

- ssh support fuer ARM (dropbear, README beachten)

Anstelle des Benutzers "root" über /bin/login kann man auch gleich die Benutzerverwaltung der FRITZ!Box verwenden ... administrative Benutzer sind nach dem Login automatisch "root" (0/0), wenn man für das Login das Programm /sbin/ar7login verwendet (muß allerdings schon bei der Übersetzung erfolgen, der "dropbear" kennt normalerweise keinen Parameter für die dynamische Konfiguration eines Login-Programms). Dann kann man die ganz normalen Konten benutzen, braucht sich um die persistente Speicherung einer /etc/passwd nicht kümmern (egal wohin man die verlinkt) und riskiert keine Probleme durch die eigene Speicherung.

In den Kontext reiht sich auch das Verwenden eines dynamisch generierten RSA-Schlüssels für SSH ein. Es gibt einen Patch für "dropbear", der dafür sorgt, daß das ohnehin im FRITZ!OS vorhandene Zertifikat (und der dazugehörige private Schlüssel) für das GUI (also für den Zugriff über HTTPS) auch als Host-Key vom "dropbear" in der FRITZ!Box benutzt werden kann und wieder muß man sich um eine Speicherung keine Gedanken machen (für den privaten Teil sogar verschlüsselt) und man hat - im Gegensatz zu dynamisch generierten Keys, die auch noch volatil sind - wieder die Gewißheit, bei welchem Gerät man sich tatsächlich anmeldet (sofern man Benutzernamen und Kennwörter dann überhaupt verwendet, da wäre ja ein "pubkey auth" dann ohnehin schlauer).

Wenn man den Patch noch etwas anpaßt, kann man auch das CM-Zertifikat für den SSH-Server verwenden (würde ich trotzdem nicht machen) ... das macht eine wechselnde oder unklare Identität der FRITZ!Box dann noch unnötiger.

---

-Auch wenn ich registriert habe, daß Du den Host-Key in /var/media/ftp ablegst ... das ist ein Verzeichnis, wo normalerweise der NAS-Service zugreifen kann und da legt man - meiner Überzeugung nach - keine RSA-Keys ab. Zwar verhindern die Rechte (700) bei Dir vordergründig erst einmal den Zugriff, aber so eine FRITZ!Box hat keine echte Benutzerverwaltung und am Ende sind schon mal alle Accounts in der Gruppe "root" und es ist auch nicht allzu kompliziert, sich für andere Konten die UID 0 zu verschaffen.

Es ist wesentlich schwieriger, beim NAS-Zugriff aus dem "jail" unter /var/media/ftp auszubrechen ... das minimiert dann die Folgen wieder. Ich würde trotzdem (wenn es andere Wege gibt) keine privaten Schlüssel dort ablegen.

Schon das Speichern eines öffentlichen Schlüssels für die automatische SSH-Anmeldung ist an dieser Stelle grenzwertig, wobei auch wieder das Verhindern des Schreibzugriffs (für das unberechtigte Hinzufügen weiterer öffentlicher Schlüssel für das Login) recht gut und durchgehend gelöst ist (das Auslesen ist da ja kein wirkliches Problem).

---

-Beim Einpacken eines Images für eine FRITZ!Box sollte man immer auf das "tar"-Applet der BusyBox setzen (jetzt bin ich bei Deinen "telnet-1.tar") ... die ansonsten vorhandenen PaxHeader-Einträge können (nicht mit müssen/werden zu verwechseln) an dieser Stelle "firmwarecfg" bei der Prüfung der Image-Datei verwirren.

---

-Was wird eigentlich durch die geänderte atom/mod/etc/init.d/rc.tail.sh in der vorletzten (nicht leeren) Zeile genau gestartet? Soll der Telnet-Daemon auf dem x86-Core jetzt über diese Datei oder über /usr/sbin/start_atom_telnetd auf dem ARM-Core gestartet werden? Beide gleichzeitig werden nicht funktionieren.

---

-Die "debug.cfg" würde ich nicht durch ein "." wieder zum Leben erwecken ... die Gefahr, daß dort falsche Kommandos den Init-Prozess vorzeitig beenden, ist immer gegeben. Ich dachte, das so gesehen zu haben, finde es aber nicht mehr ... also nur als "Prophylaxe".

---

-Beim Start des Telnet-Daemons auf dem ARM-Core über ein Pseudo-Update muß man bei der 6490 gar nicht so kompliziert vorgehen (mit copy und bind-mount), dort gibt es ein Binary namens "utelnetd", welches man einfach mit den richtigen Parametern als Telnet-Daemon aufrufen kann. Das macht das Image dann sogar "reusable" ... im Moment ist es mehr oder weniger Glückssache, was bei einem mehrfachen Aufruf passiert mit der Kopiererei und dem "mount".

---

-Nur so ein paar Gedanken, die mir bei der Durchsicht kamen ...

 

[noob_noob]

danke an alle leidgeplagten, die mir hier geholfen haben. thema ist für mich vom tisch. box bootet über linux_fs_start 0 6.24 ohne! provider-additive und mit linux_fs_start 1 die 6.62. dank http://www.ip-phone-forum.de/showthread.php?t=283851&p=2147376&viewfull=1#post2147376 das 2 mal aufgerufen werden muss

 scriptname

für den arm part

rpc scripname

für den x86 part
hab ich nun auf die 6.24 mit allen partitionen sowie die provideradditve.tar gesichert.

 

[fesc]

Hallo,

vielen Dank fuer dein "review".

Das mit telnet sehe ich nicht so kritisch, solange der port nur offen ist und nicht genutzt wird. Aber ich wollte telnet eigentlich komplett eliminieren und durch dropbear ersetzen. Ich werde es wohl erst mal so machen dass telnetd nach 5 minuten gekillt wird.
Die Telefoncodes funktionieren bei mir (6.62) nicht, oder ich mache was falsch (ich habe telnetd gekillt und versucht ueber codes in meinem telefonbuch zu starten).

Dropbear aendere ich erst mal dahingehend dass die keys in /nvram/dropbear liegen. Die sind ja nicht gross, in /nvram ist noch genug Platz und sie werden ja nur einmal geschrieben. Das ftp Verzeichnis ist in der Tat keine so gute Idee gewesen. Bzw. werde ich bei Gelegenheit mal den patch suchen und testen.

Mit ar7login kenne ich mich nicht gut aus, ich habe den Eindruck dass das NUR den web-login kennt, aber keine sonstigen Benutzer. Es fragt ja nicht mal nach einem Benutzer, also frage ich mich wie sshd damit umgehen soll (d.h. welchen Benutzernamen erwartet sshd dann, root?).

Das telnet-1.tar ist nicht von mir, es war einfach die erstbeste Methode die bei mir funktioniert hat um Zugang zu bekommen.

Bzgl start_atom_telnetd: Momentan installiere ich kein modifiziertes atom FS, d.h. atom/mod/etc/init.d/rc.tail.sh wird nicht verwendet (telnet wird via start_atom_telnetd vom arm core gestartet). Den autostart werde ich allerdings entfernen.

 

[erst_nachdenken]

Du hast das Telnet-Image aber (nach dem, was man bei Dir liest) in "release 2" geändert und dann beim Einpacken wohl ein "tar" verwendet, was seinerseits die erweiterten Header benutzt. Wäre nur schade/schlecht, wenn diese Änderung am Aufbau des Images am Ende dazu führt, daß es bei jemandem nicht funktioniert, der sich darauf verläßt, es wäre genauso aufgebaut wie das, worüber Du selbst den Telnet-Zugang erlangen konntest ... und das ist es eben mit den zusätzlichen Headern nicht.

Wenn Du den Unterschied sehen willst, kannst Du mal die beiden Images durch "firmwarecfg stream" jagen (auf stdin) und die Ergebnisse (tar-File auf stdout mit Änderungen durch AVM-Code) miteinander vergleichen. Ich würde aus dem Bauch heraus sagen, daß es Varianten von "firmwarecfg" gab, die sich an der Existent einer "/var/ignored_tar_content" nach dem Auspacken am Ende der Pipe gestört haben ... finde aber gerade keine passende Version, mit der ich das "beweisen" könnte. Trotzdem gehört es eben wegen dieser PaxHeaders zur üblichen Vorgehensweise in Freetz, Tarballs für das Update des FRITZ!OS mit dem "tar"-Applet der BusyBox zu erzeugen (das ist sogar (fast) der einzige Verwendungszweck der BusyBox auf dem Build-Host dort). Wie bereits geschrieben ... das muß nicht automatisch dadurch schieflaufen, aber es kann.

"ar7login" kennt sich tatsächlich mit den drei möglichen Modi der Anmeldung am FRITZ!OS aus ... wenn Du die FRITZ!Box so eingestellt haben solltest, daß ein Kennwort für alle gilt, dann wird ein Benutzer "@CompatMode" angelegt und dieser Benutzername in Kombination mit diesem "Generalschlüssel" verwendet (definitiv auch nicht der sicherste Modus, in dem man so eine FRITZ!Box betreiben kann). Parallel dazu wird dann noch ein Benutzer "ftpuser" für den (lokalen) Zugriff auf die NAS-Funktionen eingerichtet - den muß man bei den verschiedenen Diensten (Samba, FTP) dann auch angeben, wenn man das allgemeine Kennwort verwenden will (der kriegt bei der Einrichtung das "Box-Kennwort", aber spätere Änderungen werden nicht mehr synchronisiert und man müßte das für den Benutzer "ftpuser" über die Benutzerverwaltung machen).

Aber "ar7login" bringt beim "dropbear" tatsächlich nichts ... der macht in "svr-auth.c" die gesamte Authentifizierung alleine und liest auch selbst die /etc/passwd usw. (in common-session.c) - habe ich auch erst jetzt gesehen, ich verwende ansonsten nur "dropbear" als SSH-Server, wo alles mit Benutzernamen/Kennwörtern von Beginn an ausgeschaltet ist und nur noch schlüsselbasierte Anmeldung funktioniert. Dieser zusätzliche Benutzer "@CompatMode" wird auch vom AVM-Code nicht in die /etc/passwd geschrieben, damit kommt der auch nicht als Benutzername für den SSH-Zugriff in Frage.

 

[lleeaaddeerr]

Ich habe mir noch mal die Zeit genommen, den Updatevorgang auf 6.61 und 6.62 zu beschreiben

Vorweg vielen, vielen Dank an fesc mit dem Post #84 an stanpete78 für die Anleitung des Einspielens eines Pseudoimages und scuros für seine hilfreichen Tipps, was die Zertifikate angeht. Weiterhin an Nimloth und HabNeFritzbox für das linken und relinken der FW 6.61 im Post #396. Ohne euch hätte ich das nie geschafft!!!

Nun zum Vorgehen:

Hardware: FB 6490 lgi Branding FW 6.24 Herstelldatum Frühjahr 2016 und FB 6490 international Version FW 6.23 Herbst 2015

0. Fritzbox auf Werkseinstellungen zurücksetzen und Feststellen welche Fritz!OS Version auf eurer Fritz!box 6490 ist (Version 6.3X lässt sich nicht von kdg Branding auf avm Branding umstellen, bei Version 6.24 (lgi Branding im Original) und 6.23(international Version) war es möglich)
1. Branding FB 6490 aufavm stellen:
a) Windows Konsole aufrufen: z.B. durch Eingabe von
cmd
b) In Windows Konsole
ftp 192.168.178.1
eingeben (noch nicht mit Enter bestätigen)
c) Stromversorgungvon Fritzbox abziehen
d) Stromversorgungvon Fritzbox wieder anschließen
e) Warten bis die Fritzbox 2 oder 3 mal hintereinander geblinkt hat (2 bis 3 Sekunden) dann Enter in der Konsole drücken
f) dann einloggen mit Benutzername:
adam2
Enter und Passwort:
adam2
g) Enter. Dann
quote SETENV firmware_version avm
h) eingeben
i) Wenn die Ausgabe der erfolgreichen Umstellung kommt mit der Eingabe von
bye
ausloggen.
j) Fritzbox durch kurze Trennung der Stromversorgung neu starten

2. Firmware 6.61 laut Link in Post #393 herunterladen
http://download.avm.de/firmware/6490/35717120/FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.06.61.image

3. Fritz.box im Browser aufrufen (ich habe IE V11 benutzt)
a) Nach System/Sicherung/Wiederherstellen navigieren
b) "Entwickler-Tools"im Browser aktivieren
c) Rechtsklick auf den "Datei auswählen" Button --> Inspect
d) Folgende Elemente im HTML code ändern:
name=ConfigImportFile ändern in name=UploadFile
und
id=uiImportändern in id=uiFile
e) "Wiederherstellen" drücken (Bitte unbedingt warten, am Anfang hat sich bei mir nichts getan, dann hat die INFO LED angefangen zu blinken und die FW 6.61 wurde eingespielt. Habe dann solange gewartet bis die 6490 komplett neugestartet hat (WLAN LED ist dann wieder eingeschaltet).

4. Wenn keine Fehlermeldung erscheint, habt ihr das Update auf 6.61 erfolgreich vollzogen dann bitte zu Schritt 6 gehen

5. Wenn eine Fehlermeldung „Fehler 106 (Ein nicht näher spezifizierter Fehler traf während des Updates auf.)“ erscheint (war bei mir mit der Firmware 6.23 auch so) dann half folgendes
a) Windows Konsole aufrufen: z.B. durch Eingabe von
cmd
b) In Windows Konsole
ftp 192.168.178.1
eingeben (noch nicht mit Enter bestätigen)
c) Stromversorgung von Fritzbox abziehen
d) Stromversorgung von Fritzbox wieder anschließen
e) Warten bisdie Fritzbox 2 oder 3 mal hintereinander geblinkt hat (2 bis 3 Sekunden) dann Enter in der Konsole drücken
f) Nun einloggen mit Benutzername:
adam2
Enter und Passwort:
adam2
g) Enter dann Bootloader wechseln durch Eingabe von
quote SETENV linux_fs_start 1
h) Wenn der Bootloader schon auf 1 ist dann auf 0 wechseln mit Eingabe von
quote SETENV linux_fs_start 0
da die Firmware auf den anderen Bootloader installiert wird
i) Wenn die Ausgabe der erfolgreichen Umstellung kommt, mit der Eingabe von
bye
ausloggen
j) Fritzbox durch Trennung der Stromversorgung neu starten
k) Jetzt sollte die Fritzbox mit Fritz!OS 6.61 geladen werden.

6. Schritt 6 Updaten auf Fritz!OS Version 6.62
a) Nun die Fritzbox in den Zugangsdaten „Zugang über LAN 1“ hinter einen funktionierenden Internetanschluss (Kabelmodem) hängen oder gleich beim KNB provisionieren lassen und online gehen
b) NachSystem/Update navigieren und nach neuem Update suchen, mir wurde 6.62 angezeigt
c) den automatischen Updateprozess starten (Bei der Fritzbox mit der ursprünglichen Version 6.23 wurde im Updatefenster ein nicht funktionierender Link angezeigt, aber das hat dem erfolgreichen Update kein Abbruch getan.)

Wenn die Fritzboxoberfläche geladen ist, kann man mit Aufruf im Browser von http://fritz.box/?lp=support die Supportdata.txt herunter geladen werden. In dieser stehen dann die aktuell enthaltenen Zertifikate.
certificate:new/new

Für meinen KNB hat die neue Version und damit verbundene Zertifikatseinspielung gereichtum die beiden 6940 Geräte provisioniert zu bekommen.

Erfolgsmeldung:
Dank Eurer zahlreichen Postings ist es mir gelungen eine
FB6490 Artikel 20002691 mit FW 6.26 via Wiederherstellungsfunktion und "Entwickler-Tools" direkt auf 6.62 upzudaten.
CM certificate: new/new
MFG certificate: new/new
Zu Anfang bekam ich die Fehlermeldung dass die Datei zu groß sei. Ein Erhöhen des FileSize brachte gar nichts.
Erst nach der Änderung size="40" auf size="" in der zweiten Zeile lief das Update durch.
Danke an alle, die dazu beigetragen haben.
Herzliche Grüße Otti

 

[Pokemon20021]

kann man mit Aufruf im Browser von fritz.box/support-lua die Supportdata.txt herunter geladen werden.

Hallo lleeaaddeerr,
Bitte die URL korrigieren: richtig ist http://fritz.box/?lp=support

Gruß
Pokemon20021

 

[leseratte10]

Ich hätte da mal ein paar kleine Fragen zu den DOCSIS-Modellen und den neuen / alten Zertifikaten:

In alten Boxen sind die alten Zertifikate drin und durch das Update auf 06.61 (6490) lädt die Box die neuen Zertifikate von AVM. Wenn man danach ein Recovery macht - sind die neuen Zertifikate dann weg und die Box damit unbenutzbar, oder bleiben die?

Wie ist das bei der 6360 (von UM)?

Ich habe ne 6360 von UM, vorher mit 06.3x, gestern wurde sie geupdatet auf 06.50. Die Supportdaten geben an, dass die neuen Zertifikate drauf sind.
Ich hätte nun gerne irgendwie wieder einen Telnet-Zugang auf diese Box ...

Dazu ne Frage an PeterPawn: Du bist in Besitz eines CVC- sowie normalen Images von 06.50 für die 6490, richtig? Darf ich fragen, wie du daran gekommen bist? Gedumpt von der eigenen Box? Wenn ja, wie?

Wenn nämlich ein Recovery mir nicht die Zertifikate kaputt macht, sollte man doch mit dem alten 06.04-Recovery die 6360 downgraden können, und dann - wenn tatsächlich irgendwo ein 06.50-Image für die 6360 von AVM existiert - könnte man dieses 06.50-Image modifizieren, um einen eigenen Signier-Schlüssel reinzupacken (06.04 hat ja noch die Möglichkeit trotz falscher Signatur das einzuspielen), und könnte danach auf 06.50 ein mit dem eigenen Schlüssel signiertes Telnet-Image einspielen.

- Gibt es so ne 06.50 für die 6360 als Datei? Wo kommt die 6490-06.50-Datei her?
- Die 06.04 kennt schon den Trick mit dem Ändern des Upload-Formulars, richtig?
- Könnte das so funktionieren wie ich mir das vorstelle?

Leseratte10

 

[geronin]

Servus an alle Frizboxcracks und an die, die es noch werden wollen
kurze Vorgeschichte

Fritzbox 6490 Cable gebraucht von Voodafoon / KD
Artikel-Nr: 2691
Serien-Nr: E522.547
MAC: 34:81
KNB: Primacom
hatte OS 6.26 drauf gehabt nach der erfolgreichen update auf 6.50 nach fsec Anleitung (danke noch mal)
hatte ich dann 6.50 mit telnet das Problem war aber das ich immer noch
DOCSIS SUPPORT
CM certificate: old/old
MFG certificate: old/old
##### END SECTION DOCSIS

natürlich war meine Freude groß nach dem ich gestern nach eine Woche Auslandsreise zurück war und gesehen hatte was alles passiert war in der zeit das 6.61 und 6.62 Image draußen sind wollte ich sofort loslegen,
hab mir alles noch mal mehr oder weniger durchgelesen und dachte los gehts:

hab WAN auf LAN1 umgestellt und hab so wie schon bei der update auf 6.50 gleiches Prozedere gemacht und auf 6.61 upgedatet
Grundgedanke war per telnet von 6.50 auf 6.61 dann per Auto update über GUI auf 6.62 weil manche hier berichtet hatten das die Cert dann auf new/new sind ,soweit so gut

Also update von 6.50 auf 6.61 per telnet ging nicht so wie geplant bekam Meldung
/var/docsiscertdefaults: Kein CM Zertifikat im Urlader
dl complete but fp still open. (written 0 / 0)
dl complete but fp still open. (written 0 / 0)

Darauf hin hab ich per quote SETENV linux_fs_start umgeschaltet und hatte dann 6.61
so dann hab ich angefangen update per GUI auszuführen von 6.61 auf 6.62 nach der zeit kam Meldung spezifische Fehler 107
auch hier half Befehl quote SETENV linux_fs_start 0 so neustart und ich hatte 6.62
aber das Problem mit Cert ist geblieben
DOCSIS SUPPORT
CM certificate: old/old
MFG certificate: old/old
##### END SECTION DOCSIS
und ich kann mich immer noch bei primacom anmelden es kommt Meldung "Auth Reject - Permanent Authorization Failure"
weil die Box alte cerf hat.

Und das schlimmer dabei ist das ich mich selbst von telnet ausgeschlossen hatte weil

quote SETENV linux_fs_start 0 OS 6.62
quote SETENV linux_fs_start 1 OS 6.61

„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“
Albert Einstein

Meine Frage an die Profis wie hoffnungslos ist diese Lage und kriegt man in dem Zustand die neue cert drauf.?

Danke

 

[erst_nachdenken]

In alten Boxen sind die alten Zertifikate drin und durch das Update auf 06.61 (6490) lädt die Box die neuen Zertifikate von AVM.

Das Gerücht hält sich ja nun hartnäckig ... wer hat das denn bisher (belegbar) erlebt?

Eine 06.24 in der 6490, welche die eventuell schon seit der Produktion in der Box enthaltenen Zertifikate nicht benutzt und deren Update auf 06.61 (wo die dann genutzt würden, wenn sie vorhanden sind), hat ja noch nichts damit zu tun, daß da von AVM neue Zertifikate geladen wurden ... die waren bereits in der Box und werden halt in neuer Firmware dann benutzt.

Ein dateibasiertes Update beendet ja vor der Installation erst einmal auch den "dsld" und ich habe bisher immer noch nicht begriffen, wie jemand hier ein "Online-Update" einer alten FRITZ!OS-Version (< 06.60, ab da war dann das Online-Update tatsächlich drin) gemacht haben soll. Die Datei "/bin/prepare_fwupgrade" wird bei einem dateibasierten Update mit dem Parameter "start" aufgerufen (sieht man auch in der Prozessliste, wenn man den richtigen Zeitpunkt erwischt) und bei einem Online-Update mit "start_from_internet". Der entscheidende Unterschied ist dann diese Stelle in der "/bin/prepare_fwupgrade":

if [ "$1" != "start" ] ; then
## we will download the update image from the internet so keep dsld running
echo "" >/dev/null
else
PROCESSES="$PROCESSES mailer"
AVMDAEMONS="$AVMDAEMONS dsld avmike"
fi

Wenn das also der Aufruf mit "start" ist, werden der "dsld" und das VPN (avmike) der Liste der zu beendenden Prozesse hinzugefügt und am Ende von "/bin/prepare_fwupgrade" nicht mehr verfügbar sein. Damit kann so ein dateibasiertes Update gar nichts mehr aus dem Internet laden, solange es die notwendigen Dienste nicht wieder startet und genau das macht das "Pseudo-Image" für den Telnet-Start, sonst wäre das ein kurzes Vergnügen.

Damit kann im Rahmen des (hier mehrfach beschriebenen) Update-Prozesses (mit der Änderung des HTML-Formulars und dann ist das ein dateibasiertes Update) auf die 06.61 eben auch kein Zertifikat "geladen" werden ... ist es beim nächsten Neustart vorhanden, war es bereits vorher da. Die einfachste Art das (definitiv) zu testen, ist ein Update ohne Online-Verbindung.

Diese Zertifikate müßte man eigentlich auch nicht bei jedem Update neu von AVM versuchen zu laden (da sind m.E. Fehler im Ablauf) - wenn sie wirklich nicht von Beginn an im SPI-Flash liegen (wo sie bei der Finalisierung nach dem Zusammenschrauben landen), dann werden sie nach dem Download nach "/nvram" kopiert und bleiben dort auch ewig liegen (inzwischen auch über Recovery hinaus).

Gerade die 06.24 hat eben den Code zur Verwendung der bei der Produktion eingebrachten Zertifikate noch gar nicht an Bord - wer Telnet-Zugang zu so einer Box hat, kann das problemlos verifizieren. Wenn bei der 06.24 (30308) ein "cat /proc/sys/urlader/config" kein "ZERTIFIKATE" enthält, dann liegt das eben nicht daran, daß die Box kein neues Zertifikat hat - diese FRITZ!OS-Version enthält schlicht den Code für diese Anzeige noch nicht.

Wenn man bei so einer Box jetzt ein dateibasiertes Update von <= 06.24 auf die 06.61 ohne verkabelte Online-Verbindung ausführt (wie gesagt, das dateibasierte Update schießt den "dsld" ohnehin ab, darum wird der ganze Klimbim ja z.B. auch im "Pseudo-Image" im Anschluß erst mal neu gestartet - ab Zeile 26 - und das macht das AVM-Update-Skript schon mal nicht, weil das davon ausgeht, es wäre ein Online-Update) und anschließend sind da "neue" Zertifikate vorhanden, dann können die ja kaum von AVM geladen worden sein, oder?

Wer Telnet-Zugang zu einer 06.24 hat, kann ja noch einmal nach der "/bin/docsiscertdefaults" schauen, die gibt es dort gar nicht ... genau dort werden aber die Zertifikate der Box nach "/nvram" kopiert und diese Datei ist in Kopie auch in einem Update-Image enthalten und wird von "ewnw_check_install" aufgerufen (das wiederum von "install"):

#!/bin/sh
if [ -x /var/docsiscertdefaults ] ; then
   /var/docsiscertdefaults
fi
if [ -x /var/cm_dl_cert ] ; then
   exec /var/cm_dl_cert
fi
exit 0

Der Aufruf von "/var/docsiscertdefaults" kopiert also bei einer passenden Box (und einem passenden laufenden System, dazu gleich mehr) die Zertifikate nach "/nvram" (einfach nachzulesen, sind nur simple Shell-Kommandos) und eigentlich wäre bei einem Return-Code von 0 der nachfolgende Aufruf von "cm_dl_cert" (wo die Boxen dann vielleicht hängenbleiben, wenn man das dateibasierte Update macht) überflüssig.

Selbst wenn so ein Download aus irgendeinem obstrusen Grund funktionieren sollte, wird ja beim nächsten Start sofort wieder "/bin/docsiscertdefaults" ausgeführt und dort kann man ja sehen, daß die Zertifikate aus der Produktion jederzeit irgendwelche anderen in "/nvram" wieder überschreiben würden.

Aber so ein Update von einer OS-Version, die im laufenden Kernel den Code zur Anzeige von "ZERTIFIKATE" noch gar nicht hat (das findet sich in den Quellen in "arch/arm/mach-avalanche/puma6/prom.c", kann auch jeder nachlesen), kann eben auch beim Aufruf von "/var/docsiscertdefaults" aus dem laufenden System heraus diese Zertifikate noch gar nicht kopieren (ausnahmsweise mal in voller Schönheit, weil der "else"-Zweig ganz unten der entscheidende Punkt ist):

#!/bin/sh
[COLOR="#FF0000"]if test -e /proc/sys/urlader/config && grep -q ZERTIFIKATE < /proc/sys/urlader/config >/dev/null ; then[/COLOR]
   echo ZERTIFIKATE /var/tmp/urladercerts.tar.gz > /proc/sys/urlader/config
   if ! test -e /var/tmp/urladercerts.tar.gz ; then
      echo "$0: Konnte das CM Zertifikat nicht aus dem Urlader holen"
      exit 2
   fi
   if gunzip -d < /var/tmp/urladercerts.tar.gz | tar -xf - -C /var/tmp ; then
      test -d /nvram/1/security/download || mkdir -p /nvram/1/security/download
      for i in cm_cert.cer cm_key_prv.bin mfg_cert.cer mfg_key_pub.bin ; do
         if ! test -e /var/tmp/$i ; then
            echo "$0: $i: nicht im Tarfile enthalten"
            exit 2
         fi
         if test -e /nvram/1/security/download/$i && cmp -s /var/tmp/$i /nvram/1/security/download/$i ; then
            echo "$0: $i: in Ordnung"
         else
            rm -f /nvram/1/security/download/$i
            if cp /var/tmp/$i /nvram/1/security/download/$i ; then
               echo "$0: $i: kopiert"
            else
               echo "$0: Kopieren von $i fehlgeschlagen"
               exit 2
            fi
         fi
         if [ "`readlink /nvram/1/security/$i`" != /nvram/1/security/download/$i ] ; then
            rm -f /nvram/1/security/$i
            if ln -sf /nvram/1/security/download/$i /nvram/1/security/$i ; then
               echo "$0: $i: symlink erstellt"
            else
               echo "$0: Erzeugen des Symlinks fuer $i fehlgeschlagen"
            fi
         fi
      done
   else
      echo "$0: Fehler beim Auspacken des CM zertifikats"
      exit 2
   fi
[COLOR="#FF0000"]else
   echo "$0: Kein CM Zertifikat im Urlader"
fi[/COLOR]

Da würde also bei der Ausführung des Updates unter der 06.24 sogar noch "Kein CM Zertifikat im Urlader" angezeigt ... einfach deshalb, weil der Test am Beginn fehlschlagen muß. Anschließend wird versucht, "cm_dl_cert" zu starten, weil es gar keine Auswertung des Rückgabe-Wertes von "docsiscertdefaults" gibt - das würde also in jedem Falle aufgerufen. Wann das dann hängenbleibt und wann nicht, ist bisher wohl eher unklar ... vielleicht macht ja mal jemand einen Support-Case bei AVM dazu auf? Ich tippe mal, daß dieser ganze Update-Vorgang eigentlich nicht unbedingt dazu gedacht war, sinnvolle Anzeigen in "/dev/console" zu erzeugen ... das ist schlicht bei einer "normalen" Box gar nicht sichtbar.

Jedenfalls wird dann beim nächsten Neustart der Box in "/etc/init.d/S01-head" erneut das (inhaltsgleiche) "docsiscertdefaults" aufgerufen, diesmal aus "/bin" (in der neuen FRITZ!OS-Version) heraus:

######## Restore finalized Certificates (if necessary) ########
[ -x /bin/docsiscertdefaults ] && /bin/docsiscertdefaults
#####################################

An dieser Stelle wird jetzt also nach dem Update das Zertifikat der Box endlich nach "/nvram" kopiert. Die "übrig gebliebene" Datei "urladercerts.tar.gz" in "/var/tmp" in den Support-Daten ist dann genau das Ergebnis dieses Aufrufs in der "S01-head".

Wenn die Box jetzt immer noch kein "neues" Zertifikat hat (das kommt dann bis zu diesem Punkt eben aus der Finalisierung bei der Produktion und nicht von einem AVM-Server - wenn sie nicht schon vorher ein neues Zertifikat als Ergebnis eines früheren Downloads in "/nvram" hatte, was wieder nicht zu einer Version <= 06.24 passen würde), dann wird sie mit einiger Sicherheit auch keines mehr kriegen ... es sein denn, sie steht halt bei AVM "auf der Liste" und ist vom Provider für das Update gemeldet, hatte das aber bisher aus irgendeinem unerfindlichen Grund noch nicht erhalten. Aber auch das wird eben bei einem dateibasierten Update nicht funktionieren.

Dieser Vorgang wurde bisher (gerne lasse ich mich überzeugen/widerlegen) noch für keine 6490 "live" beobachtet. Aus so einem tatsächlich von AVM geladenen Zertifikat würde auch niemals eine Ausgabe von "ZERTIFIKATE" bei der Abfrage im procfs ... das steht dort nur, wenn die Zertifikate bereits von Beginn an in der Box waren. Wenn die 6490 alle aktualisiert sind (sonst könnte der Provider ja das alte Zertifikat nicht sperren), dann gäbe es theoretisch auch keinen Grund für AVM, den Download weiterhin zu ermöglichen - die logischste Handlungsweise wäre es also, wenn AVM den ohnehin abgeschaltet hat.

---

-Wegen des oben gezeigten Zusammenhangs glaube ich einfach nicht daran, daß eine beliebige 6490 einfach mit dem Update auf 06.6x auch neue Zertifikate von AVM erhält ... das halte ich für ein unbewiesenes Gerücht. Es mag vereinzelte Boxen geben, die von einem KNB "gemeldet" und dann doch nicht aktualisiert wurden, wo das heute noch im Nachhinein klappt - immer vorausgesetzt, der Service existiert überhaupt noch und da wäre die Frage, warum das so sein sollte. Ich habe das bisher jedenfalls nicht festgestellt, daß da irgendetwas antworten würde - es müßte schon extrem gute Gründe geben und die sehe ich nicht für die 6490.

In den bisher hier geschilderten "success stories" für die 6490 habe ich jedenfalls noch keinen Fall gelesen, der zweifelsfrei nur mit einem erfolgreichen Download neuer Zertifikate zu erklären wäre ... die Updates von <= 06.24 auf 06.61 wären nur dann tatsächlich mit einem Download in Verbindung zu bringen, wenn auch eine neuere FRITZ!OS-Version in der Ausgabe von "cat /proc/sys/urlader/config" das "ZERTIFIKATE" definitiv nicht enthält. Eine Box mit <= 06.24 als Ausgangspunkt eines Updates wird zumindest schon mal beim früheren Update auf die vorhandene Version (wenn das nicht die Auslieferungsversion war) keinen Download-Versuch gestartet haben ... da gab es das ja auch noch nicht.

---

-In der 06.61 oder 06.62 wird dann der Inhalt von "/nvram" auch bei Recovery nicht mehr gelöscht ... sowie die Datei "/bin/docsisfactorydefaults" existiert, werden die Verzeichnisse mit den Zertifikaten bei jeder Löschaktion in "/nvram" ausgenommen.

Da es Sache des startenden Systems ist, was es mit "/nvram" macht, kann man auch nicht einfach eine 6360 auf 06.04 "downgraden" mit dem vor langer Zeit mal geleakten Recovery-Programm. Dort sieht die "/etc/init.d/S01-head" so aus (an der entscheidenden Stelle):

if [ -n "${mtd_nvram}" ] && [ -n "${Recover_was_here}" ] ; then
del_mtd_nvram=${mtd_nvram#mtd}
del_mtd_nvram=${del_mtd_nvram%:*}
## erase nvram (formatting) due to preceding recover
nvram_erasestring="mtd ${del_mtd_nvram} erase all"
echo "[config-space/Recover] nvram erasing start ... (${nvram_erasestring})" > /dev/console
echo "${nvram_erasestring}" > /proc/mtd
echo "[config-space/Recover] nvram erasing ... done." > /dev/console
fi

Hier wird also in jedem Falle die Partition für "/nvram" über den MTD-Treiber gelöscht - damit sind dort abgelegte Zertifikate dann auch weg. Ich würde mir so ein Downgrade also gut überlegen ... Zertifikat und 06.50 ohne Telnet oder 06.04 mit bekannten Schwächen und kein Zertifikat. Mit viel Handarbeit könnte man vermutlich das oben gezeigte Löschen auch abwenden ... aber lohnt sich das wirklich und ist es das Risiko des Brickens auch wert?

BTW .. wenn man ein Image hätte, in das man einen eigenen öffentlichen Schlüssel einbauen könnte, um ein Pseudo-Image zu signieren .. warum sollte man dann nicht gleich den Telnet-Zugang anstelle des öffentlichen Schlüssels einbauen?

 

[fesc]

Meine Box hatte ursprünglich 6.10 , über 6.50 jetzt 6.62 (update immer via login, var/install).
Sie hat jetzt keine urlader "ZERTIFIKATE" (die entsprechende Meldung kommt immer bei einem Update via var/install).
In der Support.txt Datei sind die Zertifikate als New/New gelistet, und der Provider macht bisher keine Anstrengungen sie zu sperren.
Es wurde einmal ein automatischer update versucht (erfolglos) noch bevor sie provisioniert war (wodurch ich auf das CVC image gestoßen bin).