7270 mit Trunk - iptables-Module weg ... ?

[RalfFriedl]

Bei der 7270 ist der Kernel neu genug, damit conntrack funktioniert.
Allerdings hat AVM bei einigen Firmware-Versionen die dafür notwendigen Optionen nicht aktiviert. Das bedeutet zum einen, dass der Kernel ersetzt werden muss, zum anderen sind die von AVM erstellten Module nicht kompatibel mit dem geänderten Kernel. Der Patch make/linux/patches/2.6.*/300-skbuff-nf_conntrack.patch versucht das zu korrigieren, aber ich habe bisher noch nicht mitbekommen, ob es bei jemandem stabil läuft.

 

[mrspeccy]

Ich werde den 300-skbuff-nf_conntrack.patch auf jeden Fall auf meiner 7270v2 probieren, sobald ich wieder den Kernel ersetzen kann. Im Augenblick habe ich die Labor-Firmware 54.05.07-20870 zusammen mit Trunk 7943 auf meiner Box, sodass "replace kernel" mangels passender Sourcen nicht möglich ist.

 

[RalfFriedl]

Dann frag schon mal bei AVM nach den passenden Sourcen an.

 

[JohnDoe42]

Der Patch make/linux/patches/2.6.*/300-skbuff-nf_conntrack.patch versucht das zu korrigieren, ...

Wäre dieser Patch der für mich passende (da ich als Build-Umgebung Kernel 2.6.32.21 benutze) ?

Und zur Gesamtproblematik mal eine andere Idee: Wo genau werden denn die Tracking-Listen abgelegt ? Ließe sich da nicht ein Workaround basteln, der diese mit der nötigen Frequenz mal reduziert ?

Und gesetzt den Fall, daß der Patch in einer aktuell verfügbaren Konstellation (Freetz<->AVM-Sourcen) nicht funktioniert: Wie könnte ich denn sonst noch stateful-Regeln auf der 7270 betreiben ?

 

[RalfFriedl]

Der Patch sollte automatisch auf die entsprechenden Kernel angewendet werden, da er im Trunk bereits enthalten ist. Damit er einen Effekt hat, muss Du aber in der Kernel-Konfiguration die entsprechenden Module auch aktivieren. In der Standard-Config sind diese nicht aktiviert, weil sie sonst nicht kompatibel mit dem AVM Kernel wären.

Was meinst Du mit den Tracking-Listen? Die Liste der Verbindungen, die conntrack kennt? Die befindet sich im Hauptspeicher, alles andere wäre zu langsam, schließlich muss diese Liste für jedes Paket durchgesehen werden. Das Speicherleck beim conntrack ist allerdings in den neueren Kernel-Versionen behoben, so dass das nicht mehr das Problem ist.

 

[JohnDoe42]

... muss Du aber in der Kernel-Konfiguration die entsprechenden Module auch aktivieren.

Ähhh .. entschuldige die Frage .. aber wie mach' ich das ? Daß kernel-menuconfig ist im wiki etwas spärlich dokumentiert ...
Und auch irgendwie (zumindest für mich) etwas undurchsichtig ...

Was meinst Du mit den Tracking-Listen? Die Liste der Verbindungen, die conntrack kennt?

Ja.

Das Speicherleck beim conntrack ist allerdings in den neueren Kernel-Versionen behoben, so dass das nicht mehr das Problem ist.

Schon klar ... aber ich meinte einen Workaround für altere Boxen, z.B. eine 7170.

 

[RalfFriedl]

Es gibt für die alten Boxen einen Patch, mit dem einige schon gute Erfahrungen gemacht haben. Dieser ist schon längere Zeit im Trunk und vermutlich inzwischen sogar in einigen stabilen Versionen.

Nach dem Start von kernel-menuconfig gibst Du ein "/conntrack". Eines der ersten Ergebnisse ist:

Symbol: NF_CONNTRACK_IPV4 [=n]
Prompt: IPv4 connection tracking support (required for NAT)                                                          
  Defined at net/ipv4/netfilter/Kconfig:12
  Depends on: NET [=y] && INET [=y] && NETFILTER [=y] && NF_CONNTRACK [=n]                                          
  Location:
    -> Networking support (NET [=y])
      -> Networking options
        -> Network packet filtering framework (Netfilter) (NETFILTER [=y])
          -> IP: Netfilter Configuration

Damit siehst Du schon mal, wo Du hin musst.

 

[JohnDoe42]

Okay, ich werde das heute abend mal testen und dann wieder berichten.
Wenn ich diesen Patch in den Kernel aufnehme, müßte ich dann im menuconfig "Replace Kernel" aktivieren ?
Danke soweit und Grüße,

JD.

 

[RalfFriedl]

Der Patch ist wie gesagt im aktuellen Trunk bereits enthalten. Natürlich bewirkt er nichts, wenn man nicht den so erstellten Kernel auch auf die Box bringt.

 

[JohnDoe42]

Damit siehst Du schon mal, wo Du hin musst.

Ähm ... wo genau finde ich denn jetzt den Patch in der aktuellen Trunk-Build-Umgebung ?
Nach welchem String soll ich denn z.B. suchen ? CONFIG_ATHRS_HW_NAT oder sowas war es schon mal nicht.
Und bei Networking support -> Networking options -> Network packet filtering framework -> Core netfilter Configuration finde ich auch nichts, was ich mit diesem Patch in Verbindung bringen kann...
oder ... ist 's der Netfilter connection tracking support ?

 

[RalfFriedl]

Also zum dritten Mal: Der Patch ist im Trunk bereits enthalten, Du musst dafür gar nichts tun.

Du muss nur in der Kernel-Config die Module aktivieren, die Du haben willst.

 

[JohnDoe42]

Wie ich bereits sagte: Ich benötige noch xt_state. Wo genau soll ich denn im kernel-menuconfig danach suchen ? Oder allgemeiner: An welcher Stelle wähle ich denn namentlich Module aus? Ich kann da nämlich bisher lediglich relativ allgemein gehaltene Beschreibungen von Dingen, die größere Pakete tun, finden ...Und beim XTABLES-Support ist kein xt_state dabei.

 

[olistudent]

connection tracking support ist die richtige Option. Aber die Frage welche Kerneloption du für welches Kernelmodul aktivieren musst hat nicht wirklich was mit Freetz zu tun...

 

[JohnDoe42]

So, ich hab' also nun verstanden, daß zwischen Kernel 2.6.19.2 und Kernel 2.6.32 irgendwie das Modul xt_state "abhanden" gekommen ist.
Gibt es denn überhaupt keine Möglichkeit, dieses irgendwie zu "reaktivieren" ?
Wie werden denn mit der 05.05er FW derzeit überhaupt stateful-Regeln des netfilters realisiert ?
Oder muß ich doch für die 7270 zurück zur .88er FW ?
Grüße,

JD.

 

[RalfFriedl]

So, ich hab' also nun verstanden, daß zwischen Kernel 2.6.19.2 und Kernel 2.6.32 irgendwie das Modul xt_state "abhanden" gekommen ist.
Gibt es denn überhaupt keine Möglichkeit, dieses irgendwie zu "reaktivieren" ?

Sicher gibt es die.

Wie werden denn mit der 05.05er FW derzeit überhaupt stateful-Regeln des netfilters realisiert?

Entweder gar nicht, oder mit den Modulen, die vorhanden sind. Bisher hat sich noch keiner gefunden, der es testen wollte.

 

[JohnDoe42]

Sicher gibt es die.

Verrätst Du auch, welche ?

Entweder gar nicht, oder mit den Modulen, die vorhanden sind. Bisher hat sich noch keiner gefunden, der es testen wollte.

Ich würd' 's ja tun ... bloß wie ?
Fakt ist, daß beim Versuch des Ladens der stateful-Regeln, die ich weiter oben erwähnte, die beschriebenen Fehler auftauchen.

 

[RalfFriedl]

Verrätst Du auch, welche ?

Du kannst versuchen, die alten Module auf den neuen Kernel zu portieren. Das heißt nicht, dass das sinnvoll wäre.

Wähle in der Kernel-Config xt_state aus.

 

[JohnDoe42]

Du kannst versuchen, die alten Module auf den neuen Kernel zu portieren.

Wie genau könnte ich das am Besten bewerkstelligen ? Ich nehme an, das banales Kopieren der Sourcen nicht reicht.

 

[RalfFriedl]

Nein, tut es nicht.
Die kurze Antwort ist, wenn Du fragen musst, lässt Du besser die Finger davon.

Warum machst Du es Dir nicht einfach, wählst xt_state aus und lädst Deine Regeln?

 

[JohnDoe42]

Warum machst Du es Dir nicht einfach, wählst xt_state aus und lädst Deine Regeln?

Weil es nichts auszuwählen gibt. "state" ist bei den X-Tables-Modulen im Kernel des aktuellen Trunk (zumindest im kernel-config) nicht vorhanden.
Genau das ist das Problem seit #13.