Alice 7570 mit 16 MB Flash (war: nur 8 MB; fritzen fehlgeschlagen und kein Rückweg)

Sehr schön, dass Du dich einschaltest!

Könntest du hier noch einmal die Paar Zeilen wiederholen die man unter Telnet braucht damit möglichst sichergestellt ist, dass keine defekten Damps verschickt werden.
Ich bin nicht so sicher ob ich da nicht auch Fehler machen würde oder könnte.
 
s. http://freetz.org/wiki/help/howtos/development/save_mtd_1

1. USB Stick an 7570-HN anschließen
2. Telnet Verbindung herstellen
3. mount Befehl ausführen, um zu sehen, wo der USB Stick gemountet wird (z.B. /var/media/ftp/...)
4. cat /proc/sys/urlader/environment | grep mtd (als Info zum Posten im Forum)
5. cat /proc/partitions (als Info zum Posten im Froum)
6. Auslesen: cat /dev/mtdblock0 > /var/media/ftp/<USB-Stick>/mtdblock0 (für alle mtdblöcke, also jeweils um 1 hochzählen)
7. Anhand der Ausgaben unter 4. kann gesehen werden, welcher mtdblock den Boot-Loader und welcher Kernel+Dateisystem enthält (Bootloader vermutlich ca. 128 kB, Kernel+Dateisytem - kernel.img ca. 8MB -> bei meiner 7270v3 sind dies mtdblock0: Kernel+Dateisystem, mtdblock2: Bootloader)
8. Für das Forum wäre auch noch der erste Teil der Ausgabe von cat /proc/sys/urlader/environment interessant - bitte alles ab "maca" vor dem Posten löschen

Annahme: Die 7570-HN verwendet zwei ~8MB große Flash Bereiche um eine sichere Aktualisierung auf neue FW Versionen durchzuführen, d.h. eine neue Firmware wird zunächst in einen Spiegelbereich geladen, um später in den aktiven Bereich kopiert zu werden. Dies ist erforderlich, damit bei Spannungsausfällen wärend des Flashens des aktiven FW Bereiches noch eine funktionierende FW auf dem Gerät verfügbar zu haben.
 
Zuletzt bearbeitet:
Das ist sicher für jemanden Ausreichend der weiß wie man Telnet auf der Box aktiviert.
FTP lässt sich möglicherweise bei einer 7570-HN auch nicht so ohne wertes über die GUI anschalten,
also sind auch da noch Handarbeit in der Kommandozeile notwendig.

Die Frage ist ob sichergestellt ist, dass die Damps der Blöcke die am USB Stick landen Fehlerfrei auch von dort wieder gepostet werden.
Könnte man die bereits auf der Box in ein tar packen, oder sollte man noch weitere Vorsichtsmaßnahmen treffen?
 
Ich hätte es auch so in der Art gesagt...
Kann man denn auf diesen Boxen ein "fremdes" Update (ein Pseudo-Update) aufbringen? Dann würde ich mich mal daran versuchen, das alles in ein solches in dieser Art hineinzupacken (Anregungen willkommen ;-)):

- Das Pseudoupdate enthält eine "eigene" Busybox für nicht vorhandene Befehle (Frage: Was ist in einer "normalen" BB drin??)
- Während des "Updates" zieht die Box jeweils eine Kopie der mtd's nach "/var/tmp" und vergleicht das "Ergebnis" (per "cmp") mit dem Original mtd
- Die Dateien werden als "tar" verpackt (und/oder per gzip kompirimiert, dann ist es "sicher" als Binary verpackt) und entweder auf einen USB-Stick geschrieben oder man macht sie über den "httpd" als Datei herunterladbar ...

Jörg

EDIT: Aber um die Frage zu beantworten, wie man die "Integrität" sicherstellt, ich würde es so machen:
Code:
# auslesen von mtd1 (= mtdblock2, vermute ich, das wäre "kernel" in /proc/mtd):
cat /dev/mtdblock2 >  /var/media/ftp/<USBSTICK>/mtd1
# vergleichen ([B]keine[/B] Ausgabe heißt identisch!)
cmp  /dev/mtdblock2  /var/media/ftp/<USBSTICK>/mtd1

# auslesen von mtd5 (= mtdblock6, vermute ich):
cat /dev/mtdblock6 >  /var/media/ftp/<USBSTICK>/mtd5
# vergleichen ([B]keine[/B] Ausgabe heißt identisch!)
cmp  /dev/mtdblock6  /var/media/ftp/<USBSTICK>/mtd5

Für das genaue Zuordnen der Größen und MTDs könnte mal jemand von einer Box die Ausgaben hiervon posten (wie oben auch schon von Fox.Mulder angefragt ):

Code:
cat /proc/partitions 
cat /proc/mtd 

echo -e "Size in Environment: \n\
$(for MTD in $(cat /proc/sys/urlader/environment | grep mtd | tr ' \t' '=='); do 
	aktmtd=${MTD//=*/}; \
	mtdpos=${MTD//*=/} ; \
	mtdstart=${mtdpos//,*/} ; \
	mtdend=${mtdpos//*,/} ; \
	SIZE=$(( $mtdend - $mtdstart )); \
	SIZE_K=$(( $SIZE / 1024 )); \
	SIZE_MB=$(( $SIZE_K / 1024 )) ;\
	echo -n "$MTD is $SIZE ($SIZE_K kB" ; \
	[ $SIZE_MB -gt 1 ] && echo -n " = ${SIZE_MB},$(( $SIZE_K *1000 / 1024  - 1000 * $SIZE_MB )) MB" ;\
	echo ")" ;
done
)"
 
Zuletzt bearbeitet:
Das ist sicher für jemanden Ausreichend der weiß wie man Telnet auf der Box aktiviert.
FTP lässt sich möglicherweise bei einer 7570-HN auch nicht so ohne wertes über die GUI anschalten,
also sind auch da noch Handarbeit in der Kommandozeile notwendig.

Die Frage ist ob sichergestellt ist, dass die Damps der Blöcke die am USB Stick landen Fehlerfrei auch von dort wieder gepostet werden.
Könnte man die bereits auf der Box in ein tar packen, oder sollte man noch weitere Vorsichtsmaßnahmen treffen?

Wie Telnet aktiviert wird steht im ersten von mir geposteten Link. Eine Aktivierung von ftp ist nicht erforderlich, da die Blöcke direkt auf den USB Stick geschrieben werden. Dieser USB Stick kann dann am PC ausgelesen werden. Zur Sicherheit könnte man zur Not auch jeden Block 2x auslesen und den Inhalt beider Blöcke am PC vergleichen.

Ein Pseudo Update ist nicht möglich!

Telnet Freischaltung über abspeichern, ändern und wieder laden der Konfiguration! Wie ich gerade gelesen habe, geht das aber nur, wenn man einen Alice Anschluss hat, da man zur Aktivierung von Telnet sich erst einmal auf dem aktiven Alice Telefonieanschluss anrufen muss.
 
Zuletzt bearbeitet:
Hallo,

ich hoffe euch helfen die Daten weiter.

@ Jpascher, der gewünschte mdt ist per Mail auf dem Weg.
 

Anhänge

  • partitions.jpg
    partitions.jpg
    53.8 KB · Aufrufe: 41
  • mtd.jpg
    mtd.jpg
    45.9 KB · Aufrufe: 29
  • environment.jpg
    environment.jpg
    43.1 KB · Aufrufe: 24
  • urlader.jpg
    urlader.jpg
    85.5 KB · Aufrufe: 36
@Silencer1982: Hast Du einen USB Stick, den Du mal anschließen und den mount Befehl ausführen kannst? Dann kann ich Dir die genauen Befehle zum Auslesen geben.

mtdblock0 => kernel+filesystem => kernel.img
mtdblock2 => bootloader
mtdblock5 => gesamter Flash

cat /dev/mtdblock0 > /var/media/ftp/<USB-Stick>/mtdblock0
cat /dev/mtdblock2 > /var/media/ftp/<USB-Stick>/mtdblock2
cat /dev/mtdblock5 > /var/media/ftp/<USB-Stick>/mtdblock5

Aus dem Dump von mtdblock5 könnte man den Spiegelbereich von kernel+filesystems extrahieren und mit dem Inhalt von mtdblock0 vergleichen. Wenn Du mir die Dumps per email schicken kannst, kann ich das übernehmen.

mtd1 und mtd5 haben die gleiche Größe (kernel+filesystem: 1. Original, 2. Backup)
mtd2: Bootloader
mtd3/mtd4: TFFS für Konfig-Daten + Kopie
 
Zuletzt bearbeitet:
Ja hab ich. Der gewünschte Block ist doch per Mail schon auf den weg an Jpascher.
Benötigt ihr noch weitere Daten?
 
Ich habe mtdblock0 und mtdblock2 mit den jeweiligen Speicherbereichen von mtdblock5 mit folgendem Ergebnis verglichen:

mtdblock2 = mtd2 aus mtdblock5 (Bootloader)
mtdblock0 != mtd1 aus mtdblock5 (kernel+filesystem)
mtd5 aus mtdblock5 (Spiegelbereich) ist leer

mtdblock0 wird von ruKT nicht als gültiges kernel.image akzeptiert. mtd1 aus mtdblock5 wird von ruKT als gültiges kernel.image akzeptiert. Aus diesem Grund nehme ich an, dass mtd1 aus mtdblock5 ein funktionierendes kernel.image sein könnte.

Da der Spiegelbereich leer ist, vermute ich folgenden Ablauf der Firmwareaktualisierung:

1. Alice überträge neue Firmware in den Spiegelbereich im Flash
2. Gültigkeit des Inhaltes des Spiegelbereiches wird überprüft
3. Inhalt des Spiegelbereiches wird in den Originalbereich kopiert
4. Gültigkeit des Inhaltes des Originalbereiches wird überprüft
5. Spiegelbereich wird gelöscht

Sollte währen der Übertragung der Daten vom Spiegelbereich in den Originalbereich etwas schief gehen, kann dieser Prozess solange wiederholt werden, bis der Originalbereich wieder gültige Daten enthält.
 
Danke erhalten, habe den Damp verglichen mit einen anderen den ich habe.
In weiten Bereichen sind die Damps gleich der Bootlader scheint jedoch unterschiede aufzuweisen.
 
Zuletzt bearbeitet:
mtdblock0 != mtd1 aus mtdblock5 (kernel+filesystem)
....
mtdblock0 wird von ruKT nicht als gültiges kernel.image akzeptiert.
Das liegt wohl daran, dass bei diesen Boxen eigentlich mtdblock0 und mtdblock1 "zusammengesetzt" werden müssen.

Also ist an der Stelle mit dem Versatz (Größe Urlader + Größe Kernel) in dem Gesamtflash "Filesystem" zu finden??
Oder anders ausgedrückt, wenn man zusätzlich noch "mtdblock1" ausgelesen hätte, wäre (mtdblock1 + mtdblock0) ein "gültiges" Filesystem?

Ich hoffe, ich konnte die Idee deutlich machen ;-)

Um mal die "echten" mtds auszulesen (wie sie im Env eingetragen sind) könntest du folgendes versuchen (sollte mtd1, mtd2 und mtd5 laut env sichern, bei Bedarf in der letzten Zeile das "of=" so anpassen, dass es auf dem Stick liegt):
Code:
for MTD in $(cat /proc/sys/urlader/environment | grep mtd[1\|2\|5] | tr ' \t' '=='); do 
	aktmtd=${MTD//=*/}; \
	mtdpos=${MTD//*=/} ; \
	mtdstart=${mtdpos//,*/} ; \
	mtdend=${mtdpos//*,/} ; \
	SIZE=$(( $mtdend - $mtdstart )); \
	SIZE_K=$(( $SIZE / 1024 )); \
	VERSATZ=$(( ($mtdstart - 0x90000000) / 1024 )) ;\
	echo  "$MTD is $SIZE ($SIZE_K kB)" ; \
	echo "Vers=$VERSATZ" ; \
	SKIP=$(( 262144  + $VERSATZ )) ; \
	echo "Skip=$SKIP" ; \
	dd if=/dev/mem bs=1k skip=$SKIP count=$SIZE_K of=/var/tmp/dump_${aktmtd} 
done

Bei einer 7270 gilt, dass "cat flash_mtdblock1.dump flash_mtdblock0.dump > mtdblock_1und0.dump" wie erwartet dazu führt, dass "cmp mtdblock_1und0.dump flash_mtd1.dump" keine Unterschiede anzeigt.

Also, meine Sicht wäre (mtdblock1 + mtdblock0) = mtd1 oder:
mtdblock1 + mtdblock0 => kernel+filesystem => kernel.img

Jörg
 
Zuletzt bearbeitet:
Der Versatz beträgt E2E00. Demzufolge sollte das extrahierte mtd1 eigentlich OK sein.

@Japscher, im EVA Bootloader sind bestimmte individuelle Werte, wie z.B. die MAC Adresse(n), ProductID, HWRevision u.ä. eingetragen. Deshalb könnten sich die Bootloader unterscheiden. Evtl. ist auch die Version unterschiedlich. Kannst Du ausprobieren, ob man das mtd1 Kernel Image auf einer W920V flashen kann?
 
Zuletzt bearbeitet:
Gut zu wissen !
Wenn ich es recht bedenke, hilft das aber bei der "Nutzungsfrage" wenig.
Durch die Tatsache, dass der "Spiegelbereich" nicht als /dev/mtdblock<X> zu erreichen ist, scheidet die Idee eines "aufgeteilten" Images mit einer zweiten Partition wohl aus, wirklich helfen würde also wohl nur, im Bootlader mtd1 auf den ganzem Bereich (mtd1+mtd5) zu vergrößern (alles Bootaler/Env-Namen)....

Vielleicht findet sich ja doch noch ein Mutiger, der mit einer Konsole an die Box geht und den Vorschlag aus Beitrag #102 testet.
 
Auf einen W920 hab ich doch das schon vor Monaten aufgespielt ohne Probleme.
Und der neue Damp ist bezüglich kernel.image ja gleich.

@MaxMuster
Beitrag #102 habe ich testweise auf meinen W920 versucht.
Sehe dir die Codierung nochmal bin am Fehlersuchen ...
 
Was ihr euch hier für einen Kopp macht. Dabei ist die Lösung so einfach:
1. Finger weg von Alice VDSL
2. Finger weg vom Alice IAD 7570

Und schon sind alle Probleme aus der Welt ;)

Grüßle

Der Mikrogigant
 
Telnet lässt sich per Callog auch nur bei alten Firmwareversionen aktivieren.
 
ich habe noch die alte Firmware 81.04.86 drauf da ich die 7570HN gleich gegen eine 7390 getauscht habe.
Gibt es die Möglichkeit auch einen Dump zu erstellen wenn ich die 81.04.90 oder 91 (weiß gerade nicht welche aktuell ist) drauf habe.
Zur Not würde ich die Box auch öffnen.
 
Wenn die neue FW schon drauf sein sollte, ohne dass Telnet vorher aktiviert wurde, wäre evtl. ein Dump über die serielle Konsole möglich. Falls Telnet vorher aktiviert wurde, wäre es evtl. möglich, dass ein Zugriff darüber weiterhin möglich ist. Aber die Aktivierung per Konfiguration könnte durch die neue FW auch zurückgesetzt werden.

Ich habe nun mtdblock1 + mtdblock0 zu kernel.image zusammengefügt und mit mtd1 verglichen. Dabei gibt es Unterschiede ab 79FE00. Im kernel.image ist der Bereich ab der angegebenen Adresse bis zum Ende mit 00 gefült, im mtd1 jedoch mit FF. Wahrscheinlich wird dieser Unterschied aber nicht funktionsrelevant sein.

Traut sich jemand, einen Flashversuch seiner 7570-HN zu wagen? Es kann aber nicht ausgeschlossen werden, dass die Box danach nicht mehr läuft!
 
Zuletzt bearbeitet:
Das wäre aber noch kein Fortschritt, mtd1 ist immer noch zu klein, oder?
Die Frage ist, wie weit man zum Risiko bereit ist, denn momentan sehe ich nur die möglichkeit, den Lader zu patchen, was ein gewisses Risiko birgt. Es gäbe evtl. eine “halbe “ Alternative, dies über ein Recover zu versuchen in der Art: Wenn die Versionsnummer falsch ist, überschreibt das Recover auch den Lader. Man könnte so versuchen, per FTP die mtd-Werte zu ändern, einen ungültigen wert bei der Version angeben und dann (ohne Neustart) recovern.
Ansonsten eben nur die beiden Werte ändern (ggf mtd5 auch löschen)

Jörg
 
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.