[Frage] ebtables verfügbar? Wie einbinden?

Du kannst das Testweise nach /mod/lib kopieren oder per LD_LIBRARY_PATH den “Unterordner“-Pfad für die Libraries angeben.
 
Arghh...
Code:
root@fritz:/var/mod/root# ebtables
Segmentation fault
root@fritz:/var/mod/root#
Wie bekommt man dem nun auf die Schliche?
 
Du könntest das mit strace oder so eingrenzen.
Ich habe mal ein statisches Binary gebaut, funktioniert das?
Code:
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$ file static 
static: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1, statically linked, with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, not stripped
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$ 
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$ mips-linux-strip --remove-section={.comment,.note,.pdr} static 
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$ 
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$ file static 
static: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, stripped
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$ 
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$ qemu-mips-static ./static 
ebtables v2.0.10-4 (December 2011)
Usage:
ebtables -[ADI] chain rule-specification [options]
ebtables -P chain target
ebtables -[LFZ] [chain]
ebtables -[NX] [chain]
ebtables -E old-chain-name new-chain-name

Commands:
--append -A chain             : append to chain
--delete -D chain             : delete matching rule from chain
--delete -D chain rulenum     : delete rule at position rulenum from chain
--change-counters -C chain
          [rulenum] pcnt bcnt : change counters of existing rule
--insert -I chain rulenum     : insert rule at position rulenum in chain
--list   -L [chain]           : list the rules in a chain or in all chains
--flush  -F [chain]           : delete all rules in chain or in all chains
--init-table                  : replace the kernel table with the initial table
--zero   -Z [chain]           : put counters on zero in chain or in all chains
--policy -P chain target      : change policy on chain to target
--new-chain -N chain          : create a user defined chain
--rename-chain -E old new     : rename a chain
--delete-chain -X [chain]     : delete a user defined chain
--atomic-commit               : update the kernel w/t table contained in <FILE>
--atomic-init                 : put the initial kernel table into <FILE>
--atomic-save                 : put the current kernel table into <FILE>
--atomic-file file            : set <FILE> to file

Options:
--proto  -p [!] proto         : protocol hexadecimal, by name or LENGTH
--src    -s [!] address[/mask]: source mac address
--dst    -d [!] address[/mask]: destination mac address
--in-if  -i [!] name[+]       : network input interface name
--out-if -o [!] name[+]       : network output interface name
--logical-in  [!] name[+]     : logical bridge input interface name
--logical-out [!] name[+]     : logical bridge output interface name
--set-counters -c chain
          pcnt bcnt           : set the counters of the to be added rule
--modprobe -M program         : try to insert modules using this program
--concurrent                  : use a file lock to support concurrent scripts
--version -V                  : print package version

Environment variable:
EBTABLES_ATOMIC_FILE          : if set <FILE> (see above) will equal its value

Standard targets: DROP, ACCEPT, RETURN or CONTINUE;
The target can also be a user defined chain.

Supported chains for the filter table:
INPUT FORWARD OUTPUT 
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$ 
joerg@Ubuntu-11:~/freetz-trunk_7390/source/target-mips_uClibc-0.9.32.1/ebtables-v2.0.10-4$

Dazu habe ich das Makefile gepatched, damit das Ziel "static" auch statisch gelinked wird.
 

Anhänge

  • ebtables_static_patch.tgz
    513 Bytes · Aufrufe: 12
  • ebtables_static.gz
    79.1 KB · Aufrufe: 12
Hallo,
also die static Variante funktioniert, ja. Nur ich habe ebenfalls versucht, dass makefile anzupassen, vergeblich. Der Freetz Buildaufruf gibt nicht den notwendien static-Aufruf mit.

Jetzt kann ich zwar das ebtables auf einem USB Stick starten, was ich auch probieren werde, aber das ins Freetz Image zu integrieren, als Static Variante, wäre schon besser.
 
ja, und wie?

Also, ich möchte nicht die vom Kollegen static gelinkte Datei in mein Image als "own" Datei übernehmen, sondern ebtables über make menuconfig auswählen, static linken, ins Image übernehmen lassen und dann das ganze gerne in die Freetz Entwicklung abgeben, damit ein neues interessantes Tool die Freetz Umgebung erweitert.
 
Das geht mit der ebtables.mk-Datei.
Also, ich möchte nicht die vom Kollegen static gelinkte Datei in mein Image als "own" Datei übernehmen,
Und warum nicht? Du kannst auch nichts Anderes als der Kollege machen.
... sondern ebtables über make menuconfig auswählen, static linken, ins Image übernehmen lassen und dann das ganze gerne in die Freetz Entwicklung abgeben, damit ein neues interessantes Tool die Freetz Umgebung erweitert.
Die Freetz Entwicklung hat andere Sorgen. ;-)
 
Das statisch gelinkte Binary ist bei mir mit 179k etwas kleiner, als das dynamische plus Libraries ( 6k + 181k) (du -h über das packages-Verzeichnis). Allerdings, ohne zu wissen ob und welches Binary überhaupt funktioniert...

Dieses Paket sollte ebtables auf beide Arten (statisch und dynamisch) bauen können. Die notwendigen Anpassungen für den Kernel und die Integration der Kernel-Module in ein Image ist nicht berücksichtigt.
Um es im "menuconfig" auszuwählen, muss ein Eintrag für das Paket in make/Config.in hinzugefügt werden.

EDIT: Den "segfault" bekomme ich hier auch, wenn ich das dynamisch gelinkte Binary nutze. Ich habe jetzt zwar herausgefunden, woher der kommt, aber nicht, wie ich das Sinnvoll beheben kann:

Durch die Optimierung werden scheinbar zumindest die "void _init(void)" aus den extensions nicht aufgerufen, und deshalb keine targets registriert.
In libebt.c kommt es dann in "ebt_initialize_entry" zu dem Aufruf ebt_find_target(EBT_STANDARD_TARGET)->used = 1; da keine targets registriert wurden, gibt "ebt_find_target(EBT_STANDARD_TARGET)" NULL und das "->used" gibt den segfault.

Wenn ich mit "-O1" optimiere, passiert das nicht, wohl aber mit stärkerer Optimierung.
Wenn aber das statische Binary sowieso kleiner ist, und es dort funktioniert, sehe ich kaum Bedarf, das jetzt noch weiter zu analysieren (ich kann es auch nicht)..

Ich habe mal ein weiteres "Paket" anheghängt, was nur das statische Binary baut und in der Config auch die ebtables-Module drin hat (hab ich jetzt für eine W701 mit 7170 Kernel gebaut, müsste man ggf für andere Kernel-Versionen anpassen).

Uii, funktioniert sogar:)

Box:
Code:
root@fritz:/var/mod/root# ebtables  -L --Lc
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
root@fritz:/var/mod/root# ebtables -A INPUT -s 00:11:22:33:44:55 -j DROP
root@fritz:/var/mod/root# 
root@fritz:/var/mod/root# ebtables  -L --Lc
Bridge table: filter

Bridge chain: INPUT, entries: 1, policy: ACCEPT
-s 0:11:22:33:44:55 -j DROP , pcnt = 0 -- bcnt = 0

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
root@fritz:/var/mod/root# 
root@fritz:/var/mod/root# 
root@fritz:/var/mod/root## auf dem PC MAC geändert und gepingt, s.u. 
root@fritz:/var/mod/root# 
root@fritz:/var/mod/root# 
Bridge table: filter

Bridge chain: INPUT, entries: 1, policy: ACCEPT
-s 0:11:22:33:44:55 -j DROP , pcnt = 3 -- bcnt = 138

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
root@fritz:/var/mod/root# arp -an
? (192.168.178.12) at 00:11:22:33:44:66 [ether]  on lan
root@fritz:/var/mod/root#

PC:
Code:
joerg@Ubuntu-11:~/freetz-trunk$ ping 192.168.178.2
PING 192.168.178.2 (192.168.178.2) 56(84) bytes of data.
64 bytes from 192.168.178.2: icmp_req=1 ttl=64 time=0.664 ms
64 bytes from 192.168.178.2: icmp_req=2 ttl=64 time=0.595 ms
64 bytes from 192.168.178.2: icmp_req=3 ttl=64 time=0.646 ms
64 bytes from 192.168.178.2: icmp_req=4 ttl=64 time=0.600 ms
^C
--- 192.168.178.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.595/0.626/0.664/0.034 ms
joerg@Ubuntu-11:~/freetz-trunk$ sudo ifconfig eth0:12 192.168.178.12  hw ether 00:11:22:33:44:55
joerg@Ubuntu-11:~/freetz-trunk$ ping 192.168.178.2
PING 192.168.178.2 (192.168.178.2) 56(84) bytes of data.
^C
--- 192.168.178.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

joerg@Ubuntu-11:~/freetz-trunk$ sudo ifconfig eth0:12 192.168.178.12  hw ether 00:11:22:33:44:66
joerg@Ubuntu-11:~/freetz-trunk$ ping 192.168.178.2
PING 192.168.178.2 (192.168.178.2) 56(84) bytes of data.
64 bytes from 192.168.178.2: icmp_req=1 ttl=64 time=2.73 ms
64 bytes from 192.168.178.2: icmp_req=2 ttl=64 time=0.916 ms
^C
--- 192.168.178.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.916/1.826/2.736/0.910 ms
joerg@Ubuntu-11:~/freetz-trunk$
 

Anhänge

  • ebtables_make.tgz
    1.6 KB · Aufrufe: 6
  • ebtables_make_staticonly.tgz
    1.8 KB · Aufrufe: 11
Zuletzt bearbeitet:
Hallo mal wieder,

neues Wochenende, neuer Versuch.
Danke erst einmal für die letzten make files, damit ließ sich schon eine Menge machen, aber leider noch nicht alles:
Code:
root@fritz:/var/mod/root# ebtables
ebtables v2.0.10-4 (December 2011)
Usage:
ebtables -[ADI] chain rule-specification [options]
ebtables -P chain target
ebtables -[LFZ] [chain]
ebtables -[NX] [chain]
ebtables -E old-chain-name new-chain-name

Commands:
--append -A chain             : append to chain
--delete -D chain             : delete matching rule from chain
--delete -D chain rulenum     : delete rule at position rulenum from chain
--change-counters -C chain
          [rulenum] pcnt bcnt : change counters of existing rule
--insert -I chain rulenum     : insert rule at position rulenum in chain
--list   -L [chain]           : list the rules in a chain or in all chains
--flush  -F [chain]           : delete all rules in chain or in all chains
--init-table                  : replace the kernel table with the initial table
--zero   -Z [chain]           : put counters on zero in chain or in all chains
--policy -P chain target      : change policy on chain to target
--new-chain -N chain          : create a user defined chain
--rename-chain -E old new     : rename a chain
--delete-chain -X [chain]     : delete a user defined chain
--atomic-commit               : update the kernel w/t table contained in <FILE>
--atomic-init                 : put the initial kernel table into <FILE>
--atomic-save                 : put the current kernel table into <FILE>
--atomic-file file            : set <FILE> to file

Options:
--proto  -p [!] proto         : protocol hexadecimal, by name or LENGTH
--src    -s [!] address[/mask]: source mac address
--dst    -d [!] address[/mask]: destination mac address
--in-if  -i [!] name[+]       : network input interface name
--out-if -o [!] name[+]       : network output interface name
--logical-in  [!] name[+]     : logical bridge input interface name
--logical-out [!] name[+]     : logical bridge output interface name
--set-counters -c chain
          pcnt bcnt           : set the counters of the to be added rule
--modprobe -M program         : try to insert modules using this program
--concurrent                  : use a file lock to support concurrent scripts
--version -V                  : print package version

Environment variable:
EBTABLES_ATOMIC_FILE          : if set <FILE> (see above) will equal its value

Standard targets: DROP, ACCEPT, RETURN or CONTINUE;
The target can also be a user defined chain.

Supported chains for the filter table:
INPUT FORWARD OUTPUT
root@fritz:/var/mod/root# ebtables -A INPUT -s 00:11:22:33:44:55 -j DROP
modprobe: can't load module ebtables (kernel/net/bridge/netfilter/ebtables.ko): invalid module format
The kernel doesn't support the ebtables 'filter' table.
root@fritz:/var/mod/root#
root@fritz:/var/mod/root# modprobe ebtables.ko
modprobe: can't load module ebtables.ko (kernel/net/bridge/netfilter/ebtables.ko): invalid module format
root@fritz:/var/mod/root#

Das kernel Modul ebtables.ko wurde von mir wie in den ersten Posts gebaut und liegt im Dateisystem vor: \\freetz-linux\freetz\freetz-trunk\kernel\modules-iks-16mb-7390_05.20\net\bridge\netfilter\

Wieder ein Schritt weiter, aber noch immer kein lauffähiges ebtables.
Hat noch jemand eine Idee?
 
Das sollte mit dem letzte .tar-File gehen. Hast du denn im neuen Untermenu dazu (im Config.in fürs “menuconfig“) die Kernelmodule gewählt? Dann sollten sie automatisch im Image landen, wenn sie im kernel-menuconfig angewählt wurden. Laden musst du sie dann noch von Hand.
 
Zuletzt bearbeitet:
Hallo,
ja das Modul ist im Kernel:
Code:
root@fritz:/var/mod/root# cd /lib/modules/2.6.28.10/kernel/net/bridge/netfilter/
root@fritz:/lib/modules/2.6.28.10/kernel/net/bridge/netfilter# ls
ebtables.ko
root@fritz:/lib/modules/2.6.28.10/kernel/net/bridge/netfilter#
Leider klappt es nicht:
Code:
root@fritz:/lib/modules/2.6.28.10/kernel/net/bridge/netfilter# modprobe ebtables
.ko -v
modprobe: can't load module ebtables.ko (kernel/net/bridge/netfilter/ebtables.ko): invalid module format
root@fritz:/lib/modules/2.6.28.10/kernel/net/bridge/netfilter#
Dabei scheint alles in Odnung zu sein:
Code:
root@fritz:/var/mod/root# modprobe ebtables -D
insmod /lib/modules/2.6.28.10/kernel/net/bridge/netfilter/ebtables.ko
root@fritz:/var/mod/root#
Ausgabe von File auf dem freetz Linux:
Code:
freetz@freetz-linux:~$ file freetz-trunk/build/modified/filesystem/lib/modules/2.6.28.10/kernel/net/bridge/netfilter/ebtables.ko
freetz-trunk/build/modified/filesystem/lib/modules/2.6.28.10/kernel/net/bridge/netfilter/ebtables.ko: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), with unknown capability 0x41000000 = 0xf676e75, not stripped
freetz@freetz-linux:~$
Oder vielleicht auch nicht? Ausgabe von dmesg:
Code:
...
avm_pa: telephony inactive
ebtables: exports duplicate symbol ebt_do_table (owned by kernel)
ebtables: exports duplicate symbol ebt_do_table (owned by kernel)
ebtables: exports duplicate symbol ebt_do_table (owned by kernel)
ebtables: exports duplicate symbol ebt_do_table (owned by kernel)
ebtables: exports duplicate symbol ebt_do_table (owned by kernel)
 
Zuletzt bearbeitet:
Das liest sich für mich so als wäre ebtables schon im Kernel!?

Gruß
Oliver
 
Ja, leider waren wir schon mal soweit, nur diesesmal wird das Kernel-Modul implizit durch den Aufruf des Programms ebtables geladen. Ich wollte gerade alle Module wieder entfernen, muss aber mal das make dirclean aufrufen, da sich im Image immer wieder die ebtables.ko befindet, obwohl das Modul im make menuconfig abgewählt wurde.

Spricht eigentlich etwas gegen die Aufnahme aller ebtables Module in den Kernel? Im make menuconfig-kernel kann man es auswählen.
Muss dann noch im make menuconfig das (modul) ausgewählt werden? Meines Verständnisses nach nicht.
 
Alles was mit "make kernel-menuconfig" ausgewählt wird wird als Modul (oder fest ein-)gebaut. Nur das was du unter "menuconfig" auswählst (Module) kommt auch ins Image. Dabei musst du natürlich aufpassen, dass der Kernel zu den Modulen passt...

Gruß
Oliver
 
Die Option Replace Kernel ist deaktiviert, es muss sich also um den Originalkernel handeln.
 
Vielleicht haben wir in diesem Punkt nicht die richtige Konfiguration, AVM nimmt es da leider nicht so genau.

Versuch mal, in der kernel-config ebtables fest einzubauen und ob dann die restlichen Module dazu geladen werden können.
 
Hallo Leute,

es funktioniert! Ja, ich habe im Tinc Netz mit mehreren DHCP Servern alles blockiert, außer meinen eigenen in der lokalen Fritz Box.
"Replace Kernel" und die Static Bindung der KernelModule, die dann auch in den Kernel aufzunehmen waren die Lösung.
Falls jemand die ebtables Rules benötigt:
Code:
# block DHCP incoming/outgoing width ebtables
echo "create ebtables rules"
ebtables -A INPUT --in-interface tap0 --protocol 0x0800 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol 0x0800 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface tap0 --protocol 0x0800 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface tap0 --protocol 0x0800 --ip-protocol udp --ip-source-port 67:68 -j DROP
Anbei noch einmal die Dateien:
Anhang anzeigen ebtables_make_staticonly.tgz

Vielen Dank noch an alle, die mir geholfen haben! Jetzt muss das ganze nur noch auf eine 7170 portiert werden....


Gruß,

dwichmann
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,690
Beiträge
2,256,045
Mitglieder
374,664
Neuestes Mitglied
verrücktetmongo
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.