Fritzbox Talk Konfiguration der FB 7520 bearbeiten

1. Die wichtigste Datei. /etc/version​

Dort stehen unter anderem:​

• firmware_version
• provider
• brand
• annex

2. /etc/init.d/rc.conf oder /etc/rc.conf​

Auch dort findet man Branding-Informationen:​

• OEM
• OEM_DEFAULT
• CONFIG_PROVID

3. /etc/default.cfg​

Hier stehen tiefere Gerätekonfigurationswerte drin, u. a.:​

• firmware_info
• provider
• oem
• firmware_version

4. /var/firmware_version (abhängig vom Modell)​

Diese Datei existiert nicht in allen Versionen, enthält aber oft kurze Kennungen wie:​

• avm
• vodafone
• unitymedia

Was man im Ablauf sieht​

1. Login
   230 User adam2 successfully logged in — der Benutzer adam2 hat sich erfolgreich per FTP authentifiziert.
2. Media wechseln
   quote MEDIA FLSH → 200 Media set to MEDIA_FLASH
   Das FTP-Interface wurde so gesetzt, dass Operationen auf das Flash-Medium zielen (nicht z. B. RAM oder ein anderes Storage).
3. Binary-Transfermodus
   quote TYPE I → 200 Type set to BINARY
   Datenübertragung auf Binärmodus gesetzt — Standard, wenn man Images/Blöcke schreibt.
4. Passive Mode (PASV)
   quote PASV → 227 Entering Passive Mode (192,168,178,1,241,219)
   PASV meldet IP und Port. Der Port ist aus den beiden letzten Zahlen zu berechnen:
   Port = 241*256 + 219 = 61696 + 219 = 61915.
   (FTP öffnet auf dem Gerät einen TCP-Port 61915 für die Datenverbindung.)
5. Umgebungsvariable lesen
   quote GETENV firmware_version → firmware_version 1und1
   Die Variable firmware_version war initial 1und1.
6. Umgebungsvariable setzen
   quote SETENV firmware_version avm → 200 SETENV command successful
   Direkter Check danach: GETENV → firmware_version avm → zeigt, dass das Setzen im laufenden System wirksam wurde.
7. Reboot
   quote REBOOT → Server beendet Sitzung und rebootet. Verbindung vom Remotehost beendet.
8. Neuanmeldung nach Reboot
   Nach Reboot erneut eingeloggt, GETENV firmware_version → wieder 1und1.
   — Das geänderte avm hat den Neustart nicht überlebt.

Wahrscheinliche Erklärung / Interpretation​

• SETENV hat nur eine flüchtige (RAM) Änderung durchgeführt. Die Änderung war zur Laufzeit sichtbar, wurde aber nicht dauerhaft in den nichtflüchtigen Speicher (Flash / NVRAM / persistent environment) geschrieben.
• Beim Booten wird ein persistenter Wert (z. B. aus Flash, Factory-Partition oder Bootloader-Env) geladen, der wieder 1und1 liefert. Mögliche Stellen: u-boot environment, spezielle Config-Partition oder firmware-eigene Default-Konfiguration.
• Alternativ: Das System hat beim Reboot eine Art Integritäts-/Rollback-Mechanismus oder Signaturprüfung, die nicht-genehmigte/temporäre Änderungen verwirft und den „vertrauenswürdigen“ Wert wiederherstellt.
• Media = MEDIA_FLASH allein garantiert nicht, dass SETENV in Flash persistiert — es sagt nur, dass Operationen gegen Flash gerichtet sind.

Technische Hinweise / Verdächtige Punkte​

• Passive-Port (61915) wurde benutzt — normal. Kein Hinweis auf Netzproblem.
• SETENV wurde akzeptiert (200) — das Gerät erlaubt das Setzen, aber nicht zwangsläufig das dauerhafte Speichern.
• Kein Hinweis in den Logs auf einen fehlgeschlagenen save/commit-Befehl — typische persistent-Speicher-Befehle fehlen.

Konkrete nächste Schritte / Prüfungen (praktisch)​

1. Dokumentation / Hilfemenü des FTP-Servers prüfen: Gibt es Befehle wie SAVEENV, COMMIT, WRITEENV oder ähnliches?
2. Nach Konfigurationsdateien im Flash suchen (per Telnet/SSH, falls verfügbar): /etc/, /nvram/, /configs/ oder spezielle Partitionen.
3. Systemlogs beim Reboot prüfen (dmesg, syslog), ob ein Restore/Rollback angezeigt wird.
4. Bootstrap/Bootloader-Env prüfen (z. B. u-boot), oft ist das separate persistent storage.
5. Versuch: SETENV, dann gezielt nach einem save-ähnlichen Befehl suchen und erneut rebooten — beobachten, ob Änderung dann bleibt.
6. Sicherheitscheck: wer darf SETENV ausführen? Der Account adam2 hat Rechte, aber das kann ein Sicherheitsrisiko sein — prüfen, ob Beschränkungen/Logging vorhanden sind.

Kurzfazit​