nhipt - Anfänger-Eingabeproblem

[cando]

Entweder ist die Chain nicht vorhanden, auf die eine Regel angewendet werden soll, oder das Ziel ist unbekannt / nicht unterstützt.

Man muss den Befehl mal posten, der den Fehler verursacht.

Bei der 7270 kann dieser Fehler entstehen, wenn zwar ip_tables geladen ist, aber x_tables oder iptable_filter fehlt. Dann kennt er seine Standard - Kette filter nicht.

Die Targets sind ACCEPT, DROP, LOG, REJECT, custom-chain, etc...

wenn z.B. ipt_LOG nicht geladen ist, kann ich das Target LOG nicht benutzen und obige Fehlermeldung kommt, ebenso bei REJECT und fehlendem ipt_REJECT etc.

Wenn Du alle Module im Image hast und autoload kernel modules wie beschrieben aktiviert ist, dann kann es nur noch an der Syntax oder einer fehlenden custom chain liegen.

Beispiel:

iptables -A wurzelbrunft -j ACCEPT ​

bringt den Fehler, wenn Du nicht vorher die kette wurzelbrunft ordentlich mit:

iptables -N wurzelbrunft​

angelegt hast.

 

[sf3978]

Man muss den Befehl mal posten, der den Fehler verursacht.

Siehe Beiträge # 9 und # 14.

 

[cando]

Exit Code 0 - iptables -t filter -A INPUT -i wlan -p tcp --dport 53 -j ACCEPT

und der Befehl ist, wie erwartet in der Kette.

exit code 0 bedeutet OK.

Hast Du das Modul xt_tcpudp geladen? (modprobe xt_tcpudp in der experten Zeile eingeben)
Welche Module geladen sind, kannst Du mit dem Button check status oder in der Kommandozeile mit lsmod abfragen.

und es ist kein syntax problem

iptables -t filter -I INPUT 2 -i wlan -p tcp --dport 53 -j ACCEPT

bedeutet, in der tabelle -t filter, Kette INPUT an der 2. Stelle eine Regel einzufügen I mit folgenden Parametern:

-i wlan : input-interface: wlan (muss vorhanden sein)
-p tcp : protokoll tcp (muss unterstützt werden - xt_tcpudp)
--dport 53 : ziel-Port 53
-j ACCEPT : Verkehr wird zugelassen

 

[Desertbum]

Genau das war auch meine Frage.

iptables: No chain/target/match by that name
Exit Code 0 - iptables -t filter -A INPUT -i wlan -p tcp --dport 54 -j ACCEPT

Wenn diese Meldung kommt erscheint diese Regel nicht im Interface von NHIPT.
Wenn ich im Terminal iptables -L eingebe erscheint diese Regel auch nicht (trotz Exit Code 0)

Nur wenn ich multiport aktiviere (s.o.) erscheint die Regel.

Rätselhaft.

Erst nachdem ich manuell mit modprobe xt_tcpudp dieses Modul geladen habe taucht im im Staus auf.
Ich habe aber automatic modul loading im replace kernel aktiviert (?)

 

[RalfFriedl]

Was bedeutet das hier?

iptables: No chain/target/match by that name

Es bedeutet, daß keine Library nachgeladen werden kann, die für chain/target/match zuständig ist. Leider ist die Meldung nicht sonderlich konkret. Das einfachste ist, "strace -efile iptables ..." laufen zu lassen.

Sinnvoll wäre auch, die Meldung aussagekräftiger zu machen.

 

[cando]

Natürlich, nur kommt die Meldung vom Netfilter Projekt so dass wir keinen Einfluss darauf haben. Bist Du sicher, dass du im replaced Kernel tatsächlich autoload modules an hast und dass diese Konfig in Deinem Image ist?

Mein xt_tcpudp wird automatisch geladen. Wenn Du nach Deiner Modifikation des Kernels svn up oder ähnliches gemacht hast, hat es Dir jemand wieder deaktiviert. (SilentTiers hat es beim vorletzten Einbinden in den Trunk als Regel zurückgesetzt und ich musste meinen Schalter nach dem Auschecken noch mal setzen.

Übrigens, wenn Du persist rules machst, werden alle bereits geladenen Module Resetfest im Startscript hinterlegt, also auch das nachgeladene xt_tcpudp, so dass es künftig stets zur Verfügung steht.

Das Verhalten bei fehlendem xt_tcpudp ist normal, da das das Modul ist, das einzelne Ports beider Protokolle behandelt. Multiport ersetzt und erweitert xt_tcpudp.

 

[Desertbum]

Obwohl ich alle erdenklichen Module beim make menuconfig aktiviert hatte (xt_tcpudp wurden manuell geladen) erscheinen in Status nur ein paar.
Ist das in Ordnung?

modules loaded :
ip_conntrack
ip_conntrack_ftp
ip_tables
ipt_LOG
ipt_REJECT
iptable_filter
x_tables
xt_multiport
xt_state
xt_tcpudp
STATUS_changed=...NOT SAVED!
STATUS_directory_backup=...PASSED
STATUS_iptables=...PASSED
STATUS_admin_set=...PASSED
Exit Code 0 - Installation Status

 

[Desertbum]

OK cando,

du warst schneller.
Ich check nochmal mein make menuconfig und make kernel-menuconfig

Grüße

Desertbum

 

[cando]

Ja, das ist normal.

freetz lädt beim ersten Aufruf "manuell" folgende module, falls vorhanden:

[B]DEFAULT_MODULES="ip_tables iptable_filter x_tables ip_conntrack ip_conntrack_ftp ipt_LOG ipt_REJECT xt_multiport xt_state"

[/B]

Auch die autoload Funktion des Kernels lädt auch nur die bei irgend einem Aufruf gerade benötigten Module, nicht mehr benötigte werden aber leider nicht wieder automatisch entladen.

Ich vermute mal, dass die bei Dir geladenen Module allesamt "manuell" vom Freetz beim ersten Aufruf geladen wurden, und dass Dein Autoload nicht an ist.

 

[RalfFriedl]

Natürlich, nur kommt die Meldung vom Netfilter Projekt so dass wir keinen Einfluss darauf haben.

Wir könnten dort eine Änderung beantragen oder selbst einen Patch erstellen.

Bist Du sicher, dass du im replaced Kernel tatsächlich autoload modules an hast und dass diese Konfig in Deinem Image ist?

Diese Meldung hat nichts mit den Modulen des Kernels oder mit autoload zu tun, sondern mit dem Userspace-Teil von iptables, also not den Dateien *.so. Wie bereits geschrieben, kann man mit strace feststellen, welche Datei nicht gefunden wird.

 

[cando]

Das ist eine algemeine Fehlermeldung. Wenn autoload an ist (was der Standard bei den Linux distributionen ist), werden die Module geladen und die Meldung zeigt tatsächlich was sinnvolles an, nämlich, dass tatsächlich die Chain für die Regel noch nicht angelegt wurde oder das Target eine Chain ist, die (noch) nicht existiert, bzw ein Target, das im Kontext nicht zulässig ist. Ist übrigens im Handbuch im Hauptthread als allgemeine und auf dem ersten Blick unverständliche Meldung vom Author beschrieben - also allgemein bekannt.

Übrigens würde ich mich auf den Userspace von iptables nicht so verbeissen, das ist nur ein UI um die kernel-Funktionalität von netfilter zu konfigurieren. Die Module werden für die Filterung des Verkehrs vom Kernel benötigt / benutzt und müssen auch nachdem der iptables Aufruf in der shell beendet ist weiter arbeiten.

Wenn Du rmmod modulname machst, kannst Du nur module entladen, die in keiner bestehenden Regel mehr gebraucht werden. Alle anderen sind von netfilter im Kernel geblockt (eine Ausnahme sind die Module für die komlexen Spezialprotokolle im conntrack / nat Bereich: ftp, h323, irc, pptp, tftp, die sich entladen lassen, da hierfür keine speziellen Regeln erstellt werden, sondern diese aus dem daten context zur Laufzeit erkannt und wenn geladen benutzt werden).

Außerdem sind das *.ko module und keine *.so

./lib/modules/2.6.19.2/kernel/net/netfilter/xt_CLASSIFY.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_MARK.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_NFQUEUE.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_NOTRACK.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_comment.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_conntrack.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_esp.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_helper.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_length.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_limit.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_mac.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_mark.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_multiport.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_pkttype.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_quota.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_realm.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_state.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_statistic.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_string.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_tcpmss.ko
./lib/modules/2.6.19.2/kernel/net/netfilter/xt_tcpudp.ko

 

[RalfFriedl]

Außerdem sind das *.ko module und keine *.so

Was Du über die Kernel-Module geschrieben hast, ist richtig, aber ich meinte nicht die Kernel-Module, sondern wirklich die *.so Dateien.

Was den angesprochenen Patch betrifft, habe ich im SVN gerade einen eingebaut:

# ./iptables -A INPUT -j TEST
Extension (libipt_)TEST not found in /usr/lib/xtables
...

Ich denke, damit erspart man sich einiges an Rätselraten.

EDIT:
Ich sehe gerade, daß im Falle von nicht gefundenen User-Modulen sowieso schon der Name des Moduls angezeigt wurde.

 

[cando]

Nicht wirklich, denn TEST muss kein Modul sein. es kann ja auch eine User Chain sein, die man mit iptables -N TEST erzeugt...
Es muss also nicht unbedingt ein Modul fehlen, es kann auch an der Chain / Chain Target liegen. Insofern ist die originale
Fehlermeldung schon aussagekräftiger. Die .so Bibliotheken werden in der Regel sauber automatisch geladen, wenn sie
überhaupt vorhanden sind.

Die nicht geladenen / fehlenden Module, die Probleme bereiten sind stets Kernel module und fangen nicht mit libipt_an, sondern mit

[B]ip_*.ko
ipt_*.ko
xt_*.ko
iptable_*.ko
x_tables.ko[/B]

Das Problem tritt auf wenn der KMOD Kernel-Schalter aus ist. Dann muss man die Kernel-Module explizit von Hand mit modprobe oder insmod laden.
Die *.so Bibliotheken werden immer automatisch gebunden.

Die Fehlermeldungen zu den Bibliotheken sind außerdem etwas aussagekräftiger.

Die Entwickler haben den Fall, dass kernel module fehlen könnten einfach nicht ausreichend abgefangen. Der Fehler bubbelt hoch und default ist halt eine
fehlende Chain / oder Target (Chain), da alle anderen Meldungen spezifischer vom jeweiligen Modul kommen. Da das Modul aber erst gar nicht da ist,
kommt die allgemeine Meldung durch.

Ich würde an den Meldungen von iptables nicht herumpatchen. So kann man wenigstens in der ofiziellen Referenz nachsehen was los ist.
Mit eigenen "Fehlermeldungen" wird das Ganze intransparent und schlimmstenfalls fehlerhaft.

Damit:

Extension (libipt_)TEST not found in /usr/lib/xtables

kann man wirklich nichts anfangen, es fehlt ja kein Modul namens libipt_TEST und keiner weiss, wo er eins her bekommt.

 

[RalfFriedl]

Ich habe es mittlerweile auch gemerkt.

 

[sf3978]

[...]
Nur wenn ich multiport aktiviere (s.o.) erscheint die Regel.

Rätselhaft.
[...]

@Desertbum
Versuch mal die Regel ohne NHIPT, d. h. über die Konsole einzugeben.

 

[cando]

Ist doch schon lange erledigt. xt_tcpudp war nicht geladen und vermutlich autoload kernel modules (KMOD) aus.

 

[Silent-Tears]

Der kernelmodul-autoloader ist auch per default aus in der kernelconfig, wie es sich wege nder auftretenden Fehler gehört.
Und da die meisten user nicht die kernel-config ände4rn, bzw. das kernel-menuconfig zur Hilfe rufen dabei kannst du davon ausgeehn, dass eben dies tatsächlich nciht der Fall war.

 

[cando]

@SilentTiers: Also Desertbum behauptet ja, er hätte vorher autoload im Kernel aktiviert. Offenbar wurde das aber wieder abgeschaltet - was nicht in Ordnung wäre. Es wäre auch sinnvoller, die "auftretenden" Fehler mal vernünftig zu analysieren, anstatt Basisfunktionen des Kernels zu deaktivieren. IMHO betrifft das nur die bluezutils, die eh noch nicht stabil auf der Box laufen. Übrigens ist bei mir der Schalter seit Langem an und ich habe keine negativen Effekte. Deshalb sollte wenigstens das dauernde Zurücksetzen von KMOD aus dem Trunk raus. Man muss es ja nicht automatisch für alle aktivieren, aber auch nicht zwangsweise dauernd ausschalten. Einfach mal nur dem Benutzer überlassen.

...
Rätselhaft.

Erst nachdem ich manuell mit modprobe xt_tcpudp dieses Modul geladen habe taucht im im Staus auf.
Ich habe aber automatic modul loading im replace kernel aktiviert (?)

 

[Silent-Tears]

Die config wird nicht einfach zurückgesetzt. Imho wenn überhaupt beim neu auschecken oder vllt. noch nem distclean, ansonsten nicht. Und ob ein Paket wie bluezutils weniger sinnig und experiementeller als nhipt lassen wir mal aussen vor, denn ich erinnere mich noch grob, dass wir das autoload absichtlich ausgestellt haben, bevor bluez-uitls überhaupt dabei war. Allerdings ist der Grund dabei nicht mehr so ganz präsent


Schilder also bitte mal (in nem neuen Thread), unter welchen Gegebenheiten deine Kernelconfig automatisiert geändert wurde, damit dort ein System zu erkennen ist, das nachgestellt werden kann und vor allem anaysiert werdne kann, was du tust, was andere nicht tun, damit eben dies passiert, denn das trunk-Verzeichnis, in dem ich dein nhipt damals integriert habe, exisitiert noch mit dieser kerneländerung, auch wenn ich es nicht mehr nutze.

 

[cando]

Nun ja, ich baue ja nicht täglich eine neue Firmware. Meine letzte Version ist die 54.04.76freetz-devel-3977M , die stabil läuft und alles enthält, was ich brauche. Ich musste den Kernel Schalter aber schon ein paar mal bei der Entwicklung überprüfen und neu setzen bei svn up.

Da Desertbum offenbar fest geglaubt hat, er hätte autoload an im Kernel - tatsächlich der Schalter aber wirkungslos / aus zu sein scheint (was mir beim ersten mal auch passiert ist - seitdem überprüfe ich die Kernel Config immer vor dem Bauen und musste wie gesagt, schon ab und an den Schalter wieder setzen) gehe ich davon aus, dass er in die selbe Falle getappt ist, wie ich.

Nun habe ich aber keine weitere Rückmeldung hier im Forum, ob es tatsächlich daran lag oder nicht. Fakt ist, dass die Module bei ihm nicht automatisch geladen wurden - obwohl er behauptet er hätte autoload an im replaced kernel. Fakt ist auch, dass durch das manuelle Laden von xt_tcpudp der gemeldete "Fehler" weg ist, was die Vermutung erhärtet.

Der Rest ist Schlußfolgerung anhand der Indizien / Vermutung.