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
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
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
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
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
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
Hi!
It is possible to announce a network behind a router without exposing it on L2? So that you would have nodes and clients meshed in L2, but subnets behind nodes are only routed to?
In what shape is L3 batman implementation?
Mitar
On Thu, Apr 12, 2012 at 05:13:33PM +0200, Mitar wrote:
Hi!
It is possible to announce a network behind a router without exposing it on L2? So that you would have nodes and clients meshed in L2, but subnets behind nodes are only routed to?
In what shape is L3 batman implementation?
L3 problems are L3 problems. So you need OSPF, RIP, BPG, etc, to solve your L3 routing. This works well, i've had OSPF routers talked to each other over the mesh, so building a routed network of multiple subnets, some subnets being mesh, some being plain old ethernet.
Your DHCP server could announce a default route which might be enough, depending on your network topology. BATMAN also has the ability to filter DHCP requests so that the "nearest" DHCP server replies, and that server could have a different default route as all the other DHCP servers on the mesh.
Or, if you are in a transition phase, and don't mind your head exploding, run olsr, babel, etc, on top of BATMAN to gateway between the L2 meshes!
Andrew
Hi!
On Thu, Apr 12, 2012 at 5:36 PM, Andrew Lunn andrew@lunn.ch wrote:
Or, if you are in a transition phase, and don't mind your head exploding, run olsr, babel, etc, on top of BATMAN to gateway between the L2 meshes!
Can you please explain a bit more what are you thinking here?
Mitar
On Thu, Apr 12, 2012 at 07:12:08PM +0200, Mitar wrote:
Hi!
On Thu, Apr 12, 2012 at 5:36 PM, Andrew Lunn andrew@lunn.ch wrote:
Or, if you are in a transition phase, and don't mind your head exploding, run olsr, babel, etc, on top of BATMAN to gateway between the L2 meshes!
Can you please explain a bit more what are you thinking here?
Well, your infrastructure already speaks olsr, babel, or what every L3 mesh protocol you have. It knows how to advertise additional routes. So make one or more of your BATMAN nodes L2 mesh also a L3 mesh node. These L3 mesh nodes will see each other over the mesh, and they will see other L3 mesh nodes over what every network technology you have between L2 meshes. These L3 mesh nodes should also be the default router for the devices in the L2 mesh. The L2 mesh devices will send there packets to a L3 mesh node. It will then route it, maybe back over the mesh, or maybe over an inter mesh links, to where ever it needs to go. If ICMP redirect works on your L2 and L3 nodes, it should add host routes to the L2 nodes when they use the wrong gateway out of the L2 mesh.
Andrew
As we did L2 Mesh with AWDS for some years and are switching to batman-adv at the moment here my 2c.
a) Networks on L2 needs some more insight because wireless mesh isn't just like ethernet cable, even if it looks like. b) "leaking" subnets must be taken care of. Often the L3 network works fine without exactly knowing what happening "down below" and astonishingly one can see packets flowing around and been transported with L2 all over the mesh. c) VLAN on L2 helps alot in design of the network topoly ( VLAN over WIFI was no problem with AWDS - we will test this with batman-adv)
regards 3zl
2012/4/12 Andrew Lunn andrew@lunn.ch:
On Thu, Apr 12, 2012 at 07:12:08PM +0200, Mitar wrote:
Hi!
On Thu, Apr 12, 2012 at 5:36 PM, Andrew Lunn andrew@lunn.ch wrote:
Or, if you are in a transition phase, and don't mind your head exploding, run olsr, babel, etc, on top of BATMAN to gateway between the L2 meshes!
Can you please explain a bit more what are you thinking here?
Well, your infrastructure already speaks olsr, babel, or what every L3 mesh protocol you have. It knows how to advertise additional routes. So make one or more of your BATMAN nodes L2 mesh also a L3 mesh node. These L3 mesh nodes will see each other over the mesh, and they will see other L3 mesh nodes over what every network technology you have between L2 meshes. These L3 mesh nodes should also be the default router for the devices in the L2 mesh. The L2 mesh devices will send there packets to a L3 mesh node. It will then route it, maybe back over the mesh, or maybe over an inter mesh links, to where ever it needs to go. If ICMP redirect works on your L2 and L3 nodes, it should add host routes to the L2 nodes when they use the wrong gateway out of the L2 mesh.
Andrew
Hi!
On Thu, Apr 12, 2012 at 2:00 PM, Antonio Quartulli ordex@autistici.org wrote:
but only when the packet format (or something really crucial) is touched.
But couldn't the packet format be made so that unknown values in there are simply ignored? And also ignore unknown packet types? So that at least connectivity is possible, but not as good as it could be? For example, if we have some node which reconnects after a month, it would be great that it still is able to connect, so that we can at least upgrade it.
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.
And it would also see all nodes as directly connected together? So:
[nodeA] --- [tunA on server, tunB on server] --- [nodeB]
If I bridge tunA and tunB together, nodeA will think that there is only one hop to nodeB, no?
Mitar
On Thursday, April 12, 2012 19:10:42 Mitar wrote:
On Thu, Apr 12, 2012 at 2:00 PM, Antonio Quartulli ordex@autistici.org
wrote:
but only when the packet format (or something really crucial) is touched.
But couldn't the packet format be made so that unknown values in there are simply ignored? And also ignore unknown packet types? So that at least connectivity is possible, but not as good as it could be? For example, if we have some node which reconnects after a month, it would be great that it still is able to connect, so that we can at least upgrade it.
Yes, exactly that is on the feature todo list (and more) to ensure better backward compatibility in the future.
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.
And it would also see all nodes as directly connected together? So:
[nodeA] --- [tunA on server, tunB on server] --- [nodeB]
If I bridge tunA and tunB together, nodeA will think that there is only one hop to nodeB, no?
Correct.
Regards, Marek
Hi!
On Thu, Apr 12, 2012 at 12:36 PM, Gioacchino Mazzurco gmazzurco89@gmail.com wrote:
and we managed have some compatibility break in updates without problem just start to update from the fairest node to the yours
This works if all nodes are online at that time ...
In batman-adv you can add/remove interfaces at runtime without problems so you doesn't need bridging or similar nasty things
Great. Can you also say to work on all "tun+" interfaces, so that any interface which starts with "tun" is automatically operated on?
Mitar
On Thursday, April 12, 2012 19:05:54 Mitar wrote:
In batman-adv you can add/remove interfaces at runtime without problems so you doesn't need bridging or similar nasty things
Great. Can you also say to work on all "tun+" interfaces, so that any interface which starts with "tun" is automatically operated on?
No, batman-adv is not a user space daemon with a configuration file, hence you can't tell batman-adv to wait for tun+. However, you can easily write a simple shell script for hotplug which adds whatever interface you want to batman-adv as soon as it is created. Or, if you are using OpenWrt, you can simply extend the existing hotplug shell script to interprete the "+" as you like.
Regards, Marek
On Fri, Apr 13, 2012 at 12:17:31AM +0200, Marek Lindner wrote:
On Thursday, April 12, 2012 19:05:54 Mitar wrote:
In batman-adv you can add/remove interfaces at runtime without problems so you doesn't need bridging or similar nasty things
Great. Can you also say to work on all "tun+" interfaces, so that any interface which starts with "tun" is automatically operated on?
No, batman-adv is not a user space daemon with a configuration file, hence you can't tell batman-adv to wait for tun+. However, you can easily write a simple shell script for hotplug which adds whatever interface you want to batman-adv as soon as it is created. Or, if you are using OpenWrt, you can simply extend the existing hotplug shell script to interprete the "+" as you like.
A little remark here. You MUST use interfaces that support ethernet frames transmission. Therefore (IIRC) you can use tap interfaces but not tun ones.
Cheers,
Hi!
On Fri, Apr 13, 2012 at 8:22 AM, Antonio Quartulli ordex@autistici.org wrote:
A little remark here. You MUST use interfaces that support ethernet frames transmission. Therefore (IIRC) you can use tap interfaces but not tun ones.
L2TP tunnel is creates a L2 tun interface, no?
Mitar
On Fri, Apr 13, 2012 at 09:29:27AM +0200, Mitar wrote:
Hi!
On Fri, Apr 13, 2012 at 8:22 AM, Antonio Quartulli ordex@autistici.org wrote:
A little remark here. You MUST use interfaces that support ethernet frames transmission. Therefore (IIRC) you can use tap interfaces but not tun ones.
L2TP tunnel is creates a L2 tun interface, no?
First, of, lets make sure we are all using tun/tap correctly. I know i keep having the check which is which.
http://en.wikipedia.org/wiki/TUN/TAP
TAP (as in network tap) simulates a link layer device and it operates with layer 2 packets such as Ethernet frames. TUN (as in network TUNnel) simulates a network layer device and it operates with layer 3 packets such as IP packets. TAP is used to create a network bridge, while TUN is used with routing.
So a tap interface can be added to BATMAN and become part of the L2 mesh.
tun cannot be added to batman. You need to perform L3 routing over the interface.
Which implementation are you using of L2TP?
Andrew
Hi!
On Fri, Apr 13, 2012 at 9:43 AM, Andrew Lunn andrew@lunn.ch wrote:
Which implementation are you using of L2TP?
We are not using any, we are planning to use ones provided by OpenL2TP:
We are hoping to use UDP as transport and do L2 tunnels. I was lead to believe that this is achievable with OpenL2TP. But I must admit I do not know which type of interface it creates.
Mitar
On Fri, Apr 13, 2012 at 09:51:51AM +0200, Mitar wrote:
Hi!
On Fri, Apr 13, 2012 at 9:43 AM, Andrew Lunn andrew@lunn.ch wrote:
Which implementation are you using of L2TP?
We are not using any, we are planning to use ones provided by OpenL2TP:
Never used it, so i "use the source luke", since its in the kernel...
Looks like you have at least two options:
Linux PPP over L2TP (PPPoX/PPPoL2TP) Sockets L2TPv3 ethernet pseudowire driver
PPP is L3 only, so you cannot add it to BATMAN. You would need to L3 routing over it.
The pseudowire driver creates a network device l2tpeth0, l2tpeth1, l2tpeth2, etc, one for each session. Looks like you should be able to add these to BATMAN.
Andrew
Hi!
On Fri, Apr 13, 2012 at 10:26 AM, Andrew Lunn andrew@lunn.ch wrote:
The pseudowire driver creates a network device l2tpeth0, l2tpeth1, l2tpeth2, etc, one for each session. Looks like you should be able to add these to BATMAN.
Yes. This was what we were targeting. Hopefully we can make it go over UDP.
Mitar
13 apr 2012 kl. 09:29 Mitar wrote:
On Fri, Apr 13, 2012 at 8:22 AM, Antonio Quartulli ordex@autistici.org wrote:
A little remark here. You MUST use interfaces that support ethernet frames transmission. Therefore (IIRC) you can use tap interfaces but not tun ones.
L2TP tunnel is creates a L2 tun interface, no?
Just asking to educate myself.
Why would you use L2TP rather than just IPsec? With KLIPS you would get a ethernet style device ipsec0, that should work fine with batman, no?
Hi!
On Fri, Apr 13, 2012 at 10:52 AM, Christian Huldt christian@solvare.se wrote:
Just asking to educate myself.
I am also doing that.
Why would you use L2TP rather than just IPsec?
We want UDP transport. Does IPsec tunnels support that? And furthermore, we do not want/need encryption. The main reason for going to L2TP is that currently we are using OpenVPN for our L2 tunnels and have problems that our links are CPU bound and not bandwidth bound. So we would like to go to a in-kernel solution and probably without encryption. (I doubt that Fonera can encrypt 20 Mbit/s. I even doubt it can route that over L2TP. But I hope it will be better then current 5 Mbit/s limit.)
Mitar
On Fri, Apr 13, 2012 at 03:32:59PM +0200, Mitar wrote:
Hi!
On Fri, Apr 13, 2012 at 10:52 AM, Christian Huldt christian@solvare.se wrote:
Just asking to educate myself.
I am also doing that.
Why would you use L2TP rather than just IPsec?
We want UDP transport.
Why?
Does IPsec tunnels support that?
Don't think so. Its a L3 solution, not L4.
And furthermore, we do not want/need encryption. The main reason for going to L2TP is that currently we are using OpenVPN for our L2 tunnels and have problems that our links are CPU bound and not bandwidth bound.
Did you try:
auth none cipher none
Andrew
Hi!
On Fri, Apr 13, 2012 at 3:50 PM, Andrew Lunn andrew@lunn.ch wrote:
We want UDP transport.
Why?
Because it easier goes through consumer firewalls than some non-TCP non-UDP IP packets.
Mitar
b.a.t.m.a.n@lists.open-mesh.org
-
3zl Trizonelabs -
Andrew Lunn -
Antonio Quartulli -
Christian Huldt -
Gioacchino Mazzurco -
Marek Lindner -
Mitar