Then I tried to block any kind of packets from a known mac (say
# 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
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.
GRATIS: Movie-Flat mit über 300 Top-Videos. Für WEB.DE Nutzer
dauerhaft kostenlos! Jetzt freischalten unter http://movieflat.web.de