AVM-Firewall package für Freetz

olistudent · 6 Feb 2010

@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 · 6 Feb 2010

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 · 6 Feb 2010

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 · 8 Feb 2010

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 · 8 Feb 2010

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

Jörg

hermann72pb · 9 Feb 2010

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 · 9 Feb 2010

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

MaxMuster · 9 Feb 2010

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 · 9 Feb 2010

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 · 9 Feb 2010

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 · 9 Feb 2010

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 · 9 Feb 2010

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

Teste mal bitte mit der stabilen AVM-Firmware gegen.

hermann72pb · 9 Feb 2010

@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 · 9 Feb 2010

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.

Code:

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 · 9 Feb 2010

@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 · 9 Feb 2010

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

MaxMuster · 9 Feb 2010

hermann72pb schrieb:
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 · 9 Feb 2010

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 · 10 Feb 2010

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 · 10 Feb 2010

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?

AVM-Firewall package für Freetz

IPPF-Urgestein

Anhänge

IPPF-Promi

Neuer User

Neuer User

IPPF-Promi

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

IPPF-Promi

IPPF-Promi

IPPF-Promi

Neuer User

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

Neuer User

Statistik des Forums