[Sammlung] Was sollte man bei eigenen Änderungen beachten bei neueren Versionen des FRITZ!OS?

[PeterPawn]

Ich will hier mal eine Sammlung aufmachen, in der wichtige Änderungen in neueren Firmware-Versionen (ab 06.9x) zusammengefaßt werden.

Nicht alle Modelle haben ja eine 06.9x erhalten und schon bei dieser hat AVM an einigen Stellen massive Änderungen vorgenommen, die man beim Modifizieren der Firmware ggf. berücksichtigen muß.

Die Aufzählung (und auch hinzugefügte "Erklärungen" meinerseits) erhebt/erheben keinen Anspruch auf Vollständigkeit und/oder irgendeine logische Reihenfolge.

Benutzung von Dateinamen für eigene Erweiterungen

Schon vor der Version 06.9x hat AVM eine Protokollierung für den Update-Prozess eingeführt, dieses Protokoll (/var/tmp/fwupdate.log) wurde auch - wenn vorhanden, was eher selten ist, weil nach Update neu gestartet wird - mit in die Support-Datei aufgenommen.

Seit Version 06.9x trifft AVM aber in der Datei "/sbin/prepare_fwupgrade" (hier werden die meisten Dienste des FRITZ!OS vor einem Update der Firmware gestoppt) auch noch Vorbereitungen für "saubere" Log-Dateien und die sehen so aus:

181 rm -f /var/install
182 rm -f /var/tmp/*.image
183 rm -f /var/*.log
184 rm -f /var/log/*.log
185 for file in /var/tmp/*.log ; do
186 if [ $file != /var/tmp/fwupdate.log ] ; then
187 rm -f $i
188 fi
189 done

Da wird also nicht nur eine vorhandene "install"-Datei abgeräumt und jede Datei mit einem Namen "*.image" im Verzeichnis "/var/tmp" gelöscht (diese "*.image"-Dateien könnten von einem vorhergehenden Update-Versuch stammen, der mit Fehlernachricht abgebrochen wurde, aber die Möglichkeit der Wiederholung vor dem Reboot bietet - beim Auspacken könnten sie auch dann schon stören, wenn sie später durch die erneut ausgepackte Datei ersetzt werden), sondern es werden auch noch alle Dateien mit einem Namen, der auf "*.log" paßt, aus den Verzeichnissen "/var", "/var/log" und "/var/tmp" gelöscht, mit Ausnahme der erwähnten "fwupdate.log".

Nun kann man das Löschen solcher Log-Files sicherlich als Teil des "Platzschaffens" im Speicher (eben auch im "tmpfs") für das bevorstehende Update interpretieren ... das heißt aber im Umkehrschluß auch, daß man in eigenen Erweiterungen besser keine Dateien länger "*.log" (oder auch "*.image") nennt, wenn man diese Dateien im "tmpfs" ablegt und darauf (z.B. aus einer eigenen Image-Datei, deren "install"-Skript erst nach einem "prepare_fwupgrade" ausgeführt würde) noch zugreifen will.

Ich habe ja im "modfs"-Kontext u.a. auch die Empfehlung stehen, daß man mittels "prepare_fwupgrade start_tr069" noch etwas mehr Platz in der Box schaffen könnte, wenn das Packen wegen Platzmangels abgebrochen wird. Seitdem dort aber die Verwendung von Swap-Space "Pflicht" ist, sollte das auch nicht mehr kriegsentscheidend sein.

Auf der anderen Seite kann man dieses Wissen dann auch wieder nutzen, um (relativ sorglos und auch in größerem Umfang) in eigene Dateien zu protokollieren und sich dabei darauf verlassen, daß daraus kein Hindernis für ein Update entsteht ... weil die Datei eben vorher entsorgt würde, sofern sie einen passenden Namen hat.

Protokollierung von Zugriffen auf AVM-GUI und TR-064/UPnP

AVM hat mit 07.0x eine Protokollierung der Zugriffe auf die enthaltenen "Webserver" eingebaut, sowohl der "ctlmgr" (für das "normale" GUI) als auch der "upnpd" (für TR-064) zeichnen jetzt jeden Request in einem eigenen Ringpuffer auf (jeweils erfolgreiche und fehlerhafte (in erster Linie "not found") auch noch einmal getrennt), diese Protokolle kann man sich (mit Shell-Zugriff) mittels:

showshringbuf waccess
showshringbuf werror
showshringbuf upnp_access
showshringbuf upnp_error

ansehen. Zwar sieht man nur die "üblichen" Infos, die man aus solchen Log-Files kennt (also auch keinen POST-Body o.ä.), aber das Format ist praktisch dasselbe, welches man auch mit div. anderen Webservern erzeugen könnte. Für die Kontrolle eines Zugriffs (IP-Adresse, Fehlercode, URL, usw.) reicht das häufig schon, vor allem, wenn man damit auch regelmäßige XHR aus eigenem Code auf der "Serverseite" ansehen und registrieren kann.

Eingehende WAN-Verbindungen für eigene Dienste auf der FRITZ!Box

Seitdem AVM die Freigaben über PCP erledigt (nein, das sind keine Drogen, sondern das Port Control Protocol aus RFC 6887), ist das mit den Einträgen in der "ar7.cfg" (sowohl bei "internet_forwardrules" als auch bei "voip_forwardrules") und der "vpn.cfg" ja nicht mehr so einfach, die Ports für eigene Dienste auch freizuschalten.

Seit 07.0x funktioniert die "vpn.cfg" jetzt wohl gar nicht mehr und der einzige verbliebene Platz für eigene Portfreigaben ist wohl die "voip_forwardrules"-Einstellung. Die wird aber auch nur dann aktiviert (wenn man sie denn richtig in der "ar7.cfg" eingetragen hat, was auch nicht immer ganz einfach ist und die diversen alten Anleitungen, die auch noch "ar7cfgchanged" referenzieren, helfen dabei nicht gerade weiter), wenn auch der "voipd" gestartet ist. Das kann man zwar mit einem Dummy-Eintrag für die Telefonie auch irgendwie alles in den Griff bekommen, aber es ist schon einigermaßen kompliziert.

Wer einen eigenen Service implementieren will (z.B. einen OpenVPN-Zugang), der kann aber auch das Programm "pcplisten" verwenden, welches AVM selbst auch für den "ftpd" benutzt, wenn aus dem Internet bei einem passiven Transfer-Request auf einen ansonsten geschlossenen Port zugegriffen werden soll:

 40         snprintf(buf, sizeof(buf), "%s tcp %s %u %u ftp-data", PCPLISTEN, sockaddr_addr2string(addr), sockaddr_port(addr), timeout_sec);

Dessen Aufruf sieht folgendermaßen aus:

root@FB7490:~ $ pcplisten -?
usage: pcplisten tcp|udp address port lifetime description
options:
  -?                 - print this help
  -N                 - don't ignore proxy error. (NOTSET)
  -D STRING          - switch debug logs on. (FUNC)
open listen port on local address for lifetime seconds
exit codes
0 - listen port opened
1 - wrong usage
2 - pcp error
3 - no pcp server
root@FB7490:~ $

Das Protokoll erklärt sich von selbst, als Adresse ist entweder eine lokale IPv4-Adresse anzugeben (das muß auch eine lokale auf der Box selbst sein, mit "pcplisten" läßt sich keine Freigabe ins LAN einrichten) oder auch eine IPv6-Adresse. Der Port ist bei PCP nur eine "Wunschvorstellung" ... der PCP-Server darf den durchaus durch einen anderen ersetzen, wenn der angeforderte Port nicht mehr zur Verfügung steht. Auch "description" versteht sich von alleine und stellt nur eine Beschreibung bereit, die u.a. auch in der Diagnose-Seite für den offenen Port angezeigt wird (als "FRITZ!Box-Dienst").

Welche (externe) Adresse die Freigabe dann betrifft und welcher Port es geworden ist, sieht man in der Ausgabe des Programms ... bei einem Exit-Code von 0 besteht die Ausgabe auf STDOUT aus einem "OK:", gefolgt von der externen IP-Adresse und der Portnummer.

Spannender wird es bei der "lifetime" - hier erlaubt zwar das Programm die Angabe von bis zu 300 Sekunden:

root@FB7490:~ $ pcplisten tcp 192.168.xxx.1 443 301 Invalid_LifeTime
ERROR: illegal lifetime: 301
usage: pcplisten tcp|udp address port lifetime description
options:
  -?                 - print this help
  -N                 - don't ignore proxy error. (NOTSET)
  -D STRING          - switch debug logs on. (FUNC)
open listen port on local address for lifetime seconds
exit codes
0 - listen port opened
1 - wrong usage
2 - pcp error
3 - no pcp server
root@FB7490:~ $ pcplisten tcp 192.168.xxx.1 443 300 MaximumLifeTime
OK: 192.168.xxx.13 443
root@FB7490:~ $

, aber in Wirklichkeit wird eine max. Lifetime von 120 Sekunden unterstützt.

Ob das jetzt schon in "pcplisten" oder erst im PCP-Server bzw. -Proxy entschieden wird (denn auch der MAP-Request hat nur eine Lifetime von 120 Sekunden im Paket stehen), weiß ich nicht ... es spielt aber auch nicht wirklich eine Rolle.

Will man einen solchen Port auf Dauer freigeben, muß man also seinen MAP-Request innerhalb von 120 Sekunden erneuern ... irgendwie muß man sich also eine Schleife um den Aufruf von "pcplisten" basteln und diese spätestens alle 120 Sekunden einmal durchlaufen. Frühere Erneuerungen sind auch kein Problem ... das muß also nicht auf die Sekunde genau sein.

Nun ist es ja kein wirkliches Problem, in einem Start-Skript eine gesonderte Task zu erstellen, die mit "sleep 118" in einer Schleife immer wieder das "pcplisten" aufruft ... das wäre dann die einfachste Form, die man in ein Skript zum Start eines Dienstes integrieren kann, der von der WAN-Seite direkt erreichbar sein soll. Wer will, kann sich ja auch vom AVM-Relikt (das eigentlich nicht mehr benötigt wird, weil die Speicherangaben alle in der "avm_kernel_config" stehen seit dem 3.10-Kernel der 06.5x) inspirieren lassen, mit dem in der "/etc/init.d/rc.tail.sh" immer noch ein "Zusammenrechnen" der Speichergrößen aller Module nach 10 Minuten Laufzeit ausgeführt wird:

#########################################################################
## modulemem: mit 'fork' <set_m_sleep> Minuten warten, bis alle module gestartet sind.
#########################################################################
if [ -x "/bin/set_modulemem" ] ; then
set_m_sleep=$((10*60))
nohup sh -c "echo \"\$0[\$\$]: ++++fork set_modulemen, sleep ${set_m_sleep}++++\" > /dev/console ; sleep ${set_m_sleep}; echo \"\$0[\$\$]: ++++do set_modulemen++++\" > /dev/console; /bin/set_modulemem;" &
fi

Das mit anderer Verzögerung und in einer passenden Schleife (while true; do ... done) verpackt (nicht "mit" einer Schleife ) und man hat seinen eigenen kleinen PCP-MAP-Service, den man ggf. auch beim Beenden des Services, für den er den Port freigeben soll, gleich noch mit abschießen kann.

Die Verwendung des PCP-Service für eine Freigabe, hat bei kaskadierten FRITZ!Boxen auch gleich noch den Vorteil, daß man in der Ausgabe von "pcplisten" bei NAT für IPv4 die Adresse erhält, bis zu der dank PCP die Freigabe "durchgestellt" werden konnte ... wer also einer kaskadierten Box die "Selbständige Portfreigabe" erlaubt im Edge-Router und dann auf dieser kaskadierten Box das "pcplisten" verwendet, der erhält die externe IP(v4)-Adresse des Edge-Routers in der Bestätigungszeile ... eine ansonsten nur schwer zu ermittelnde Angabe. Bei IPv6 stellt sich die Frage nicht, weil das ja alles öffentliche Adressen sind.

Wenn irgendwann mal ein Provider dann PCP unterstützen sollte, hat man hier auch wieder die IP-Adresse des CGN-Gateways beim Provider ... alles recht einfach, was zuvor relativ kompliziert zu ermitteln war - wenn man erst mal auf PCP umgestellt hat.