iptables auf der 7320 ???

[sf3978]

... gegen 17.45 Uhr die Patches "7320_kernel_modules.patch" und "7320_iptables_modules.patch" neu erstellt?
...

Siehe hier: >>> klick <<<.

 

[hhfreetz]

iptables auf der 7320

Ich hab's mal mit den beiden Patches (7320_iptables_modules.patch und 7320_kernel_modules.patch) versucht...:

• trunk - revision 6351
• beide Patches angewendet
• iptables & nhipt mit ALLEN Modulen und ALLEN libaries gewählt
• recovert - neues Image eingespielt
• telnet...

Einen Schritt bin ich nun weiter! Die Anzeige der Regeln scheint erstmal möglich.

root@fritz:/var/mod/root# [COLOR="Red"]iptables -L[/COLOR]
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Jedoch ist ein Zugriff auf die "NAT-Tabelle" nicht möglich.

root@fritz:/var/mod/root# [COLOR="Red"]iptables -t nat -L[/COLOR]
iptables v1.4.1.1: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
root@fritz:/var/mod/root# [COLOR="Red"]modprobe nf_conntrack[/COLOR]
modprobe: can't load module nf_conntrack (kernel/net/netfilter/nf_conntrack.ko): unknown symbol in module, or unknown parameter

Mit "dmesg" wurden unbekannte Symbole gemeldet.

root@fritz:/var/mod/root#[COLOR="Red"]dmesg[/COLOR]
...
iptable_filter: ignoring short SOCK_RAW packet.
__ratelimit: 38 callbacks suppressed
iptable_filter: ignoring short SOCK_RAW packet.
[COLOR="Red"]nf_conntrack: Unknown symbol nf_conntrack_destroy (-2)
nf_conntrack: Unknown symbol nf_ct_destroy (-2)
nf_conntrack: Unknown symbol ip_ct_attach (-2)
nf_conntrack: Unknown symbol nf_conntrack_destroy (-2)
nf_conntrack: Unknown symbol nf_ct_destroy (-2)
nf_conntrack: Unknown symbol ip_ct_attach (-2)[/COLOR]
iptable_filter: ignoring short SOCK_RAW packet.

Was kann man dagegen tun? Wie lassen sich die Symbole "bekanntmachen"?

Das müsste doch zu machen sein - oder ?

PS:
Ich kam dann noch auf die Idee, es nochmal mit "Replace kernel" zu versuchen. Mit diesem Image startete die Box aber nicht - sie blieb beim Starten hängen.

 

[olistudent]

Wenn ich das richtig sehe, dann muss dazu replace kernel aktiviert sein. Da wäre zu überlegen, ob wir diese Symbole nicht in das nf_conntrack Modul portieren?

Gruß
Oliver

 

[hhfreetz]

iptables auf der 7320

Hallo Oliver,

"Replace Kernel" ist momentan keine Moglichkeit (bei der 7320) - Die Box startet mit dieser Option nicht, sondern bootet ständig neu. Ich hab's gerade noch mal ausprobiert, zur Info:

• Revision 6419
• NHIPT und IPTables mit allen Modulen und Libaries ausgewählt
• "Replace Kernel" ausgewählt
• Box recovert und Image eingespielt
• Box startet vorerst normal bis zur Initialisierung des WLANs (WLAN-LED und Power-LED hören auf zu blinken und leuchten kurz dauerhaft)
• DANN automatischer Reboot...
• die beiden vorherigen Punkten wiederholen sich dann

Ohne "Replace Kernel" ist die Situation momentan unverändert zur Revision 6351 (siehe #42: 22.12.2010, 14:50)

Wodurch ließe sich also die "Replace Kernel"-Option auf der 7320 realisieren?

Dann könnte ich nämlich auch nachschauen, was mit den Modulen und unbekannten Symbolen los ist und auch eine eventuelle Portierung der unbekannten Symbole in das nf_conntrack - Modul testen.

Grüße
hhfreetz

 

[olistudent]

Ich hatte bis eben "replace kernel" aktiv. Aber jetzt musste ich die Option auch abwählen, weil es zu Oopses während des Bootvorgangs kam. Wir hatten das auf der 7270 auch schon mal. Damals lag es (vermutlich) an Kernel-Optionen, die wir abgeändert hatten.

Gruß
Oliver

 

[hhfreetz]

Und dann frage ich nun: Welche Kernel-Optionen sollten wie geändert werden? Und wie macht man das?
Weißt Du Rat?

 

[cando]

Hallo hhfreetz,

vielen Dank für die Nachricht.

Die modprobe Meldungen kannst Du bei den 73xx Boxen getrost ignorieren. Die iptbles Module sind im Kernel bereits integriert. Bei der 72xx war das noch nicht der Fall und deshalb habe ich eine Liste von ausgewählten wichtigen Modulen manuell laden lassen. Beim Speichern werden die geladenen Module mit lsmod ausgelesen und für den Reboot in das Startscript aufgenommen.

Wie gesagt, bei den 73xx Kisten ist das nicht mehr nötig - die Meldungen kann man ignorieren (bis AVM den Schalter vielleicht wieder ausschaltet). Deshalb hatte das für mich bislang auch keine Priorität es zu fixen Auf meiner Box stehen die Einträge auch im Log, iptables funktioniert aber trotzdem tadellos.

Die ober erwähnte Funktion könnte man auch komplett bei den 73xx Boxen und die 72xx/71xx Boxen mit replaced Kernel und passendem Kernel Schalter aus dem Script schmeißen, nur dann müsste man für die anderen alten Boxen mit original Firmware wieder eine Extrawurst braten....

Falls bei Dir die Module NICHT automatisch geladen werden sollten (Fehlermeldungen, dass eine Regel nicht angenommen wird wegen fehlender Module), dann kannst Du das Modul in der Expertenzeile mit modprobe modulname selbst laden. Beim Speichern kommt es in die Liste und wird fortan auch immer automatisch geladen.

Wenn es Probleme mit den neuen Namenskonventionen (nf_) gibt, poste bitte ins Forum zu NHIPT

Hallo cando,
ich wollte dir mal eine Informationen zukommen lassen (Du hast doch etwas mit nhipt zu tun oder?).
Ich versuche seit einiger Zeit, iptables auf die 7320 zu bringen. Dabei erhalte ich im Freetz-Interface folgende Fehlermeldungen:
NHIPT zeigt einige Probleme in /var/log/mod.log

rc.mod version freetz-devel-6419
crond is disabled.
AVM telnetd is disabled.
Starting Freetz webinterface ... done.
swap is disabled.
Starting inetd ... done.
configuring nhipt gui ... /usr/ipt
modprobe: module ip_conntrack not found in modules.dep
modprobe: module ip_conntrack_ftp not found in modules.dep
modprobe: can't load module ipt_REJECT (kernel/net/ipv4/netfilter/ipt_REJECT.ko): unknown symbol in module, or unknown parameter
modprobe: module xt_state not found in modules.dep
iptables reconfigured

Bei mir heißen die Module "neuerdings" nf_conntrack usw.
Vielleicht ist es ja von Bedeutung für dich (bzw. für mein Vorhaben).

gruß
hhfreetz

 

[cando]

Bezüglich Reboots:

Ich hatte das Problem auch schon mal beim Firmware Upgrade der 7390 von einer Version auf die nächste. Es hat nur funktioniert, wenn man ein AVM Recovery Image eingespielt und konfiguriert hat (jungfräuliche Box), dann mir einem sauberen AVM Umage Upgegradet hat, und erst danach freetz mit der gleichen fw-Version aufgespielt hat. Beim Upgrade scheint AVM einige Konfigurationsänderungen zu machen, die beim Upgrade via Freetz nicht passieren - was die Box wohl abschießt. Ich konnte auch eine gespeicherte alte Konfig nicht restoren ohne die Box zu killen, es half nur der beschriebene Weg und neues manuelles setzen aller Einstellungen....

 

[olistudent]

Die 7320 ist leider nicht wie die 7390. Der Kernel ist neuer und hat Symbole die für nf_conntrack benötigt werden, die aber in net/core.o landen...

Gruß
Oliver

 

[cando]

Oops. Dann geht iptables mit den neuen nf_* noch gar nicht, zumindest was die kommandos betrifft, die diese Module benötigen... Da ich keine 7320 habe, kann ich auch noch nicht nhipt anpassen / erweitern, mangels Testmöglichkeiten. Bislang suche ich nur nach:

ip_*
ipt_*
iptable*
x_*
xt_*
ip6_*
ip6t_*
ip6table*
​

Modulen beim Speichern (root/usr/ipt/cgi-bin/nhipt.cgi, Zeilen 450-460)

Falls die 7320 per modprobe auch wieder die Module laden muss, müsste man die Suche auf die geladenen nf_* erweitern.

	system("lsmod \| grep \"^ip_\\\|^ipt_\\\|^iptable\\\|^x_\\\|^xt_\" \| awk \47{print $1}\47 \| sort > /var/tmp/nhipt.yyy");
	system("lsmod \| grep \"^ip6_\\\|^ip6t_\\\|^ip6table\" \| awk \47{print $1}\47 \| sort >> /var/tmp/nhipt.yyy");
...

Außerdem müssten die Stellen mit dem conntrack je nach Box die passenden Module nachladen, wenn diese noch nicht im Speicher sind. (natürlich nur, wenn kein Autoload Modules aktiviert / vorhanden ist und die Module nicht im Kernel integriert sind).

Wenn jemand die 7320 mit iptables zum Laufen gekriegt hat, bitte mal melden.
Ich bräuchte ein lsmod dump, um zu sehen was da per modprobe geladen werden muss. Notfalls müsste man eine eigene Version für die Box bauen, sonst wird es unübersichtlich.

Gruß cando

 

[hhfreetz]

iptables auf der 7320

Hallo,

irgendwie bin ich mit meinem Latein am Ende. Auf dieser Ebene fehlt mir einfach das (Hintergrund-)Wissen. Ich glaube auch fast, dass das hier nicht der richtige Ort ist, um meine Wissenslücken zu schließen, auch wenn ich daran Interesse hätte.
Mich würde z.B. das Zusammenspiel von "Kernel - 'IPTabellen' - Module - Symbole" intereressieren.

Wenn mir einer das erklären könnte oder vielleicht weiß, wo ich was darüber erfahren kann, dann wäre ich dankbar.
Wenn nicht, dann bin ich auch dankbar und harre der Entwicklung, die da kommt.

Grüße
hhfreetz

PS:
Can do?

 

[cando]

Ich versuch's mal laienhaft:

Um eine Systemfunktion in Linux zu integrieren gibt es mehrere Möglichkeiten:

1. Man integriert sie direkt in den Kernel, sie wird einfach mit übersetzt und ist dann Bestandteil des Kerns. Sie steht immer zur Verfügung
2. Man realisiert sie als nachladbares Modul (ladbar mit modprobe & Co), und lädt sie bei Bedarf nach - hällt den Kernel schlank im Speicher.
3. Man implementiert sie als dynamische Bibliothek (ähnlich der dll's bei Windows)
4. Man realisiert sie als Userspace Programm, das mit niedrigeren Privilegien auskommt

Das Problem bei dem Ganzen ist aber, dass diese Funktion ja von anderen Programmen und Modulen addressiert werden muss, und der Linker
(Das Programm, das das Ganze zusammenbindet - entweder nach dem Kompilieren oder zur Laufzeit) braucht Informationen, wie diese
Funktion aufzurufen ist (Aufruf-Parameter, Rückgabewerte, Zugriff auf externe Variable und andere Funktionen). Hier kommen die Symbole
ins Spiel, es sind so zu sagen, die Beschreibungen der Schnittstellen ohne der Implementierung der Funktion selbst. Ohne diese Symbole
kann der Linker das System nicht fehlerfrei aus seinen Bestandteilen zusammenfügen.

Auch brauchen Installationsmanager (wie z.B. der apt bei Ubuntu) Informationen über die installierten Versionen und der Verträglichkeit
der zu installierenden Pakete, damit das System bei der Installation eines neuen Programmes nicht instabil wird oder z.B. ein für 64 Bit
kompiliertes Programm nicht auf einen 32 Bit OS gestartet wird etc.

Ach ja, iptables.

Eigentlich reden wir hier von den im Linux Kernel integrierten Netzwerkfunktionen und der netfilter firewall, die durch Module entweder im Kernel
oder nachladbar auf diese sehr tiefen Kommunikationsschichten zugreift. iptables ist einfach "nur" eine Kommandozeilen Tool, mit dem man
über eine Linux shell ebendiese netfilter Funktionen konfigurieren kann.

Da der Kernel von AVM kommt und die passenden Symbole darin fehlen, ist es wohl schwierig, die Module zu bauen und anzubinden....

 

[hhfreetz]

cando? ... Yes, you can!

Vielen Dank für deine Erklärungen, die ich auf dieser Ebene nachvollziehen kann.
Darf ich dir (euch) noch ein paar Fragen stellen?

Der Kernel wird also von AVM vorgegeben.

1. Bedeutet das, dass der Kernel beim Freetz-Image bauen schon "compiliert" übernommen wird? Oder wird der Kernel dabei durch Vorgaben von AVM jeweils neu "gebuildet"?
2. Was bedeutet in diesem Zusammenhang "Replace Kernel"? Kommt dann ein "nicht AVM-Kernel" zum Einsatz?

Und nun etwas konkreter auf das Thema bezogen:

root@fritz:/var/mod/root# modprobe nf_conntrack
modprobe: can't load module nf_conntrack (kernel/net/netfilter/nf_conntrack.ko): unknown symbol in module, or unknown parameter

root@fritz:/var/mod/root#dmesg
...
iptable_filter: ignoring short SOCK_RAW packet.
__ratelimit: 38 callbacks suppressed
iptable_filter: ignoring short SOCK_RAW packet.
nf_conntrack: Unknown symbol nf_conntrack_destroy (-2)
nf_conntrack: Unknown symbol nf_ct_destroy (-2)
nf_conntrack: Unknown symbol ip_ct_attach (-2)
nf_conntrack: Unknown symbol nf_conntrack_destroy (-2)
nf_conntrack: Unknown symbol nf_ct_destroy (-2)
nf_conntrack: Unknown symbol ip_ct_attach (-2)
iptable_filter: ignoring short SOCK_RAW packet.
...

• Bedeuten die obigen Meldungen, dass beim Versuch des Ladens vom Modul "nf_conntrack" ein Fehler auftritt, weil im Kernel einige Symbole fehlen, an die das Modul gebunden werden soll bzw. muss?
  Oder fehlen im Modul "nf_contrack" die Symbole, die der Kernel zum Verknüpfen vorgibt?

Danke einfach mal schon im Voraus...

 

[cando]

Also gut. Noch ein paar Anmerkungen, eigentlich steht das recht ausführlich in der Freetz Wiki.

Die Firmware kommt von AVM, sie ist gepackt, da AVM Linux als OS verwendet muss sie die Quellen für den Open Source Teil offenlegen, der Rest ist AVM Eigenentwicklung oder proprietäre Software, die von AVM lizensiert ist und nicht öffentlich zugänglich ist.

Jetzt kommt freetz ins Spiel. Das Ganze wird ausgepackt, gepatcht, mit neuen Funktionen Angereichert und wieder verpackt.

Wenn die Kernel Sourcen von AVM in Ordnung sind, läßt sich auch der Kernel ordentlich kompilieren. Dort kann man Optionen sperren oder hinzufügen etc und die Symbole werden auch ordentliich aufgelöst. Replace Kernel bedeutet, AVM Kernel wird durch den selber compilierten ersetzt. Für die proprietären Module sind die Symbole ja vorhanden - und so können sie ebenfalls eingebunden werden.

Das ist aber nicht immer der Fall. Manchmal passt die veröffentlichte Kernel Source mit den veröffentlichten Symbolen nicht wirklich zusammen und man kann keinen eigenen Kernel kompilieren. Dann hilft nur, den Kernel von AVM so zu verwenden, wie er ist und mit Hilfe der vorhandenen Symbole passende Module hinzuzufügen. Für die meisten Pakete funktioniert das recht gut, aber Pakete, die erweiterte Kernel Funktionen benötigen, machen halt etwas Ärger - das ist momentan wohl mit den 73xx Boxen der Fall, man kann (noch nicht) den Kernel von AVM ersetzen.

Eigentlich muss AVM nach Open Source Lizenz alles ordentlich veröffentlichen, nur lassen die sich eben oft viel Zeit damit...

 

[olistudent]

Nachdem ich jetzt geschätzte 10 Firmwares geflasht habe bin ich zu folgendem Ergebnis gekommen:
Sobald ich in der Kernel-Config die Option "Netfilter connection tracking support" setze und den Kernel ersetze landet die Box in einer Reboot-Schleife.

Also selbst falls das rausnehmen dieser Option das Problem mit dem "replace kernel" löst, dann lässt sich iptables nicht mehr für NAT verwenden.

Gruß
Oliver

 

[cando]

Vielleicht ist ja auch nur das neue NAT Modul fehlerhaft oder passt nicht zum Kernel. Da muss man auf die nächste version / fix warten. Solange läßt sich NAT ja auch mit dem dsld von AVM bewerkstelligen und iptables als 2. Firewall für den Rest nutzen. Baust Du den netfilter conntrack als modul oder integriertst du den direkt in den kernel? Nicht dass vielleicht AVM ein eigenes Modul mit gleichem Namen oder Symbolen hat, was sich mit dem original beißt....

 

[olistudent]

Ich habe conntrack als Modul und fest probiert. Bei beiden Varianten hatte ich Segfaults sobald der telefon Daemon gestartet wurde.

Gruß
Oliver

 

[cando]

Hast Du VoIP Telefonie aktiv? Vielleicht hat da AVM was gezaubert - die müssen ja auch NAT-en.
Die normalen Telefone (ISDN / Anlog / DECT) sollten mit netfilter & co nichts zu tun haben...

 

[olistudent]

Nein, ich hab keine VoIP Telefone.

Hier hab ich mal die nötigen Änderungen an der Kernelconfig angehängt.

Gruß
Oliver

 

[hhfreetz]

Hallo Oliver, hallo Cando,
nochmals vielen Dank für eure Bemühungen (stundenlanges Flashen, Fragen beantworten, an Lösungen tüfteln, ...).

Ist iptables lauffähig, wenn ich den "7320_disable_conntrack.patch" mit "replace Kernel" anwende (also ohne das conntrack-Modul auskommen muss)?
Ist dann auch noch NAT möglich?

Grüße
hhfreetz