Mittlerweile habe ich bereits die zweite Box mit Werkseinstellungen. Beide mit 50.000 VDSL von 1und1.
Vielleicht ja doch das von informerex in #178 angedachte Problem bei diesem Provider? Nach dem, was ich beim (flüchtigen) Nachlesen gefunden habe, wäre Cobold der einzige, der beim 1&1-Anschluß "aus der Reihe tanzt", wenn die Signatur stimmt. Andererseits war das da ja vermutlich auch eine Umschaltung auf die andere Partition ... insofern ist auch das eine Abweichung (da wäre es gut mal zu wissen, ob in der anderen Partition tatsächlich die neuere Version des Systems steht).
Wenn da 1&1 irgendwelche regelmäßigen TR-069-Inform-Requests falsch interpretiert und die Box zu einem Downgrade auf die "offizielle Version" überreden will, dann wäre der Verlust der Einstellungen nur folgerichtig ... genauso steht das in der "install"-Datei eines Firmware-Images:
Code:
##################################################################################
# Downgrade with factorysettings or normal update ?
##################################################################################
if [ "${force_update}" = "y" ] ; then
echo "Force: Accept Firmware Version: xx.${newFWver} "
echo "Force: factorysettings ..."
[...]
##################################################################################
# factorysettings tffs: ID's erst ab 100 (0x64) loeschen
##################################################################################
id=$((0x64))
while [ $id -le 255 ] ; do
echo "clear_id $id" >/proc/tffs
id=$(($id + 1))
done
id=$((0x4000))
while [ $id -le $((0x4040)) ] ; do
echo "clear_id $id" >/proc/tffs
id=$(($id + 1))
done
id=$((0x4400))
while [ $id -le $((0x4440)) ] ; do
echo "clear_id $id" >/proc/tffs
id=$(($id + 1))
done
echo "Force: factorysettings done."
else
[...]
Da dieses Löschen der Einstellungen bereits vor dem Flashen der neuen Firmware erfolgt, würde ein späterer Fehler beim Flashen (vielleicht auch das Timeout zum automatischen Reboot der Box) die Umschaltung des Systems auf die andere Partition verhindern, das ist erst der allerletzte Schritt. Das Ergebnis wäre eine Box mit demselben System und gelöschten Einstellungen.
Da stellt sich dann ggf. die Frage (immer vorausgesetzt, die Annahme stimmt ... das kann man nur mit entsprechenden Vorbereitungen - z.B. einer angepaßten prepare_fwupgrade, die einige Dateien aus /var auf einen USB-Stick sichert - überprüfen), was 1&1 da eigentlich macht und wieso dort ein Firmware-Update mit "force" (s.o.) für ein Downgrade erfolgen sollte. Wenn das nicht nur 1&1-Kunden betrifft, wäre trotzdem die Frage interessant, woher das kommt. Normalerweise würde eine FRITZ!Box immer versuchen, ein Crash-Log zu schreiben (bei Kernel-Error auch ein Panic-Log), dort sollte man zumindest einen Anhaltspunkt finden, wenn diese Dateien nicht automatisch an AVM gesendet und anschließend gelöscht werden. Hat jemand mit dem "Reset-Problem" mal unmittelbar die Support-Daten gezogen anstatt seine gesicherten Einstellungen wieder einzuspielen? Wenn nicht, könnte das der nächste Unglückliche mal freundlicherweise machen? Ich würde da zu gerne mal einen Blick hineinwerfen.
M.W. benutzt die Telekom kein TR-069 bei FRITZ!Boxen (allerdings weiß ich das für 06.35 nicht wirklich) und somit fällt das bei Cobold als mögliche Ursache eigentlich aus.