21 Jul
2011
21 Jul
'11
3:33 a.m.
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?
21 Jul
21 Jul
6:56 a.m.
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=660d20261343e0b2ff57e…
Kind regards,
Sven
7:28 a.m.
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(a)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=660d20261343e0b2ff57e…
Kind regards,
Sven
8:23 a.m.
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
9:14 a.m.
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(a)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
9:23 a.m.
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
9:32 a.m.
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
10:20 a.m.
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
28 Jul
28 Jul
12:06 p.m.
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
4263
days inactive
4270
days old
b.a.t.m.a.n@lists.open-mesh.org
8 comments
3 participants
participants (3)
-
Andrew Lunn -
Nik M. Anas Kamarudin -
Sven Eckelmann