[Berlin-wireless] kleines nat problem mit ff-firmware

[Sven-Ola Tücke]

N'abend Stefan,

FYI: die aktuelle Firmware 1.6.31 hat ein neues Kernel-Module "flushnat.o". 
Das loescht das Conntrack beim Setzen des -j MASQUERADING. Ausprobieren?

// Sven-Ola

Am Freitag 22 August 2008 12:58:16 schrieb Stefan Sperling:
> On Sun, Aug 17, 2008 at 08:12:45AM +0200, Sven-Ola Tücke wrote:
> > Hey,
> >
> > physisch dran? Muss hoechstwarscheinlich gar nicht sein. Aber die
> > Firmware neu flashen - das muesste sein. Wegen neuem Linux-Kernel - den
> > kann man nicht einfach installieren. Ich hab's natuerlich ausprobiert und
> > bin recht sicher, das die Probe-FW laeuft. Was nicht klar ist, ob diesse
> > OpenVPN/Conntrack-Geschichte damit aus der Welt ist...
>
> Also, wenn man die Module lädt nachdem die set_masq() Funktion
> aufgerufen wird stehen gar keine NAT regeln mehr in den Tables.
>
> D.h. anscheinend braucht man die Module schon zum Erstellen der
> NAT regeln. Damit gibts ne zirkuläre Abhängigkeit die wir nicht
> auflösen können -> zu frühe ip_conntrack einträge per module
> später laden verhindern ist nicht.
>
> rmmod ip_conntrack zum flushen der conntrack einträge scheint
> übrigens auch nicht zu gehen:
>
> root at dachjo:~# lsmod | grep conntrack
> ip_conntrack           25008   0 [ipt_MASQUERADE iptable_nat ipt_state]
> root at dachjo:~# rmmod ip_conntrack
> root at dachjo:~# echo $?
> 0
> root at dachjo:~# lsmod | grep conntrack
> ip_conntrack           25008   0 [ipt_MASQUERADE iptable_nat ipt_state]
> root at dachjo:~#
>
> Analog für ipt_MASQUERADE, ipt_state und iptable_nat.
>
> Hat der Kernel evtl. keinen module-entladen support?
> Das ist optional bei einigen Kernel versionen AFAIK.
>
> Ich werde meinem VPN jetzt sagen, es soll nicht allzu oft
> keep-alive Packete an die Gegenstelle schicken. Dadurch wird
> das Risiko, dass ein falscher Eintrag zu falschem NAT verhalten
> führt hoffentlich etwas verringert.
>
> Wenn das Problem aufftritt hilft halt nur VPN aus, router
> rebooten, kurz warten, vpn an :/
>
> Übrigens ist das Problem heute schon wieder 2 Mal aufgetreten,
> jeweils auf beiden Routern, mit ca. ner halben Stunde dazwischen.
> Kein Ahnung warum das sogar einfach im laufenden Betrieb, also ohne
> reboot der router passieren kann.
>
> Sieht sonst noch jemand das Problem im eigenen Setup, oder bin ich
> der einzige der das reproduzieren kann? Das wäre interessant zu wissen.
> Ich schickte übrigens alle 2 Sekunden Keep-alive messages.
> Evtl. findet man das Problem auch wenn man in gleicher oder noch
> schnellerer Folge irgendwelche UDP Packete durch einen ff-firmware
> router schickt der NAT macht.
>
> Und kann die Welt nicht endlich mal komplett auf IPv6 umsteigen damit
> man kein NAT mehr braucht? Dann wär dieser Bug einfach weg.
> Wäre langsam eh mal an der Zeit.
>
> Danke,
> Stefan
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin