[B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Nik M. Anas Kamarudin]

Hello all,

I need some help with batmand-adv packet filtering on wireless interface.
I successfully filter batman-adv packet using ebtables. This what i do:

/usr/sbin/brctl addbr br0
/usr/sbin/brctl addif br0 eth0
/sbin/ifconfig br0 up
/sbin/ifconfig eth0 192.168.5.2 up

then wait around 15 ~ 30 second.

/sbin/modprobe /lib/modules/`2.6.35.13/batman-adv/batman-adv.ko
/usr/sbin/batctl if add br0
/sbin/ifconfig bat0 192.168.5.41 up
/sbin/ifconfig br0 192.168.5.1 up

and filter up the batman-adv packet using etables like this:
`/usr/sbin/ebtables -A INPUT -s AA:AA:AA:AA:AA -j DROP`

BUT, this only work for Ethernet interface/ wire.. i need to do this
same thing using wireless interface. Anyone got any ideas?

Re: [B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On Thursday 21 July 2011 11:33:55 Nik M. Anas Kamarudin wrote:
[...]
> /sbin/modprobe /lib/modules/`2.6.35.13/batman-adv/batman-adv.ko
> /usr/sbin/batctl if add br0
> /sbin/ifconfig bat0 192.168.5.41 up
> /sbin/ifconfig br0 192.168.5.1 up

Why has br0 an IP address (and one which seems to be in the same subnet
like the one from bat0)?

> and filter up the batman-adv packet using etables like this:
> `/usr/sbin/ebtables -A INPUT -s AA:AA:AA:AA:AA -j DROP`
> 
> BUT, this only work for Ethernet interface/ wire.. i need to do this
> same thing using wireless interface. Anyone got any ideas?

Why shouldn't that work on wireless interfaces? Maybe you should provide more
information about your problem or your statement is just wrong. Just to
provide a easy to reproduce counterexample: Take your standard ath9k master
interface, add it to a bridge and add the correct ebtables filter rules
(depends on the actual scenario, but just assume INPUT, FORWARD and OUTPUT
of of the filter table with the source/destination macs and DROP target).

And there is still the possibility to revert and extend
 http://git.open-mesh.org/?p=batman-adv.git;a=commit;h=660d20261343e0b2ff57e51e50d7eb0e557d5e5b

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Nik M. Anas Kamarudin]

I think this is misunderstanding.  This method work fine on wire
interface because it use ebtables to filter the batman-adv packet, and
ebtables need to be use with bridge interface.

And why this method don't work on wireless, is simply because you
can't create bridge interface with wireless interface.  That why ask,
if anyone here got another idea on how to filter the batman-adv
packet. I provide the example above to show what i done, if others can
do same thing but different way.

About the br0, you can make the br0 work with or without IP.

On 7/21/11, Sven Eckelmann <sven@narfation.org> wrote:
> On Thursday 21 July 2011 11:33:55 Nik M. Anas Kamarudin wrote:
> [...]
>> /sbin/modprobe /lib/modules/`2.6.35.13/batman-adv/batman-adv.ko
>> /usr/sbin/batctl if add br0
>> /sbin/ifconfig bat0 192.168.5.41 up
>> /sbin/ifconfig br0 192.168.5.1 up
>
> Why has br0 an IP address (and one which seems to be in the same subnet
> like the one from bat0)?
>
>> and filter up the batman-adv packet using etables like this:
>> `/usr/sbin/ebtables -A INPUT -s AA:AA:AA:AA:AA -j DROP`
>>
>> BUT, this only work for Ethernet interface/ wire.. i need to do this
>> same thing using wireless interface. Anyone got any ideas?
>
> Why shouldn't that work on wireless interfaces? Maybe you should provide
> more
> information about your problem or your statement is just wrong. Just to
> provide a easy to reproduce counterexample: Take your standard ath9k master
> interface, add it to a bridge and add the correct ebtables filter rules
> (depends on the actual scenario, but just assume INPUT, FORWARD and OUTPUT
> of of the filter table with the source/destination macs and DROP target).
>
> And there is still the possibility to revert and extend
> http://git.open-mesh.org/?p=batman-adv.git;a=commit;h=660d20261343e0b2ff57e51e50d7eb0e557d5e5b
>
> Kind regards,
> 	Sven

Re: [B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

On Thursday 21 July 2011 15:28:18 Nik M. Anas Kamarudin wrote:
> I think this is misunderstanding.  This method work fine on wire
> interface because it use ebtables to filter the batman-adv packet, and
> ebtables need to be use with bridge interface.
>
> And why this method don't work on wireless, is simply because you
> can't create bridge interface with wireless interface.  That why ask,
> if anyone here got another idea on how to filter the batman-adv
> packet. I provide the example above to show what i done, if others can
> do same thing but different way.

As explained in my counterexample, this statement is simply wrong. I am 100% 
sure that I use bridges together with wireless interfaces (ath9k+AP) and I 
can't take enough drugs to forget that. Either you have a specific situation 
where this is not possible (there are some of course) and have to say that or 
you are simply lying. But giving no information or lying will not help you at 
all.

> About the br0, you can make the br0 work with or without IP.

And now we bury the routing...

I don't see that you use specific routes which are set to the correct device. 
So let's assume that your routing table now has two entries for 192.168.5.0 
with different outgoing devices and that it chooses (for unknown reasons) to 
use the route over br0. The target you want to reach is not only one hop away 
and thus the actual nic can't reach it directly, but batman-adv would be able 
to forward the packet correctly. And now think about how useful it was to give 
br0 a conflicting ip (due to the same subnets).

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Nik M. Anas Kamarudin]

AP mode? Sry, forget to tell, i using in ad-hoc mode. Maybe i explain
more. I try to test batman-adv in MANET. In order to doing that, i
need to make a scenario that have changing in topology. That why i
need to filter some batman-adv packet, if not i need to move the node
myself in and out of wireless range.  So, anyone have any idea how to
filter batman-adv packet?

On 7/21/11, Sven Eckelmann <sven@narfation.org> wrote:
> On Thursday 21 July 2011 15:28:18 Nik M. Anas Kamarudin wrote:
>> I think this is misunderstanding.  This method work fine on wire
>> interface because it use ebtables to filter the batman-adv packet, and
>> ebtables need to be use with bridge interface.
>>
>> And why this method don't work on wireless, is simply because you
>> can't create bridge interface with wireless interface.  That why ask,
>> if anyone here got another idea on how to filter the batman-adv
>> packet. I provide the example above to show what i done, if others can
>> do same thing but different way.
>
> As explained in my counterexample, this statement is simply wrong. I am 100%
> sure that I use bridges together with wireless interfaces (ath9k+AP) and I
> can't take enough drugs to forget that. Either you have a specific situation
> where this is not possible (there are some of course) and have to say that
> or
> you are simply lying. But giving no information or lying will not help you
> at
> all.
>
>> About the br0, you can make the br0 work with or without IP.
>
> And now we bury the routing...
>
> I don't see that you use specific routes which are set to the correct
> device.
> So let's assume that your routing table now has two entries for 192.168.5.0
> with different outgoing devices and that it chooses (for unknown reasons) to
> use the route over br0. The target you want to reach is not only one hop
> away
> and thus the actual nic can't reach it directly, but batman-adv would be
> able
> to forward the packet correctly. And now think about how useful it was to
> give
> br0 a conflicting ip (due to the same subnets).
>
> Kind regards,
> 	Sven

Re: [B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

On Thursday 21 July 2011 17:14:28 Nik M. Anas Kamarudin wrote:
> AP mode? Sry, forget to tell, i using in ad-hoc mode. Maybe i explain
> more. I try to test batman-adv in MANET. In order to doing that, i
> need to make a scenario that have changing in topology. That why i
> need to filter some batman-adv packet, if not i need to move the node
> myself in and out of wireless range.  So, anyone have any idea how to
> filter batman-adv packet?

I already told you about it in the first mail what a solution could be. There
are two other solutions use the initial idea of ebtables and bridge.

The first one is to use 4 address mode with a compatible driver (I used
madwifi with one of the patches from http://madwifi-project.org/ticket/1131 ).

The second one (assuming that you are using a mac80211 based driver) that you
remove the checks at
 * http://git.open-mesh.org/?p=linux-
merge.git;a=blob;f=net/wireless/core.c;h=c22ef3492ee6f0b8f58f1d663c995a977a7bcc6b;hb=HEAD#l821
 * http://git.open-mesh.org/?p=linux-
merge.git;a=blob;f=net/wireless/util.c;h=4d7b83fbc32f0eb042e3a70e23d01d626a5add04;hb=HEAD#l854

and use the same MAC on the bridge and only one interface inside the bridge
(so the bridge is a transparent filter). I never tested it, but at least
sounds promising.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Thursday 21 July 2011 11:23:11 Sven Eckelmann wrote:
> I already told you about it in the first mail what a solution could be.
> There are two other solutions use the initial idea of ebtables and bridge.

Translation:

I already explained a different solution in the first mail. There are two 
other ideas which only use ebtables and a bridge.

Kind regards,
 	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Andrew Lunn]

On Thu, Jul 21, 2011 at 05:14:28PM +0800, Nik M. Anas Kamarudin wrote:
> AP mode? Sry, forget to tell, i using in ad-hoc mode. Maybe i explain
> more. I try to test batman-adv in MANET. In order to doing that, i
> need to make a scenario that have changing in topology. That why i
> need to filter some batman-adv packet, if not i need to move the node
> myself in and out of wireless range.  So, anyone have any idea how to
> filter batman-adv packet?

Hi Nik

You might want to consider using a network simulator/emulator. Use a
number of user mode linux nodes, or qemu nodes, connected together
using a virtual network. You can control the packets losses, paths
etc, much easier and dynamically.

Take a look at this page for an example:

http://www.open-mesh.org/wiki/open-mesh/Emulation

	Andrew

Re: [B.A.T.M.A.N.] Filtering BATMAN-ADV packet

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

On Thu, Jul 21, 2011 at 12:20:00PM +0200, Andrew Lunn wrote:
[...]
> You might want to consider using a network simulator/emulator. Use a
> number of user mode linux nodes, or qemu nodes, connected together
> using a virtual network. You can control the packets losses, paths
> etc, much easier and dynamically.
> 
> Take a look at this page for an example:
> 
> http://www.open-mesh.org/wiki/open-mesh/Emulation


Yes, this is an extreme good reminder. It cannot be used for performance 
analysis, but is quite good to test routing in extreme weird situation.

Only a small hint: Try to use qemu-kvm instead of qemu and enable KSM [1] when 
not enough memory is available to hold all virtual machines in memory.

Kind regards,
        Sven

[1] http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]