[NEU] schnelles iptables / ip6tables interface für die 7270 (v.0.8.3a) + 7390 etc...
- Ersteller cando
- Erstellt am
hermann72pb
IPPF-Promi
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,726
- Punkte für Reaktionen
- 16
- Punkte
- 38
Dann könnte man nachher überlegen, ob man dein Paket dann unter menuconfig hart von autostart.sh abhängig erklärt, sodass autostart.sh dann automatisch ausgewählt wird, sobald dein Paket augewählt ist. autostart.sh erfordert allerdings automount, wenn ich es richtig überblicke. Also da wird sich eventuell einen Ratenschwanz hinterher ziehen. Nicht dass ich sagen will, dass man diese automount-Sachen nicht sowieso braucht, ganz in Gegenteil. Es sollten aber angeblich Leute geben, die es nicht haben wollen. Aber dann sind sie eben selbst schuld...
Meine Frage am Rande: Kann man AVM-Firewall denn irgendwie deaktivieren, oder wenigstens so konfigurieren, dass sie alles durchlässt? Denn zwei Firewalls zu warten ist wirklich so eine Sache. Noch besser wäre in diesem Zusammenhand den dsld von AVM rauszupatchen und gegen etwas Eigenes zu ersetzen. Dann hätte man das Problem gelöst. Ich glaube, hier gab es bereits Bewegungen in die Richtung den dsld zu ersetzen. Ich weiß allerdings nicht, ob es jemand noch weiter verfolgt.
MfG
Meine Frage am Rande: Kann man AVM-Firewall denn irgendwie deaktivieren, oder wenigstens so konfigurieren, dass sie alles durchlässt? Denn zwei Firewalls zu warten ist wirklich so eine Sache. Noch besser wäre in diesem Zusammenhand den dsld von AVM rauszupatchen und gegen etwas Eigenes zu ersetzen. Dann hätte man das Problem gelöst. Ich glaube, hier gab es bereits Bewegungen in die Richtung den dsld zu ersetzen. Ich weiß allerdings nicht, ob es jemand noch weiter verfolgt.
MfG
dsld rauspatchen ginbge wohl, aber die Fireallsachen auszustellen ist denke ich ohne das nicht möglich. Eigene Lösung ist machbar, besagen die Bemühungen, aber dann ist zumindest viop nohc nicht gelöst, denke ich, und da komtm dann der Rattenschwanz an Problemen hinterher.
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Die AVM Firewall ist ja von Haus aus in allen Richtungen offen, wenn man nichts dagegen unternimmt (default PERMIT). Das einzige, was sie blockt sind 2 NETBios broadcast Addressen. Aus dem Internet scheitert man nur am NAT, wenn kein Portmapping eingestellt ist, durch Connection Tracking wird alles automatisch durchgelassen, was von innen initialisiert wird.
Insofern ist sie so gut wie keine Hürde bei gleichzeitiger Nutzung von iptables, ausser man nutzt und konfiguriert ganz bewusst beide FW's.
Die Abhängigkeiten würde ich nicht so hart setzen. Das Risiko ist vergleichsweise gering, dass man sich derart aussperrt (wenn man nicht manuell die Bootfiles bearbeitet), und gleich hoch mit normalen shell-iptables Konfigurationen.
Ich habe gerade den neuesten Stand des cgi für die Testwilligen hochgeladen mit vielen neuen Funktionen, wie Unterstützung fast aller Targets, aller Tabellen (filter, nat, mangle, raw). etc.
Das Testen ist etwas langwierig, da bei so vielen möglichen Parametern der Aufwand exponentiell steigt. In meiner Konfiguration kann ich alle meine Regeln vom UI aus setzen. Bei Exotischeren Konfigurationen bitte mal die Regeln schicken, die nicht direkt gesetzt werden können. Ich schau dann mal, wie man die auch noch rein bekommt
Für Hinweise zur Verbesserung bin ich natürlich dankbar.
Die Beschreibung aktualisiere ich auf der 1. Seite...
[EDIT 02.11.09-17:31] Airbag CGI optional als Script zum Ausprobieren (siehe oben).
2 Betriebsarten:
- Unsafe Admin - Admin kann alles,
- Safe Admin - die CGI verwaltet selbst alle relevanten Top-1 Regeln für den Admin Zugang
(raw-PREROUTING -> mangle-PREROUTING -> nat->PREROUTING -> mangle->INPUT -> filter-INPUT -> FRITZBOX -> raw-OUTPUT -> mangle-OUTPUT -> nat-OUTPUT -> filter-OUTPUT-> mangle-POSTROUTING -> nat-POSTROUTING )
Fehlende Regeln werden bei Bedarf eingefügt, sie gelten nur für die registrierte Admin-IP.
Es werden nur Regeln für die aktivierten Module generiert (wenn z.B nur filter aktiv ist, gibt's nur INPUT und OUTPUT).
Insofern ist sie so gut wie keine Hürde bei gleichzeitiger Nutzung von iptables, ausser man nutzt und konfiguriert ganz bewusst beide FW's.
Die Abhängigkeiten würde ich nicht so hart setzen. Das Risiko ist vergleichsweise gering, dass man sich derart aussperrt (wenn man nicht manuell die Bootfiles bearbeitet), und gleich hoch mit normalen shell-iptables Konfigurationen.
Ich habe gerade den neuesten Stand des cgi für die Testwilligen hochgeladen mit vielen neuen Funktionen, wie Unterstützung fast aller Targets, aller Tabellen (filter, nat, mangle, raw). etc.
Das Testen ist etwas langwierig, da bei so vielen möglichen Parametern der Aufwand exponentiell steigt. In meiner Konfiguration kann ich alle meine Regeln vom UI aus setzen. Bei Exotischeren Konfigurationen bitte mal die Regeln schicken, die nicht direkt gesetzt werden können. Ich schau dann mal, wie man die auch noch rein bekommt
Für Hinweise zur Verbesserung bin ich natürlich dankbar.
Die Beschreibung aktualisiere ich auf der 1. Seite...
[EDIT 02.11.09-17:31] Airbag CGI optional als Script zum Ausprobieren (siehe oben).
2 Betriebsarten:
- Unsafe Admin - Admin kann alles,
- Safe Admin - die CGI verwaltet selbst alle relevanten Top-1 Regeln für den Admin Zugang
(raw-PREROUTING -> mangle-PREROUTING -> nat->PREROUTING -> mangle->INPUT -> filter-INPUT -> FRITZBOX -> raw-OUTPUT -> mangle-OUTPUT -> nat-OUTPUT -> filter-OUTPUT-> mangle-POSTROUTING -> nat-POSTROUTING )
Fehlende Regeln werden bei Bedarf eingefügt, sie gelten nur für die registrierte Admin-IP.
Es werden nur Regeln für die aktivierten Module generiert (wenn z.B nur filter aktiv ist, gibt's nur INPUT und OUTPUT).
Zuletzt bearbeitet:
Nach "persist rules" findet sich in der nhipt.cfg im Abschnitt ###FIREWALL### folgende Zeile:
Einzige Rule: iptables -A INPUT -s 192.168.178.20/32 -j ACCEPT
Wozu wird ar7.cfg in /var/tmp/ geschrieben? Zugriffe auf die heilige ar7.cfg sind mir immer ein bißchen unheimlich, vor allem dann, wenn sie nicht von mir selbst stammen ;-)
Code:
cat /var/flash/ar7.cfg > /var/tmp/ar7.cfgEinzige Rule: iptables -A INPUT -s 192.168.178.20/32 -j ACCEPT
Wozu wird ar7.cfg in /var/tmp/ geschrieben? Zugriffe auf die heilige ar7.cfg sind mir immer ein bißchen unheimlich, vor allem dann, wenn sie nicht von mir selbst stammen ;-)
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Sorry, mach ich noch raus. Ich kopiere immer die ar7.cfg und die debug.cfg nach /var/tmp, damit ich sie mir dort bei Bedarf anschauen / editieren kann.
Ich schreibe sie nicht automatisch zurück in den flash. Hat mit dem cgi so gar nichts zu tun, war nur eine Comfort Funktion, wenn man mal was sucht.
[EDIT] Die Zeile ist schon Raus aus den Paketen, ich habe die neue Version hochgeladen.
Neue Funktionen:
- Nach Reboot wird der httpd mit User / Passwort geschützt (gleiche Kennung / Vorgehensweise wie beim freetz UI)
- Die "Airbag" Funktion wider des Aussperrens ist nun über Radiobuttons gelöst und integriert.
- Die Boot-Delay Funktion ist konfigurierbar (aus, 30s ... 10min)
- Während des Delays kann optional der dsld gestoppt und danach wieder gestartet werden.
Das muss noch ausgiebig getestet werden, da ich noch nicht weiss, ob der dsld zum Bootzeitpunkt überhaupt schon oben ist und sich stoppen lässt.
- beim Starten des CGI wird geprüft, ob im wwwroot Verzeichnis des CGI' eine default.html existiert und notfalls eine solche erzeugt. Sinn der Sache ist es, die UI auch direkt z.B. mit http://fritz.box:83 aufrufen zu können.
Ich denke, das sollte an Vorkehrungen zum Schutze von Administratoren vor sich selbst ausreichen. Der Code dafür wird sonst in Relation zur Nutzanwendung unverhältnismäßig.
Ich schreibe sie nicht automatisch zurück in den flash. Hat mit dem cgi so gar nichts zu tun, war nur eine Comfort Funktion, wenn man mal was sucht.
[EDIT] Die Zeile ist schon Raus aus den Paketen, ich habe die neue Version hochgeladen.
Neue Funktionen:
- Nach Reboot wird der httpd mit User / Passwort geschützt (gleiche Kennung / Vorgehensweise wie beim freetz UI)
- Die "Airbag" Funktion wider des Aussperrens ist nun über Radiobuttons gelöst und integriert.
- Die Boot-Delay Funktion ist konfigurierbar (aus, 30s ... 10min)
- Während des Delays kann optional der dsld gestoppt und danach wieder gestartet werden.
Das muss noch ausgiebig getestet werden, da ich noch nicht weiss, ob der dsld zum Bootzeitpunkt überhaupt schon oben ist und sich stoppen lässt.
- beim Starten des CGI wird geprüft, ob im wwwroot Verzeichnis des CGI' eine default.html existiert und notfalls eine solche erzeugt. Sinn der Sache ist es, die UI auch direkt z.B. mit http://fritz.box:83 aufrufen zu können.
Ich denke, das sollte an Vorkehrungen zum Schutze von Administratoren vor sich selbst ausreichen. Der Code dafür wird sonst in Relation zur Nutzanwendung unverhältnismäßig.
Zuletzt bearbeitet:
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
*push*
Ich habe 2 Bugs gefixt und eine neue Version hochgeladen.
1.) der crond wird beim Boot und bei start logging umkonfiguriert, damit er nicht den Syslog vollschreibt. Es empfiehlt sich, den cron nicht vom freetz aus zu starten, da dann wieder der Log vollgeschrieben wird. Man bräuchte einen Patch für die freetz Einstellungen, mit 2-3 Radiobuttons:
bei der man die Logeinstellungen vom crond setzen kann:
a) syslog cron -b
b) file + (Eingabefeld für Pfad & Dateiname) cron -b -L path_to_file
c) ganz aus (wie File, nur mit /dev/null vorbelegt) cron -b -L /dev/null
Ausserdem wäre es sehr schön, wenn freetz beim Starten der Dienste (z.B. des crond) prüft, ob die vielleicht schon laufen, und das Starten dann sein lässt.
(noch besser wäre, wenn er nur eigene Dienste abschießen würde beim Stop / Restart über die PID, anstatt mit der großen Kelle alles platt zu machen, was so heißt.).
2.) Meine Änderung mit der Verwendung vom freetz Login hatte noch einen Bug beim Kaltstart, der nun gefixt ist (Passwortdatei fehlte beim Booten)
Wer das Interface testet, sollte sich die neueste Version oben ziehen.
Viele Grüße
cando
Ich habe 2 Bugs gefixt und eine neue Version hochgeladen.
1.) der crond wird beim Boot und bei start logging umkonfiguriert, damit er nicht den Syslog vollschreibt. Es empfiehlt sich, den cron nicht vom freetz aus zu starten, da dann wieder der Log vollgeschrieben wird. Man bräuchte einen Patch für die freetz Einstellungen, mit 2-3 Radiobuttons:
bei der man die Logeinstellungen vom crond setzen kann:
a) syslog cron -b
b) file + (Eingabefeld für Pfad & Dateiname) cron -b -L path_to_file
c) ganz aus (wie File, nur mit /dev/null vorbelegt) cron -b -L /dev/null
Ausserdem wäre es sehr schön, wenn freetz beim Starten der Dienste (z.B. des crond) prüft, ob die vielleicht schon laufen, und das Starten dann sein lässt.
(noch besser wäre, wenn er nur eigene Dienste abschießen würde beim Stop / Restart über die PID, anstatt mit der großen Kelle alles platt zu machen, was so heißt.).
2.) Meine Änderung mit der Verwendung vom freetz Login hatte noch einen Bug beim Kaltstart, der nun gefixt ist (Passwortdatei fehlte beim Booten)
Wer das Interface testet, sollte sich die neueste Version oben ziehen.
Viele Grüße
cando
Zuletzt bearbeitet:
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Klar, es liest die aktuellen Rules direkt aus und schreibt Änderungen direkt.
Es arbeitet nicht mit Dateien oder so.
Das Einzige, was an Dateien benötigt wird ist für den Bootvorgang bestimmt, damit man die Regeln über einen Reboot weg beibehalten kann.
Es arbeitet nicht mit Dateien oder so.
Das Einzige, was an Dateien benötigt wird ist für den Bootvorgang bestimmt, damit man die Regeln über einen Reboot weg beibehalten kann.
Klasse wäre noch, wenn man die Rules auch inhaltlich ändern könnte: z.B. bei multiport noch einen Port hinzufügen. Bisher gibt es ja in der Spalte "Edit" lediglich [UP] [DN] [Del], ein "echtes" Editeren wäre sehr praktisch.
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Ich werde mal darüber nachdenken, wie man das lösen kann. Ich wollte nicht zu viele Eingabefelder haben (wie bei der AVM Firewall), weil es da unübersichtlich wird, wenn man mehrere Regeln gleichzeitig editiert. Bei manchen Änderungen scheiterts dann vielleicht an der Syntax und man hat sich schnell ausgesperrt.
Mit dem UI kann man immer nur eine Regel eingeben oder verändern, was die Sache viel sicherer macht. Ich könnte aber bei Edit die betreffende Regel in die "Experten"-Zeile laden, damit man sie dort bearbeiten kann. Es gibt ja auch ein Schalter bei iptables zum Ändern / ersetzen einer Regel.
Ich überlege mir noch was...
Danke für den Hinweis.
(Bisher editiere ich meine Regeln, indem ich eine Neue an die stelle einfüge mit insert und wenn es passt, die alte lösche)
Ich habe die Log Prozeduren entschärft.
Mit der alten Version bestand die Gefahr, dass wenn der Logdeamon läuft und jemand über die Konsole oder freetz den cron job für die Nachverarbeitung löscht oder den crond stoppt, die Puffer-Datei in der RAM-Disk immer weiter wächst, da sie nicht mehr verarbeitet wird. Das kann nach viel DECT telefonieren irgendwann dazu führen, dass die Box rebootet. Danach heilt sich das System selbst (cron wird gestartet, fehlender Eintrag wiederhergestellt).
Das ist aber natürlich nicht akzeptabel.
Ich habe deshalb einen eigene Mini-Deamon geschrieben und in das Paket integriert, der auf den Log-Prozess "aufpasst" und alle 15 sekunden den Puffer verarbeitet. Die Systemlast, die er zusätzlich erzeugt ist minimal, der cron wird nicht mehr gebraucht. Wenn der Log-Prozess beendet wird, verabschiedet sich der deamon auch. Es wird auch verhindert, dass der Logprozess ohne de Watchdog starten kann oder doppelt gestartet wird.
Die neue Version ist nun online. Wenn Ihr die aufspielt und mit der alten bereits gespielt habt, dann solltet ihr den alten cron job löschen, damit er nicht mehr unnötig den syslog vollschreibt.
Viele Grüße
cando
Mit dem UI kann man immer nur eine Regel eingeben oder verändern, was die Sache viel sicherer macht. Ich könnte aber bei Edit die betreffende Regel in die "Experten"-Zeile laden, damit man sie dort bearbeiten kann. Es gibt ja auch ein Schalter bei iptables zum Ändern / ersetzen einer Regel.
Ich überlege mir noch was...
Danke für den Hinweis.
(Bisher editiere ich meine Regeln, indem ich eine Neue an die stelle einfüge mit insert und wenn es passt, die alte lösche)
Ich habe die Log Prozeduren entschärft.
Mit der alten Version bestand die Gefahr, dass wenn der Logdeamon läuft und jemand über die Konsole oder freetz den cron job für die Nachverarbeitung löscht oder den crond stoppt, die Puffer-Datei in der RAM-Disk immer weiter wächst, da sie nicht mehr verarbeitet wird. Das kann nach viel DECT telefonieren irgendwann dazu führen, dass die Box rebootet. Danach heilt sich das System selbst (cron wird gestartet, fehlender Eintrag wiederhergestellt).
Das ist aber natürlich nicht akzeptabel.
Ich habe deshalb einen eigene Mini-Deamon geschrieben und in das Paket integriert, der auf den Log-Prozess "aufpasst" und alle 15 sekunden den Puffer verarbeitet. Die Systemlast, die er zusätzlich erzeugt ist minimal, der cron wird nicht mehr gebraucht. Wenn der Log-Prozess beendet wird, verabschiedet sich der deamon auch. Es wird auch verhindert, dass der Logprozess ohne de Watchdog starten kann oder doppelt gestartet wird.
Die neue Version ist nun online. Wenn Ihr die aufspielt und mit der alten bereits gespielt habt, dann solltet ihr den alten cron job löschen, damit er nicht mehr unnötig den syslog vollschreibt.
Viele Grüße
cando
Zuletzt bearbeitet:
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Editieren von Regeln
Hallo Alpha1974, Dein Wunsch wurde erhört, neue Version oben zum Download bereit.
Hallo Alpha1974, Dein Wunsch wurde erhört, neue Version oben zum Download bereit.
Ich habe noch eine weitere Anregung: Der ganze Logging-Krempel wird nicht von jedem benötigt, nimmt aber eine Menge Platz weg (u.a. in nhipt.cfg). Es wäre daher prima, wenn es im Interface die Option gäbe, eine debug.cfg/nhipt.cfg ohne Erstellung von logfw.sh und iptlogger.sh zu erzeugen (also nur Start des httpd und ###FIREWALL###-Sektion).
BTW: Was genau soll eigentlich geloggt werden? Auf meiner 7170 mit Freetz/Syslogd steht alles Wesentliche im Syslog. Dorthin schreibt auch iptables die Meldungen über die entsprechenden "-j LOG" Rules. Mir reicht das.
BTW: Was genau soll eigentlich geloggt werden? Auf meiner 7170 mit Freetz/Syslogd steht alles Wesentliche im Syslog. Dorthin schreibt auch iptables die Meldungen über die entsprechenden "-j LOG" Rules. Mir reicht das.
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Firewall Log
Bei der 7270 und andere DECT-Modelle hat AVM den printk verbogen, um debugausgaben nach /dev/debug zu erzeugen. Bei diesen Boxen ist der syslog nutzlos.
Es gab mal einen Patch voriges Jahr für die Box, der hat es aber verschlimmert. Dann ging der ganze DECT Part nicht mehr richtig, weil die Meldungen den Syslog geflutet haben und die DECT Module timing Probleme bekamen. Geräte konnten nicht an der Basis angemeldet werden, Gespräche wurden abgebrochen etc.
Meine Log Mimik fängt diese Umleitung performant ab und wertet das Ganze im Hintergrund aus.
Gestern habe ich erfahren, dass cuma einen funktionierenden Patch für dieses Problem erstellt hat. Muss ich aber erst noch testen. Ich werde eine Option einbauen, ob man den eigenen Deamon oder den syslogd für das Loggen verwenden will.
Ich hatte das Interface ja vorrangig für die DECT Boxen 7270 etc. gebaut, die dieses Problem haben.
(Bei der 7170 wird das Loggen mit meiner Methode wahrscheinlich gar nicht funktionieren, da AVM vermutlich da nicht den printk umleitet.)
Bei der 7270 und andere DECT-Modelle hat AVM den printk verbogen, um debugausgaben nach /dev/debug zu erzeugen. Bei diesen Boxen ist der syslog nutzlos.
Es gab mal einen Patch voriges Jahr für die Box, der hat es aber verschlimmert. Dann ging der ganze DECT Part nicht mehr richtig, weil die Meldungen den Syslog geflutet haben und die DECT Module timing Probleme bekamen. Geräte konnten nicht an der Basis angemeldet werden, Gespräche wurden abgebrochen etc.
Meine Log Mimik fängt diese Umleitung performant ab und wertet das Ganze im Hintergrund aus.
Gestern habe ich erfahren, dass cuma einen funktionierenden Patch für dieses Problem erstellt hat. Muss ich aber erst noch testen. Ich werde eine Option einbauen, ob man den eigenen Deamon oder den syslogd für das Loggen verwenden will.
Ich hatte das Interface ja vorrangig für die DECT Boxen 7270 etc. gebaut, die dieses Problem haben.
(Bei der 7170 wird das Loggen mit meiner Methode wahrscheinlich gar nicht funktionieren, da AVM vermutlich da nicht den printk umleitet.)
Auf der 7170 mit (gut funktionierendem) syslogd gibt es also eigentlich gar keinen Bedarf für eine iptable-spezifische Logging-Funktion. Ein Grund mehr für einen Schalter in Deinem Interface, um alles, was mit logging zu tun hat, komplett zu entfernen
Wer Bedarf für Log-Rules hat, kann diese ja über die Experten-Zeile einfügen und die Meldungen über Freetz/syslogd anschauen (jedenfalls auf der 7170 und allen anderen Boxen, bei denen der syslogd problemlos läuft). Diese 7270-spezifische Verknüpfung zwischen iptables und logging wirst Du sowieso aufgeben müssen, wenn Dein Interface in Freetz integriert wird und auf allen Boxen laufen soll ;-)
Wer Bedarf für Log-Rules hat, kann diese ja über die Experten-Zeile einfügen und die Meldungen über Freetz/syslogd anschauen (jedenfalls auf der 7170 und allen anderen Boxen, bei denen der syslogd problemlos läuft). Diese 7270-spezifische Verknüpfung zwischen iptables und logging wirst Du sowieso aufgeben müssen, wenn Dein Interface in Freetz integriert wird und auf allen Boxen laufen soll ;-)
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
hallo alpha1974
Ich habe eine neue "alpha" Version hochgeladen mit einem syslogd - Schalter. Bitte mal testen (05.11-02).
Da das Ding in verschiedenen Modulen eingreift, habe ich die stabile Alte noch zum Download belassen. Bis zur Integration wird es noch ein wenig dauern, ausserdem tut die Log-Mimik keinem weh, sie tut ja nichts, wenn nichts über /dev/debug herauspurzelt. Insofern ist das Interface ja auf jeder Linux Kiste theoretisch lauffähig.
Was die abweichenden Kernel-Module angeht, habe ich bislang keine Info. Das UI sichert aber grundsätzlich alle geladenen IPTables Module für den Restart, so dass man mit einem einigen manuellen modprobe und dem anschließenden Speichern der Regeln auch solche Themen vom Tisch bekommt. Übrigens, LOG Rules gehen auch im normalen Interface, da braucht man keine Experten - Eingabe.
Bei der Integration in freetz wird der "Log-Deamon" entweder ein eigenes Modul oder ganz sterben, wenn der syslog Patch sich bewährt und man eine syslog.conf editierbar machen könnte. Das ist aber noch weit weg. Im Moment will ich das GUI erstmal wasserdicht machen.
Ich habe eine neue "alpha"
Version hochgeladen mit einem syslogd - Schalter. Bitte mal testen (05.11-02).Da das Ding in verschiedenen Modulen eingreift, habe ich die stabile Alte noch zum Download belassen. Bis zur Integration wird es noch ein wenig dauern, ausserdem tut die Log-Mimik keinem weh, sie tut ja nichts, wenn nichts über /dev/debug herauspurzelt. Insofern ist das Interface ja auf jeder Linux Kiste theoretisch lauffähig.
Was die abweichenden Kernel-Module angeht, habe ich bislang keine Info. Das UI sichert aber grundsätzlich alle geladenen IPTables Module für den Restart, so dass man mit einem einigen manuellen modprobe und dem anschließenden Speichern der Regeln auch solche Themen vom Tisch bekommt. Übrigens, LOG Rules gehen auch im normalen Interface, da braucht man keine Experten - Eingabe.
Bei der Integration in freetz wird der "Log-Deamon" entweder ein eigenes Modul oder ganz sterben, wenn der syslog Patch sich bewährt und man eine syslog.conf editierbar machen könnte. Das ist aber noch weit weg. Im Moment will ich das GUI erstmal wasserdicht machen.
Zuletzt bearbeitet:
Besten Dank. Abgesehen davon, dass bei mir die Admin-IP (192.168.0.0./16) nicht mehr persistent in nhipt.par gespeichert wird, läuft die alpha-Version prima. Der ganze Logging-Krempel ist nicht mehr in nhipt.cfg enthalten, genauso sollte es sein.Ich habe eine neue "alpha"
Der zusätzliche Code belegt aber unnötig Speicher im Flash. Bei mir führte das nach dem "modsave flash"-Aufruf zu der bekannten Fehlermeldung "/var/flash/freetz too big" . Dafür, dass es auf meiner gefreetzten 71710 langsam eng wird, kann Dein Code natürlich nix, führt aber dazu, dass die iptables nicht persistent gespeichert werden (lässt sich immerhin leicht beheben, siehe hier; trotzdem ist Speicher-Sparen angesagt).
- Mitglied seit
- 28 Nov 2008
- Beiträge
- 1,080
- Punkte für Reaktionen
- 0
- Punkte
- 0
Danke für den Hinweis, hatte ich übersehen. Ich hatte überall Sperren eingebaut, um nur dann Daten in den Flash zu schreiben, wenn sich was geändert hat und unnötige Schreibzugriffe zu vermeiden.
Die Sache mit der Admin-IP ist nun gefixt. Die Regeln / Bootprozedur kann man übrigens bei Speichermangel auf dem Stick belassen, dann wird so gut wie gar kein flash der Box benötigt. Nach dem Boot spielt sich eh alles nur noch auf der RAM-Disk / im Arbeitsspeicher ab.
Die Sache mit der Admin-IP ist nun gefixt. Die Regeln / Bootprozedur kann man übrigens bei Speichermangel auf dem Stick belassen, dann wird so gut wie gar kein flash der Box benötigt. Nach dem Boot spielt sich eh alles nur noch auf der RAM-Disk / im Arbeitsspeicher ab.
Neueste Beiträge
-
Fritzfon X6: Verhalten der Auflegen-Taste nervt
- Letzte: BanditDD
-
[Frage] Kompletter Ausfall von DNS over TLS (DoT)
- Letzte: KunterBunter
-
Suche Telefonanlage für kleine Kanzlei
- Letzte: sunnyman
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: Erforderlich
