Hi Antonio,
Then I tried to block any kind of packets from a known mac (say MACa).
# ebtables -A INPUT -s MACa -j DROP
After this I checked with "battctl o" if I was still able to see the other host, and even waiting a few minutes, the host was still in the list.
I tried it on two routers with ebtables and iptables here, too. I fired away all (redundant and like the forwarding stuff usually even useless) commands that came to my mind that could possibly block ANY traffic at all: --- ebtables -A INPUT -j DROP ebtables -A OUTPUT -j DROP ebtables -A FORWARD -j DROP ebtables -t broute -A BROUTING -j DROP ebtables -t nat -A PREROUTING -j DROP iptables -I INPUT -m physdev --physdev-is-in -j DROP iptables -I OUDPUT -m physdev --physdev-is-out -j DROP iptables -I FORWARD -m physdev --physdev-is-brigded -j DROP --- Of course, no ssh connection and stuff like that and basically no other communication got through... despite batman-adv's OGMs and batping packets, looking at that over a serial console! So it looks like batman-adv is getting hold of the OGMs before any filtering rules of the iptables/ebtables modules can get hold of them.
Additionally, the iptables/ebtables packet counts didn't seem to recognise any packets.
So it looks like either this is intended and batman-adv is also a very stealthy super-trojan (but couldn't find any proof for this in the source code yet ;) ) or batman-adv is just mistakenly catching them (and maybe even dropping them although the skb-copy should prevent this?) before the kernel or any other (filtering) kernel modules could have a glance at them.
I'm sorry having said that this should work on IRC before, but filtering (even bridged) arp/ip-packets over bat0 works like a charm - hadn't tried filtering raw batman-adv ethernet frames yet.
Cheers, Linus ___________________________________________________________ GRATIS: Movie-Flat mit über 300 Top-Videos. Für WEB.DE Nutzer dauerhaft kostenlos! Jetzt freischalten unter http://movieflat.web.de