AVM-Firewall package für Freetz

[MaxMuster]

Was hast du denn genau ausgeführt?

Ich habe während des Ausführens des rc-Skriptes ein paar "ps" gemacht und dabei gesehen, dass "setfactorydefaults" lief.

Mit ein paar greps fand ich diesen String nur im ctlmgr und habe dann das Stoppen und Starten davon rausgenommen. Kein Reboot mehr.

Daraufhin habe ich alles Mögliche versucht, was mir einfiel, um das zu verhindern:
Erst den dsld wieder gestartet, und dann den Restart des ctlmgr: Keine Besserung
nach dem Stoppen des ctlmgr erst dsld gestartet, dann ctlmgr: Keine Besserung
diverse "sleeps" eingebaut: Keine Besserung
Die ctlmgr-Befehle in ein anderes Skript ausgelagert: auch nicht besser.

Genauso wie du habe ich die ganze Befehlskette auch in ein eigenes Skript gepackt: Keine Probleme "für sich", nur, wenn sie vom rc-File aufgerufen werden: Reboot

Mir fehlen echt die Ideen...


@gamon, hermann:
Auch wenn es schwerfällt, man sollte die User vor sich selbst schützen ;-). Eigentlich denke ich, fehlt eher oft das "erst Denken". Wenn ich auf meinem PC ein Programm starte, wo steht: Vorsicht, kann zum Reboot führen, kann ich mich dann über Datenverluste beschweren, wenn der nicht "sauber" runtergefahren wurde?
Egal, meine Meinung:
Entweder den "Übernehmen" Haken rausmachen, dann ist ein Reboot zwingend und/oder dazuschreiben, dass jede Änderung in der AVM-GUI, die man danach durchführt und die ar7.cfg beschreibt die Änderungen wieder löscht...

Trotzdem müsste die ctlmgr Geschichte doch irgendwie zu lösen sein.

Jörg

 

[Silent-Tears]

MAn sollte den ctlmgr bei exakt diesem Aufruf mal tracen...

 

[MaxMuster]

Der erste Aufruf scheint es nicht zu sein. Ein strace davor zeigt nichts besonderes gegenüber dem "problemlosen" Aufruf aus der Shell.
Aber der ctlmgr startet ja immer mehrere Instanzen, und dann scheint es die Probleme zu geben. Den einzigen Unterschied, den ich fand und der nicht zusätzlich gesuchte libs in "/mod/usr/lib" oder verschiedene Timestamps waren ist:

(aus einem Diff der beiden, diff -Nur ctlmgr_shell.txt ctlmgr_cgi.txt )

@@ -373,9 +435,9 @@
 mprotect(0x2ad8a000, 4096, PROT_READ)   = 0
 mprotect(0x2aabc000, 4096, PROT_READ)   = 0
 mprotect(0x2ab68000, 171044, PROT_READ|PROT_EXEC) = 0
[B]-ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
-ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0[/B]
-getpid()                                = 821
[B]+ioctl(0, TIOCNXCL, 0x7ff75f38)          = -1 EINVAL (Invalid argument)
+ioctl(1, TIOCNXCL, 0x7ff75f38)          = -1 EINVAL (Invalid argument)[/B]
+getpid()                                = 1187
 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=0}) = 0
 setrlimit(RLIMIT_STACK, {rlim_cur=2040*1024, rlim_max=0}) = 0
 rt_sigaction(SIGRT_0, {SIG_DFL, [], SA_STACK|SA_INTERRUPT|SA_NOCLDWAIT|0x2ca2da4}, NULL, 16) = 0
@@ -388,21 +450,20 @@

Jörg

 

[RalfFriedl]

Im ersten Fall ist er mit dem Terminal verbunden, im zweiten vermutlich mit /dev/null. Das sollte aber nicht weiter wichtig sein.

Hast Du strace mit der Option -f aufgerufen (benötigt replace Kernel)? Ansonsten siehst Du nur die erste Instanz.

 

[MaxMuster]

Habe ich nicht. Replace kernel ist bei der Box/FW (W701V mit dem 7170-er Preview) nicht möglich.

Jörg

 

[RalfFriedl]

Wenn der ctlmgr erstmal läuft, kannst Du Dich auch nachträglich dranhängen:

strace -p xx -p yy ...

oder

strace $(for i in $(pidof ctlmgr); do echo -p $i; done)

 

[MaxMuster]

... damit scheine ich etwas mehr Infos zu bekommen, die auch weitergehen bis zum Reboot.

Falls sich das mal jemand mit Ahnung ansehen könnte?!?

Jörg

Edit: Das ganze muss irgendwie mit der freetz-Umgebung zusammenhängen?!?
Ich kann das Verhalten ebenfalls provozieren, wenn ich in der Rudi-Shell eingebe:

ctlmgr -s ; sleep 1 ; ctlmgr

Edit2: Es reicht für das Verhalten sogar den ctlmgr im Telnet zu stoppen, das Starten des ctlmgr aus der Rudishell rebootet die Box!

 

[RalfFriedl]

Sieht aus, als würde der ctlmgr hier gezielt die Konfiguration löschen und dann /sbin/reboot aufrufen.

Versuch mal, bevor Du den ctlmgr aufrufst, das gesicherte Environment wiederherzustellen:

. /var/env.cache; ctlmgr

 

[MaxMuster]

In der Rudi-Shell geht es, im rc-file habe ich es nicht hinbekommen...

ABER ;-) es geht, wenn ich die ctlmgr-Dinge im rc-file lösche und dieses Datei als "avm-firewall.save" nutze:

/var/mod/root # cat  /mod/etc/default.avm-firewall/avm-firewall.save 
pkg_post_save()
{
        [ -f /mod/etc/conf/avm-firewall.cfg ] && . /mod/etc/conf/avm-firewall.cfg
        if [ "$AVM_FIREWALL_DO_ACTIVATE" == "yes" ]; then 
                echo -n "Restarting ctlmgr ... "
                ctlmgr -s 
                echo -n "ctlmgr stopped ... " 
                sleep 1 
                . /var/env.cache
                ctlmgr 2>&1
                echo "ctlmgr startet" 
        fi 
}
/var/mod/root #

Stört das denn irgendetwas anderes, wenn ich an dieser Stelle /var/env.cache lade??


Jörg

 

[RalfFriedl]

Stören sollte es nicht, aber warum geht das Gleiche in der rc-Datei nicht?

 

[MaxMuster]

... keine Ahnung, vielleicht hatte ich da auch noch nen Fehler drin.

Hier mal eine Testversion, die zum einen die Wahl lässt, was genau gestartet wird und zum anderen den ctlmgr in der genannten Art neu startet.

Bei mir gingen so alle Variationen ohne Reboot, falls es noch andere mutige gibt, wäre ich dankbar!


Jörg

 

[hermann72pb]

Ich würde vorschlagen, dass man nach 2-3 Erfolgsmeldungen hier diesen Patch möglichst schnell in den trunk übernehmen sollte. Zwar wirken die vier Auswahlmöglichkeiten etwas verwirrend und bedürfen einer Erklärung (vor allem für Newbees), aber zu Test/Debugzwecken ist es auf jeden Fall besser als genug. Wenn sich danach daraus 2 "beste" Varianten herausfiltern, dann hat man gewonnen, oder es wird eben eine andere Lösung gefunden.

MfG

 

[rAcHe kLoS]

Also bei mir geht es mit dem Patch auch, wobei der Fehler wohl tatsächlich daher kommt, dass die Umgebungsvariablen nicht gesetzt sind.

Rufe ich z.b. ein Shellscript mit export auf, liefert er mir auch nur die Umgebungsvariablen der httpd Umgebung.

 

[hermann72pb]

Es gab vor Kurzem eine Änderung dazu im trunk, dass die AVM-Umgebungsvariablen nicht mehr zur Verfügung stehen. Ich weiß nicht warum und wieso und wo genau, Oliver weiß da mehr dazu bescheid. Denn er hatte mich dazu ausgefragt, ob ich denn damit einverstanden wäre, dass diese Umgebungsvariablen in meiner BOX-Info explizit aufgerufen werden. Denn dort benutze ich sie z.B. Wie Oliver das letztendlich gelöst hat, weiß ich nicht mehr. Schaut bitte in die box-info.cgi im Trunk, vielleicht werdet ihr dann fündig. Vielleicht kann man es genau so in der avm-firewall.cgi realisieren.

Edit:

http://trac.freetz.org/browser/trunk/root/usr/lib/cgi-bin/mod/box_info.cgi

Zeile 6.


MfG

 

[olistudent]

Ralf hat das hier auch schon ein paar Posts vorher beschrieben. Ich hatte diese Änderung eingebaut, da ich keinen anderen Weg gefunden habe, dass die Firewall GUI eine von den anderen Seiten abweichende Breite hat. Lustig, dass jetzt gerade dieses Paket dadurch ein Riesenproblem bekommen hat.

MfG Oliver

 

[MaxMuster]

@Oliver: Genau das war meine erste Reaktion ;-). Mir ist noch nicht ganz klar, bei welchen Firmwares das Phänomen überhaupt auftritt, da wäre Feedback nett.

Die vier Optionen würde ich natürlich nicht immer drin lassen, wollte aber gern in dieser Version die Möglichkeit haben, alles einzeln zu testen.

Vielleich sollten wir in den Stable-Zweig eine Version einbauen, wo man den Haken nicht setzen kann mit dem Hinweis:
Zum Übernehmen: Speichern, nix in der AVM-GUI machen und sofort rebooten.

Ich sehe die größte Herausforderung in dem Spagat zwischen Erwartung und Realität:
Es reicht ein HUP an den dsld zu schicken und die Forwarding-Regeln werden angewandt. Erwartung: alles ist "gesichert und läuft". Eine darauf folgende Änderung in der AVM-GUI verwirft danach aber alle neuen Einträge, Forwardings und auch FW-Regeln. Unschön. Um das zu umgehen, müsste der ctlmgr neu gestartet werden (der reagiert nicht auf ein HUP). Das allein aber wendet die Regeln nicht an. Zum Anwenden muss der dsld "geHUPt" werden für die Forwardings bzw. restartet für die Firewall-Regeln und die Logging-Schalter.

Ich denke, den ctlmgr neu zu starten ist deshalb unumgänglich. Beim dsld bin ich unsicher...

Jörg

 

[Silent-Tears]

Wie wäre es, üblerweiose erst einmal einen Reboot zu forcieren? Dann sollten wir auf der sicheren Seite sein, oder?

 

[olistudent]

Was macht denn AVM in diesem Fall? Also bei Eingabe neuer Firewall Regeln?

MfG Oliver

 

[MaxMuster]

Den Fall gibt es nicht, das ist ja der Grund für die GUI . Die AVM-FW ist statisch, zumindest soweit ich das weiß.

Jörg

 

[RalfFriedl]

Aber es muß einen Weg geben, dem ctlmgr mitzuteilen, daß sich die ar7.cfg geändert hat. Oder macht der alle Änderungen selbst?