Problem mit iptables auf der SL WLAN

[dsteinkopf]

Ja. Und: Ja, das scheint das Kernproblem zu sein...

Dirk

 

[alxweb]

Hat der Kernelpatch(update) eigentlich das Problem der 3h reboots gelösst ? Ich hab dies soeben auch gemacht da ich das gleiche Problem hatte auf einer 7170 sobald iptables aktiviert war.

Bei mir ist das Probelem mit 3 Stunden eigentlich noch nie eingetreten. Bei mir kommt die Box ab un zu in einen undefinierten Zustand, vermutlich wg. Arbeitspeicher. (Wenn das Login noch klappt, fehlen einige Prozesse). Die SL-WLAN hat bei mir nur 14 MB ram, wovon 45 % ctlmgr belegt und 33 % dsld.
Inzwischen habe ich den Kernel Patch wieder runter, da ich mal alles neu ausgecheckt habe. Die Box läuft bei mir auch ohne das Update auf 2.6.13.5 genauso stabil. Eventuell hat es was damit zu tun, dass ich die Module anders lade, also nicht über firewall-cgi, sondern mit folgendem Skript:

MODULE_DIR="/lib/modules/`uname -r`/kernel/net/ipv4/netfilter/"
MODULES=`(cd $MODULE_DIR; ls * | sed -n -e 's/\.ko$//p' -e 's/\.o$//p' -e 's/\.ko\.gz$//p' -e 's/\.o\.gz$//p')`
for module in $MODULES; do
  if lsmod | grep ${module} >/dev/null; then continue; fi
  modprobe ${module} ||  exit 1
done
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

Folgende Module sind/werden geladen:

/var/mod/root # lsmod
Module                  Size  Used by    Tainted: P  
iptable_filter          2112  1 
ipt_state               1312  21 
ipt_multiport           2176  8 
ipt_mac                 1504  0 
ipt_iprange             1600  0 
ipt_conntrack           2080  0 
ipt_REJECT              4608  0 
ipt_REDIRECT            1536  0 
ipt_MASQUERADE          2496  0 
ipt_LOG                 7328  7 
ip_nat_tftp             1184  0 
ip_nat_irc              1952  0 
ip_nat_ftp              2816  0 
iptable_nat            22096  6 ipt_REDIRECT,ipt_MASQUERADE,ip_nat_tftp,ip_nat_irc,ip_nat_ftp
ip_tables              21088  11 iptable_filter,ipt_state,ipt_multiport,ipt_mac,ipt_iprange,ipt_conntrack,ipt_REJECT,ipt_REDIRECT,ipt_MASQUERADE,ipt_LOG,iptable_nat
ip_conntrack_tftp       3104  1 ip_nat_tftp
ip_conntrack_irc       70528  1 ip_nat_irc
ip_conntrack_ftp       71552  1 ip_nat_ftp
ip_conntrack           42192  10 ipt_state,ipt_conntrack,ipt_MASQUERADE,ip_nat_tftp,ip_nat_irc,ip_nat_ftp,iptable_nat,ip_conntrack_tftp,ip_conntrack_irc,ip_conntrack_ftp
tiap                  788384  0 
kdsldmod              582128  2 
avalanche_usb          46048  0 
tiatm                 109184  0

Im Forum liest man nur, dass Iptables nicht geht. Ist auch logisch, bei denen es geht, die schreiben nicht darüber. Bei wem ausser mir geht Iptables noch? Eventuell können wir über Gemeinsamkeiten die Uhrsache eingrenzen.

 

[alxweb]

Hallo nochmal. Eventuell bin ich auf etwas gestoßen!
Ich habe meine Module-Liste mit der verglichen, die iptables-cgi lädt. Dabei habe ich folgende Module mehr:

ipt_conntrack, ipt_REJECT
ip_nat_tftp, ip_nat_irc, ip_nat_ftp
ip_conntrack_tftp, ip_conntrack_irc

Ich hatte von diesen Modulen ipt_conntrack in verdacht, also habe ich das modul aus dem Kernel entladen und gewartet was passiert.
Nach ~3 Stunden macht meine Box ein Reboot. Also Fehler reproduziert.
Mit geladenem ipt_conntrack habe ich dieses Reboot nicht.

Eine Erklärung hierfür kann ich nur vermuten. Meine Vermutung ist:
Beim Kernel-bauen ist dieses Modul mit ausgewählt. Also werden irgendwelche Abhängigkeiten zu diesem Modul mit einkompiliert. Normalerweise wird dieses Modul auch mit make modules_install mit installiert und evtl. sogar automatisch geladen. Bei Freetz nicht. Hier wird das Modul zwar kompeliert, jedoch nur installiert, wenn ausgewählt.
Was mir noch aufgefallen ist, ist dass Module nicht automatisch nachgeladen werden, wenn eine Iptables-Regel diesen benötigt. Mein PC macht das, das ds-mod-2.4 machte das auch.

Hoffe, bei Euch wird das Problem auch mit dem Laden des ipt_conntrack gelöst sein.

 

[olistudent]

Hi.
Endlich mal einer der Ahnung von iptables hat.
Die Module werden nicht automatisch nachgeladen, weil wir das im Kernel deaktiviert haben. Ansonsten würden die Module nur mit "replace kernel" laufen, weil AVM das auch nicht aktiviert hat.

MfG Oliver

 

[hendrikm]

Genial! Werde es morgen früh gleich ausprobieren und hier mein Ergebnis bis morgen Abend posten

Vielen Dank!

 

[dsteinkopf]

Klingt gut. Ich habe zwar die alte 7050 nicht mehr in Betrieb, kann aber an meinen Startskripten sehen, dass dieses Modul bei mir auch nicht geladen wurde. Warum auch immer... Ich habe auch viel mit verschiedenen Modulen probiert. Aber manchmal sieht man halt den Wald vor lauter Bäumen nicht.
..

OT: Leider nützt das bei der 7270 nicht, weil beim neuere Kernel die Module ganz anders heißen.


Dirk

 

[alxweb]

Das Modul heißt im neuen Kernel xt_conntrack.

 

[dsteinkopf]

Ja, ich weiß danke .
Vielleicht kannst Du mir ja hier weiter helfen?

Dirk

 

[alxweb]

Gibt es schon Testergebnisse für iptables mit 2.6.13er Kernel bei geladenem ipt_conntrack Modul? Besteht noch das 3-Stunden-Problem?
Oder soll ich einfach ein Ticket im Bug-Tracking aufmachen, dass das Modul in firewall-cgi aufgenommen werden soll?

 

[Silent-Tears]

Gibt es schon Testergebnisse für iptables mit 2.6.13er Kernel bei geladenem ipt_conntrack Modul? Besteht noch das 3-Stunden-Problem?
Oder soll ich einfach ein Ticket im Bug-Tracking aufmachen, dass das Modul in firewall-cgi aufgenommen werden soll?

Wie wäre es denn, wenn du das mal selbst ein wenig testest und uns mitteilst, ob das 3-h-problem damit behoben ist? Und wenn ja, mach doch dann ein Ticket mit einem Patch auf, hmm?

Lieben Gruss

cinereous

 

[alxweb]

Bei mir besteht das 3-Stunden-Problem nicht und hat nie bestanden (Siehe Signatur). Ich hatte das Problem von Anfang an nicht. Ich nutze das firewall-cgi nicht, sondern lasse mir ein Skript von fwbuilder generieren. Bitte überfliege meine Beiträge in diesem Thread, bevor Du mich anfährst (Insbesondere http://www.ip-phone-forum.de/showpost.php?p=1047847&postcount=23 ).
Mich interessiert, ob meine Vermutung bei den anderen das Problem behebt, die vom Problem betroffen sind, denn ich bin nicht betroffen. Aber wenn es niemand braucht, bitte.
Ich selbst brauche diesen Fix nicht, ich wollte nur was zu dem Projekt beitragen, das ich nutze, denn so funktioniert ja open-source.
Also, wenn mir jemand bestätigt, dass meine Vermutung stimmt, werde ich natürlich einen entsprechenden Patch machen. Wenn nicht, dann braucht es wohl keiner.

 

[hendrikm]

Tja, leider hat dieses Modul bei mir nicht geholfen :-/ Ich bin Ratlos...

 

[poruid]

... sondern lasse mir ein Skript von fwbuilder generieren

This may come handy.
Using fwbuilder is just what I would like to achieve.
Would you be so kind as to post your fwb-file so that it may serve as a template, please?
Where and how did you deploy (using freetz::usb-root or another writable root file system), c.q. insert into the firmware, the fwbuilder generated rules?

For your information: I still ponder on the number of net devices I will create (using cpmaccfg and brctl) and I 'm not sure whether the control of these could best be managed by fwbuilder also considering that VoIP telephony is handled with the AVM programs. For ADSL a separate modem ST 510i (in bridge mode) is used because this modem achieves a better line speed on my long line (± 5km) than the FB build-in modem does; the ST would be deployed when the FB modem wth new or other firmware performs comparably.
So, suggestions are welcomed.

p.s. wenn erwünscht kann ich versuchen Deutch zu schreiben, aber ... daß kostet mehr Mühe.

 

[alxweb]

Ich antworte auf Deutsch, da es für mich einfacher ist.

Das Deployment funktioniert über ssh/scp. Der fwbuilder überträgt über
scp ein Bash-Skript fritz.box.fw in das Verzeichnis /var/tmp/flash auf der FB und führt dieses aus.
Das Skript beinhaltet auch das Speichern des Skriptes über ein Reboot
(modsave).

Beim Neu-Starten der FB wird das Skript aus der rc.custom ausgeführt:

#!/bin/sh
#echo "Starte Firewall"
/var/tmp/flash/fritz.box.fw

Warnung: Für die ersten Tests noch nicht nutzen, sonst kann man sich aussperren
Warning: for first tests you dont use this, because you risk loose access to the FB

Zu meiner Konfiguration.
Die FB hat intern die IP 192.168.238.1
Die AVM-Firewall ist auf "exposed hosts" auf die IP 192.168.238.249 gestellt. Somit erreichen alle Pakete Iptables. Ein Client mit dieser IP existiert nicht. Die Pakete an diese IP werden geloggt und verworfen, falls diese nicht per DNAT woanders adressiert werden. Hiermit kann man auch ohne Virtual-IP Ports auf der FB freischalten, indem man Pakete an die 192.168.238.249 einfach per DNAT auf die FB umbiegt. (Siehe OpenVPN Konfiguration im Skript)

Die Funktion "Module laden" vom fwbuilder wird nicht verwendet, da nicht alle benötigten Module geladen werden (freetz lädt abhängige Module nicht automatisch nach). Dafür ist ein kurzes Skript im Prolog.

Spontan fällt mir nichts ein, was ich dazu noch schreiben kann. Falls Fragen oder Anregungen da sind, bitte posten.

Hier ist meine fwbuilder Datei fritz.box.fwb
und das kompilierte Ergebniss fritz.box.fw

 

[poruid]

@alxweb
Danke.

 

[WEARENOTALONE]

Hallo zusammen,
am letzten Wochenende habe ich mich noch einmal mit meiner FritzBox Fon WLAN 7170 (ds26-15.2 auf 29.04.37) und iptables beschäftigt. Dabei ist mir das Script von alxweb zum Laden aller netfilter-Kernelmodule aufgefallen. Mit einer kleinen Modifikation des Skriptes läuft meine FritzBox nun reproduzierbar mit geladenen ip_conntrack länger als 3h:

echo "Stopping dsld..."
dsld -s

echo "Loading modules..."

modprobe ip_conntrack hashsize=256

MODULE_DIR="/lib/modules/`uname -r`/kernel/net/ipv4/netfilter/"
MODULES=`(cd $MODULE_DIR; ls * | sed -n -e 's/\.ko$//p' -e 's/\.o$//p' -e 's/\.ko\.gz$//p' -e 's/\.
for module in $MODULES; do
if lsmod | grep ${module} >/dev/null; then continue; fi
modprobe ${module} || exit 1
done

echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
#echo "2048" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

echo "Starting dsld..."
dsld

Nach dem Ausführen des Scripts wird unter anderem noch eine Firewallregel mit " -m state --state ESTABLISHED,RELATED -j ACCEPT" geladen, um ip_conntrack auch wirklich zu "verwenden".

Der letzte Neustart der Box liegt nun schon 3 Tage und 2h zurück *freu*

Mit freundlichen Grüßen
WANA

 

[olistudent]

Hi.
Kannst du sagen, ob es am Neustart vom dsld liegt, dass die Box nicht neu startet? Oder liegt es an dem "echo 1 > .../rp_filter"?

MfG Oliver

 

[cuma]

Mir scheinen die 256 gleichzeitig möglichen Verbindungen etwas wenig. Bei mir verbraucht der JFritz 0.71 schon mal 50. Dazu kommen noch 10 immer offene Verbindungen der Box selbst (dns usw). Wenn ich dann noch im Opera ein paar Bookmarks öffne sind dies zusammen schon weit über 200 gleichzeitig offene Verbindungen

 

[WEARENOTALONE]

Wenn ich den dsld nicht stoppe, sondern einfach die Module & Firewallregeln lade und im Anschluss den dsld stoppe, kommt es bei meiner Box manchmal (!!!) zum sofortigen Neustart.

Inwiefern "rp_filter" das Neustarten verhindert, werd ich noch testen.


Die hashsize habe ich bisher auf 256 begrenzt, um diese mögliche Fehlerquelle "auszuschalten". Wenn ich nur die hashsize auf 256 setze, aber die restlichen Kernelmodule nicht lade, kommt es zum Neustart nach 3 Stunden.

Werden von dem ip_conntrack Modul alle Verbindungen der FritzBox beobachtet? Bisher habe ich nämlich nur einen Client per "-m state --state ESTABLISHED,RELATED -j ACCEPT" "konfiguriert".

Gilt die hashsize=256 wirklich für alle Verbindungen? Was passiert wenn die 256 Verbindungen erreicht werden; ist es dann nicht möglich neue Verbindungen aufzubauen oder werden einfach nicht mehr Verbindungen beobachtet?

Mfg
WANA

 

[cuma]

Der Hashsize patch ist doch im svn eingecheckt und greift wenn conntrack geladen wird. Die beobachteten Verbindungen kannst du mit "cat /proc/net/ipconntrack" einsehen