On Thu, Apr 12, 2012 at 12:36:27PM +0200, Gioacchino Mazzurco wrote:
Hao! Ma allora sei stronzo !!
As I understand, we should be migrating the whole network at same time each time a new version of Batman (or Linux kernel) is released, because you do not keep things backwards compatible? How serious is this limitation in practice?
It happen just some times not every batman/kernel version change. We use batman-adv in Ninux Pisa and in Ninux Sicily and we managed have some compatibility break in updates without problem just start to update from the fairest node to the yours
Up to now we had the so called "COMPATIBILITY VERSION". All the nodes must use the same compatibility version otherwise they will not be able to communicate to each other. However the compatibility version is not increased in each and every batman-adv release, but only when the packet format (or something really crucial) is touched.
I am also a bit afraid of L2 meshing. How problematic are floods in the network in practice? Like people broadcasting stuff and so on? Are there any filters possible for this?
II have tried to do something about filtering but without success, but we never encountered flooding problems nor in Pisa nor in Sicily
Actually it depends on what you want to filter. batman-adv itself doesn't support filtering. But what you can do is using "ebtables" (bridge version of iptables).
For example: If you are creating a bridge called br0 and enslaving bat0 and ap0, you can use ebtables to DROP all the broadcast packet that want to go out through bat0. Int his way you will limit the broadcast packets to the AP only.
By the way, I don't know if you really meant this kind of filtering.
We have a setup where nodes have WiFi connections and VPN links to central server. We are thinking of migration OpenVPN to L2TP tunnels, so on the central server there will be many tunnels dynamically created as nodes connect and disconnect. Is Batman able to add interfaces it operates during run-time? Probably we should not just bridge all tunnels and run Batman on top of that? This would probably hide that there are different links bellow from Batman? Or not? (For example, on OLSR we should not do this, because then nodes would discover each other over server as one hop/direct neighbors.)
In batman-adv you can add/remove interfaces at runtime without problems so you doesn't need bridging or similar nasty things
exactly. You can add/remove interfaces at run-time. Creating a bridge with all the tunnels would not be good because it would not make batman-adv exploit the interface diversity.
Cheers,
On 04/12/12 12:26, Mitar wrote:
Hi!
I really liked your client roaming support presented at Battlemesh. But I am still afraid to deploy Batman in the network. As I understand, we should be migrating the whole network at same time each time a new version of Batman (or Linux kernel) is released, because you do not keep things backwards compatible? How serious is this limitation in practice?
I am also a bit afraid of L2 meshing. How problematic are floods in the network in practice? Like people broadcasting stuff and so on? Are there any filters possible for this?
We have a setup where nodes have WiFi connections and VPN links to central server. We are thinking of migration OpenVPN to L2TP tunnels, so on the central server there will be many tunnels dynamically created as nodes connect and disconnect. Is Batman able to add interfaces it operates during run-time? Probably we should not just bridge all tunnels and run Batman on top of that? This would probably hide that there are different links bellow from Batman? Or not? (For example, on OLSR we should not do this, because then nodes would discover each other over server as one hop/direct neighbors.)
Mitar