AVM-Firewall package für Freetz

[olistudent]

@MaxMuster
Kannst du bei Gelegenheit mal den angehängten Patch testen?

Fragen:
1. Warum sind beim avm-firewall Package eigentlich die Knöpfe auf der falschen Seite?
2. Bei mir reicht ein "SIGHUP" um die neuen Regeln einzulesen. Ansonsten bekomm ich auch einen Neustart.
3. Warum wird da der ctlmgr gekillt? Sollte eigentlich nicht nötig sein.

MfG Oliver

 

[MaxMuster]

Mach ich bei Gelegenheit, muss nur gerade weg. Den ctlmgr mussten wir meiner Erinnerung nach wegen der Forwardings killen, sonst klappte das nicht (sagt meine Erinnerung ;-) )

Jörg

 

[joelxy]

Ja die lustige Warnmeldung ...
muss aber sagen, dass ich an der Stelle noch nie einen Reboot hatte und deshalb dort immer so beherzt draufgeklickt hatte.

Joel!

 

[gamon]

Hi,

habe den gleichen Fehler wie Joel & andere - jedesmal nachdem ich eine Forwarding Regel aufsetze und die Settings übernehme, geht die Box in die Werkseinstellungen.

 

[MaxMuster]

... welche Box und welche Firmware?
Im Zweifel mach es dann so, wie Joel: Abspeichern (ohne "Übernehmen-Haken") und danach ein Reboot.

Jörg

 

[hermann72pb]

Ich hatte das zwar gerade irgendwo anders spekuliert, aber kann es sein, dass AVM-Firewall irgendwo cp anstatt cat zum schreiben in ar7.cfg nutzt und dadurch die ar7.cfg zerstört? Das Verhalten mit dem Verschwinden der Telefone etc. entspricht in etwa dem, was im anderen Thread berichtet wurde, nämlich das die entsprechenden character devices für Telefonfilterregel, etc. weg sind.

MfG

 

[RalfFriedl]

Das kann durchaus sein. Also mal eine angepaßte Busybox ausprobieren.

 

[MaxMuster]

Da ich damals scheinbar der "Entdecker" der ersten cp-Probleme war, habe ich peinlich drauf geachtet, dass nicht zu nutzen. Alles wird hier nur per "cat" überschrieben.

Jörg

 

[rAcHe kLoS]

Ich werde den Patch heute testen, ich frag mich dennoch, warum das Problem nicht auftritt wenn man die Änderung macht und die Box manuell direkt im Anschluss neu startet. Entweder wird der dsld zu schnell neu gestartet, oder die neueren dslds aus den aktuellen Firmwares von AMV mögen es nicht wenn man die abwürgt.

 

[MaxMuster]

Beitrag 1:
... könnte auch am ctlmgr liegen, der ebenfalls gestoppt und neu gestartet wird. Ich tappe dabei aber im dunkeln, da das bei den "alten" Boxen (zumindest bei mir) nie auftrat.

Beitrag 2:
So, habe jetzt doch noch kurz getestet (7050 14.04.33), und mir ist einiges wieder klar geworden:

- dsld -I reicht für die Anwendung von Forwardings, aber nicht für die Anwendung von Firewall-Regeln. Dafür braucht man einen Neustart des dsld.
- ctlmgr restarten hatte ich (auch(?)) mit drin, weil geänderte Forwardings sonst nicht in der AVM-GUI erscheinen und jede Änderung dort alle Freetz-Änderungen rückgängig macht

Jetzt ist bei den "sensiblen Boxen" ;-) zu klären, was denn zum Absturz führt, der Neustart des dsld oder des ctlmgr ??? Danach müsste man überlegen, wie man dann (sinnvoll) weiter vorgeht...

Jörg

 

[rAcHe kLoS]

Naja ich kann ja mal testen, was passiert wenn ich von Hand erst den dsld und dann den ctlmgr neu starte. Vielleicht läuft auch irgendein Watchdog von AVM, der dann bei einer bestimmten Aktion die Werkseinstellungen setzt. Ich vermute auch, dass es eher an den neueren Images als an den Boxen selbst liegt, denn ich habe das Problem erst seit dem ich die aktuelle Labor und damit auch Freetz-Trunk verwende.

 

[Silent-Tears]

Vllt ist es auch simpel die LAbor, und nicht Freetz...

Teste mal bitte mit der stabilen AVM-Firmware gegen.

 

[hermann72pb]

@rAcHe kLoS: Watchdog setzt keine Werkseinstellungen. Es könnte aber durchaus passieren, dass in die ar7.cfg-Datei gerade geschrieben wurde, wo watchdog auslöste.

MfG

 

[MaxMuster]

So, scheinbar gefunden, aber ich weiß nicht, was soll das bedeuten...

wenn ich aus dem Skript heraus ctlmgr wieder starte, kommt der so komisch hoch, dass er "/bin/sh /bin/setfactorydefaults" aufruft ?!?!?

Wenn ich hargenau den Inhalt aus der rc.avm-firewall in der Shell ausführe, passiert das aber nicht.

dsld -s
ctlmgr -s
sleep 1
killall -9 dsld 2> /dev/null
killall -9 ctlmgr 2> /dev/null
ctlmgr
[ "$AVM_FIREWALL_LOG_DROPPED" != "yes" ] && LOGG="-n" || LOGG=""
if [ "$AVM_FIREWALL_LOG" == "yes" ]; then
        dsld $LOGG -D AVM_FW 
else 
        dsld $LOGG
fi

Ich kann sogar im Skript noch den ctlmgr stoppen, und dann im telnet wieder starten, kein Problem.

Jörg

 

[hermann72pb]

@MaxMuster: Kann es sein, dass AVM es neuerdings checkt, ob die Datei beschreibar ist und dein Schreibvorgang in ar7.cfg zu dem Zeitpunkt noch nicht abgeschlossen ist? Mach doch da nach dem Schreiben in ar7.cfg eine Pause mit von mir aus 1-2 Sekunden. Wenn es was bringt, dann könnte man in die Richtung weiterbohren.
Es muss nicht unbedingt genau das sein, was ich vermute, könnte aber schon etwas Ähnliches "dynamisches" sein.

MfG

 

[rAcHe kLoS]

Wäre zumindest ein Ansatz, denn wenn ich von der Shell aus die Sache ausführe knallt es nicht.

 

[MaxMuster]

Mach doch da nach dem Schreiben in ar7.cfg eine Pause mit von mir aus 1-2 Sekunden.

So weit war ich auch schon... ;-) Hat leider nix verändert.

Mal sehen, vielleicht kann man dazu ja pkg_post_save() noch irgendwie nutzen...


Jörg

 

[olistudent]

Was hast du denn genau ausgeführt? Ich hab die Zeilen von oben in ein Skript gepackt. Wenn ich das ausführe kann ich kein setfactorydefaults beobachten.

MfG Oliver

 

[hermann72pb]

Leute, sollen wir vielleicht AVM-Firewall-CGI vorübergehend Richtung instabile Pakete verschieben? Das Verhalten ist ziemlich übel und es fallen scharrenweise Neulinge dadrauf, wie man den letzten Meldungen in diesem Unterforum entnehmen kann. Man kann sich natürlich darauf berufen, dass trunk generell instabil ist und dass das Lesen bekanntlich bildet, damit wird aber keinem geholfen und wir haben uns einen neuen TOP1 eingefangen, der die SSL-bedingten Nachfragen noch übertreffen könnte.

MfG

 

[gamon]

Auch wenn es mir vom Fachwissen her nicht zusteht würde ich hermann72pb da voll zustimmen. Auch eine Anmerkung zu seinem Post - rtfm ist keine Kür, es ist Pflicht, stimmt.

Wenn man jedoch im Freetz trac unter http://trac.freetz.org/wiki/packages/avm-firewall-cgi schaut, wird nicht ersichtlich das dieses Paket so seine Fehler"chen" hat. Noch weniger wird ersichtlich das es zum trunk Zweig gehört (von dem ich ausgehe das es wie bei linux distributionen ähnlich einen Zweig neben stable und anderen darstellt, berichtigt mich wenn ich da falsch liege) - zumindest wenn man sich wie ich erstmal speed2fritz bedient hat(welches keine aussage über die einzelnen Branches trifft).

Jetzt muss ich wieder ne neue FW bauen und nehm dann doch iptables rein...


PS.: Wenn ich das richtig verstanden hab, wirken die AVM-Firewall und iptabels dann kaskadiert. Somit muss die AVM - Fwall ebenfalls passend
administriert werden - wo macht man das in Anbetracht der Tatsache das AVM-firewall-cgi momentan nicht richtig benutzbar ist?