/var/flash/ar7.cfg überlebt den reboot nicht

[John Paden]

Hallo,
auf meiner FB7580 läuft schon lange unter Freetz, jetzt Freetz-NG, eine Anzahl von Diensten, auch Apache2.
Da die 7580 kein aktuelles FritzOS mehr bekommt, möchte ich sie durch eine 7590 FritzOS 8.03 FreetzNG ersetzen.
Alles soweit gut und schön. Aber ich bekomme das Portmapping in der ar7.cfg nicht mehr hin.

Gemappt werden soll beispielsweise
http://x.x.x.x:1080 (aussen) -> http://y.y.y.y:180 (innen)
https://x.x.x.x:1443/ -> https://y.y.y.y:543

Aufgeschrieben hatte ich mir

ssh via BusyBox

cat /var/flash/ar7.cfg > /var/media/ftp/usbdevice/ar7.cfg

nano /var/media/ftp/usbdevice/ar7.cfg

statt
voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
"tcp 0.0.0.0:5060 0.0.0.0:5060",
"udp 0.0.0.0:7078+20 0.0.0.0:7078";
voip_ip6_forwardrules = "udp 5060 # SIP", "tcp 5060 # SIP",
"udp 7078-7097 # RTP";
tr069_ip6_forwardrules = "tcp 8089";
dslifaces {

ersetzen durch

voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
"tcp 0.0.0.0:5060 0.0.0.0:5060",
"udp 0.0.0.0:7078+20 0.0.0.0:7078";
voip_ip6_forwardrules = "udp 5060 # SIP", "tcp 5060 # SIP",
"udp 7078-7097 # RTP";
tr069_ip6_forwardrules = "tcp 8089";
internet_in_nat_rules_enabled = yes;
internet_out_nat_rules_enabled = yes;
internet_forwardrules = "tcp 0.0.0.0:1080 0.0.0.0:180",
"tcp 0.0.0.0:1443 0.0.0.0:543";
dslifaces {

und dann

ctlmgr -s; voipd -s; cp /var/media/ftp/usbdevice/ar7.cfg /var/flash/ar7.cfg; reboot

(ohne Reboot kann ich nachvollziehen daß die Änderungen ankommen)

Nur, die Änderungen überleben den Reboot nicht.

Testweise Versuche mit
... ar7cfgchanged; reboot
... modsave flash; modsave all; reboot

haben nichts geändert.

Mir gehts nicht um die Sinnhaftigkeit des Tuns - was mache ich falsch beim wegspeichern der ar7.cfg?
Da es hier im Forum lt Suche seit Jahren kein Thema war, dachte ich, es hat sich nichts geändert?

 

[NanoBot]

Es kann dahinstehen wieso die Änderung der ar7.cfg den reboot nicht überlebt, weil Portforwardings auf die interne IP der Fritz!Box mit dieser Methode bei den neueren Firmwares sowieso nicht mehr funktioniert. Stattdessen muß für diesen Zweck der Befehl pcplisten verwendet werden. Allerdings kann man mit diesem Befehl nur eine Weiterleitung in der Art ExterneIP:1080 auf InterneIP:1080 einrichten. Eine Weiterleitung in der Art von ExterneIP:1080 auf InternteIP:180, wie in deinem Beispiel, ist nicht möglich.

Guck dir mal dieses Freetz-AddOn an: https://freetz-ng.github.io/freetz-ng/make/avm-rules.html, hiermit können die notwendigen Weiterleitungen auf die internte IP der Fritz.Box am einfachsten eingerichtet werden.

 

[NDiIPP]

In Ergänzung dazu:

Da es hier im Forum lt Suche seit Jahren kein Thema war, dachte ich, es hat sich nichts geändert?

https://www.ip-phone-forum.de/threads/fritzbox-als-rustdesk-server.318700/post-2551752
https://www.ip-phone-forum.de/threads/fritzbox-als-rustdesk-server.318700/post-2551824

 

[John Paden]

.. warum die Änderungen (egel welche) den Reboot nicht überleben, verstehe ich trotzdem nicht.
Das Add On probiere ich aus.

 

[PeterPawn]

[…] den Reboot nicht überleben, verstehe ich trotzdem nicht.

Das liegt sicherlich an einem grundlegenden Mißverständnis dessen, wie das FRITZ!OS mit solchen Einstellungen umgeht.

Da wird NICHTS in den existierenden Daten geändert - alles wird jedesmal komplett (in interne Strukturen) eingelesen, intern geändert und dann (i.d.R. auch nicht bei JEDER einzelnen Änderung) wird aus diesen Strukturen jeweils ein komplett neuer(!) Stand der Einstellungsdateien generiert - allerdings für die jeweiligen Dateien getrennt, es ist also KEIN Monolith für alle Einstellungen.

Dabei wird halt nur das "generiert", was auch in der vorhandenen Firmware noch von Bedeutung ist (bzw. wofür die Ausgabe vorgesehen ist) - so ist es eben auch möglich, ältere Einstellungen auf einen neuen Stand zu "migrieren".

Da werden also bei JEDEM neuen Schreiben von Einstellungen all die Änderungen wieder verworfen, für die keine Ausgabe (mehr) vorgesehen ist. Da beim nächsten Start auch jeweils Änderungen an der ar7.cfg vorgenommen werden, erscheint(!) es ggf. so, als hinge das mit dem Neustart zusammen.

Aber man kann sich auch überzeugen, daß das nicht der Fall ist - startet man nach den eigenen Änderungen den ctlmgr neu (den man ja erst mal angehalten hatte, damit der eben beim (späteren) Beenden die vorgenommenen Änderungen nicht sofort wieder mit seinem "internen" Stand überschreibt), dann sind beim nächsten Schreiben (was auch nicht unmittelbar erfolgen muss - das Caching in den Daemons ist aber schon über 10 Jahre implementiert und nicht mehr wirklich neu) die eigenen Änderungen auch komplett ohne Neustart wieder verschwunden, solange sie sich auf alte (und nicht länger genutzte/ausgegebene) Einstellungen beziehen.

 

[John Paden]

Das Add On hat fünktioniert. Danke an @fda77 fürs coden und Euch für die Hinweise.

 

[John Paden]

Sodele, nach ein paar Wochen testphase stelle ich fest, daß diese neue Art des Portforwardings mit dem Add On make/avm-rules.html nicht 100%ig funktioniert.
Für eine Weiterleitung auf den Apache Server habe ich 2 TCP Ports - 1080 und 1443 durchgeleitet.
Timeout der offenen Ports, max 120 [Sekunden]: hier habe ich 110 und 120 Sekunden getestet
Timeout ohne Internetverbindung [Sekunden]: hier habe ich 0 und 60 Sekunden getestet.

Grundsätzlich gehts.... aber manchmal eben nicht.

Freetz - Syslog:
Jun 30 12:22:38 FB7590ourweb kern.notice FREETZ: [AVM-RULES] OK: 10.0.0.20 1080
Jun 30 12:22:38 FB7590ourweb kern.notice FREETZ: [AVM-RULES] OK: 10.0.0.20 1443
Jun 30 12:22:38 FB7590ourweb kern.notice FREETZ: [AVM-RULES] Wasting 110 additional seconds
Jun 30 12:22:38 FB7590ourweb kern.notice FREETZ: [AVM-RULES] Waiting 110 seconds
Jun 30 12:24:29 FB7590ourweb kern.notice FREETZ: [AVM-RULES] OK: 10.0.0.20 1080

Testweise curle ich die Website regelmäßig. Z.B. Mon 30 Jun 12:23:01 CEST 2025 - cam eine Fehlermeldung.
Es kann mit dem 'Wasting...' zu tun haben....
Warum wasted er Sekunden? Mal 1, mal 189, mal 110 ?

Oder was kann ich tun?
Doch einen cronjob auf der Box aufsetzen?

 

[Herbie_2005]

Hm, AVM-rules ist nur für Ipv4-Freigaben. Hat Deine Fritzbox eine externe Ipv4 und eine externe Ipv6? Wenn ja, dann kann eine Anfrage von außen im Prinzip manchmal via Ipv4 und manchmal via Ipv6 ankommen. Das Erstgenannte würde dann durchgestellt, das Zeitgenannte nicht.

Ich bin jetzt aber nicht ganz sicher, ob es daran liegt ...

 

[John Paden]

Hm, AVM-rules ist nur für Ipv4-Freigaben. Hat Deine Fritzbox eine externe Ipv4 und eine externe Ipv6?

Guter Punkt, hatte ich noch nicht drüber nachgedacht - aber nachgesehen. Nein, ich hab Internetseitig 'nur'IP4, und in der Box ist IP6 aus.