27 Jul
2013
27 Jul
'13
4:03 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
My name is Pau from Barcelona. I have heard about your project in the
battlemesh mailing list. First of all, congratulations for starting
such kind of initiative, I hope you succeed.
In my place I'm working in the development of a Mesh firmware named
qMp [2] which is being used mainly in our community network Guifi.net
[3].
The purpose of sending this mail comes from what I read in your Wiki
[4] about create a new firmware. IMHO it is a mistake since there are
several projects already created, probably too much because we are
dividing our strength.
Recently (thanks to the battlemesh and other events like that) we have
started a new project to put all the development efforts together and
make a firmware generic and useful for everybody. The idea is to make
a meta-firmware which can be used as basis to create specific
community firmwares. The project is named libre-mesh [5].
Until now three existing mesh communities have joined: Guifi.net
(Catalonia), AlterMesh (Argentina), Eigennet (Italy). I would like to
invite you to participate. We have a huge experience in the
OpenWRT-based distributions for mesh networking, I hope you are able
to take advantage of it.
I don't pretend to start a large discussion about routing protocols,
but I would like to summary our conclusions because they can be useful
for us. Batman-adv is very nice, but you cannot have a single
collision domain cloud for all the nodes because it does not scale.
So, the network have to be splitted in several clouds. To federate
them a layer3 routing protocol is needed, so here is where we use BMX6
[7]. Why? because BMX6 (100% rewritten fork of Batmand with native
IPv6 support) is very powerful and produces a very low overhead (see
[6]). Here [8][9] find a couple of small diagrams to understand a
little better this model.
Cheers.
PS: do not use ARC Freestations, they use Ralink USB chips and driver
is bullshit in ad-hoc mode.
PS2: CCed Libre-Mesh mailing list
[1] mesh(a)lists.sudoroom.org
[2] http://qmp.cat
[3] http://guifi.net
[4] https://sudoroom.org/wiki/Mesh/Firmware
[5] http://libre-mesh.org
[6] https://libre-mesh.org/attachments/download/12/overhead_mobile.png
[7] http://bmx6.net
[8] https://libre-mesh.org/attachments/download/4/smartmesh2.png
[9] https://libre-mesh.org/attachments/download/17/lime-modes1.jpg
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9FHbAAoJEAX7rWpc+YnN1wsH/ROdF+IsNU8X9Ub0BslkEVw4
d0ixSUH2WQKwxd58iIf+4TbsH4SXHUQlm726KnCJMRx2hzZ9E/dyItrVvbrk9Vbw
YUS59VeVwqBqo39Pu16pxDoA4hrQa3yNi+Cq3CBOQlBh/oKf1r1OFNOznhkrzdNj
7pp/L146NSyl+TJ1U3nPpikf7AAvPVfU/ege/cLGrmDeP6rGdtArLJzGRDM/8syw
pQ/A75u11IyFs00EgJJufhG4ZSbKoZIaePOZAfONPKi+WxRJZsJw4IDxp7Gd3+wF
Dk5GPj5afDjSZpM8zxK88bwDUz6jW5S8V+pQd0+TnwcaqIrlYOqDI5ublyC9Z4s=
=Nr0g
-----END PGP SIGNATURE-----
27 Jul
27 Jul
4:30 p.m.
Hi!
The idea is to make a meta-firmware which can be used
as basis to
create specific community firmwares. The project is named libre-mesh
[5].
To throw a ball back at you: why another meta-firmware? We already have
OpenWrt. Why libre-mesh cannot be just one package for OpenWrt, which
configures and depends on anything you believe should be there? Then
other communities can just fork that package and adapt it. Or just add
additional packages.
Because I don't see firwmare anything more than just a list of packages
+ configuration + few small scripts. I don't see this as such big
additional split of work as you are describing. Or is there more to
firmware development?
Batman-adv is very nice, but you cannot have a single
collision domain cloud for all the nodes because it does not scale.
Have this been proven/shown anywhere? Aren't there Batman-adv mesh nodes
with 1000 nodes in existence (or in fact in Batman-adv you do not care
so much about the nodes, but about number of individual MAC addresses in
the mesh, including clients and anything bridged to the mesh)?
So, the network have to be splitted in several clouds.
To federate
them a layer3 routing protocol is needed, so here is where we use BMX6
[7].
Why would you need to use BMX6 to federate them? Isn't just Quaga with
Batman-adv on both sides enough on a gateway node between clouds? Or are
you saying that BMX6 should run on top of Batman clouds on all nodes and
not just on gateways?
Why? because BMX6 (100% rewritten fork of Batmand with
native
IPv6 support) is very powerful and produces a very low overhead (see
[6]).
But how does this overhead compare with speed of convergence (adaption
to the changes in the mesh). Because overhead is in general inversely
related to speed of convergence. More packets you send around, higher
the overhead is, faster you can inform everybody that there was a change
in topology. So this graph without a related graph of speed of how fast
the routing protocol adapted nodes is not really useful. So I am
interested in a scenario where somebody is actively talking to a node
which is moving around. If my connection to the node stays working while
in all cases, but one routing protocol has lower overhead to achieve
this, then this is a better routing protocol.
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
4:54 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well, this kind of discussions is what I was trying to avoid... but it
is my fault for starting it.
On 28/07/13 01:30, Mitar wrote:
Ask yo AlterMesh guys who are starting having problems with
scalability. Can you imagine which is the total amount of ARP packages
in a 1000 nodes bat-adv cloud? (just to put an example)
Quagga is a suit which includes several routing protocols. Quagga
could be used to federate bat-adv and bmx6. But if you are speaking
about use static routing, I would just say it is a big mistake (what
happens when you have to paths to the same cloud?).
I agree with your approach about compare overhead and routing changes.
However I can say this test was made during the WCW-Berlin. The
scenario was around 15-20 nodes (ask UFO to to know it better) in a
mobile scenario (it means someone moving nodes). All protocols were
running at same time in different VLAN (see battlemesh firmware in
github) so all of them were in the same situation. Just to give you
another detail, the tested protocol which showed more difference
between moving and not moving environment was Babel.
By the way, the conclusion of this tests was: BATMAN based protocols
are better in the overhead-mobile test.
Hi!
It is exactly what we are doing. Please see our repositories you will
find lime-packages which is an OpenWRT feed.
The idea is to make a meta-firmware which can be
used as basis
to create specific community firmwares. The project is named
libre-mesh [5].
To throw a ball back at you: why another meta-firmware? We already
have OpenWrt. Why libre-mesh cannot be just one package for
OpenWrt, which configures and depends on anything you believe
should be there? Then other communities can just fork that package
and adapt it. Or just add additional packages. Because I don't see firwmare anything more than
just a list of
packages + configuration + few small scripts. I don't see this as
such big additional split of work as you are describing. Or is
there more to firmware development?
Well, I would not say "few small scripts", it is a bit more than that.
I don't know about which firmware are you speaking about but in my
experience if you want to end up in a stable, powerful and flexible
system you need more than "few small scripts".
Batman-adv is
very nice, but you cannot have a single collision
domain cloud for all the nodes because it does not scale.
Have this been proven/shown anywhere? Aren't there Batman-adv mesh
nodes with 1000 nodes in existence (or in fact in Batman-adv you do
not care so much about the nodes, but about number of individual
MAC addresses in the mesh, including clients and anything bridged
to the mesh)? So, the
network have to be splitted in several clouds. To
federate them a layer3 routing protocol is needed, so here is
where we use BMX6 [7].
Why would you need to use BMX6 to federate them? Isn't just Quaga
with Batman-adv on both sides enough on a gateway node between
clouds? Or are you saying that BMX6 should run on top of Batman
clouds on all nodes and not just on gateways? Why? because
BMX6 (100% rewritten fork of Batmand with native
IPv6 support) is very powerful and produces a very low overhead
(see [6]).
But how does this overhead compare with speed of convergence
(adaption to the changes in the mesh). Because overhead is in
general inversely related to speed of convergence. More packets you
send around, higher the overhead is, faster you can inform
everybody that there was a change in topology. So this graph
without a related graph of speed of how fast the routing protocol
adapted nodes is not really useful. So I am interested in a
scenario where somebody is actively talking to a node which is
moving around. If my connection to the node stays working while in
all cases, but one routing protocol has lower overhead to achieve
this, then this is a better routing protocol.
Mitar
Cheers, Mitar. Hope to see you in October.
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9F2YAAoJEAX7rWpc+YnN2/UH/2Jo0bujrjXBwGwN2vP5oi+q
5O5w5jQZ6uQEaeruwEXrmtNeucY1p9yNkXLhxDnSFWYQup4Qt4KvAdJPOQ+/pjBf
7khnwvHgD9Pupce/F8dLbmgrdUTlmThZdrug1EQHPnHwekTHwPO6/DraDYgf6Pzf
NPu0QGQDFi0zk1sBbWxXeizvcmxXhgbID9yptp6p+XIn4wvJkAVw1d3N2jHcUDRe
fg/KBQeUsCqViwMnclylOwS6Q73UpJ6yW4wVAiphwS7KpZHYn+X/yYK0NbD8kQfL
3EtUufaUxoAUgfan1qQJcP8ItEV24ylrnkJTueV06/DP65NS3O2RykfOPwM6Tyo=
=skVf
-----END PGP SIGNATURE-----
5:50 p.m.
Hi!
Well, this kind of discussions is what I was trying to
avoid... but it
is my fault for starting it.
No no. It is important to discuss this things. You cannot just believe
that people would just take some firmware without trying to understand
it and reasons for why something is like it is and not some way around?
So don't see this as a flame but more as a way to teach/show.
It is exactly what we are doing. Please see our
repositories you will
find lime-packages which is an OpenWRT feed.
Great!
This maybe means that talking about "firmware" is not the right word.
But more about a set of packages? Because then it is easier to imagine
that another community network takes few of those packages and add few
theirs and maybe even then put them all together in one feed for later
community network to build upon.
So I think the most important thing is not to see firmware as one, but
to learn which problems/issues you already solved with which packages
and see how to build upon that and contribute back, no?
Well, I would not say "few small scripts",
it is a bit more than that.
I don't know about which firmware are you speaking about but in my
experience if you want to end up in a stable, powerful and flexible
system you need more than "few small scripts".
Can you maybe just show us few examples of such scripts? Just so that it
is easier to imagine what kind of things one have to think about when
developing a firmware?
Ask yo AlterMesh guys who are starting having problems
with
scalability. Can you imagine which is the total amount of ARP packages
in a 1000 nodes bat-adv cloud? (just to put an example)
So only ARP packets are the issue. Other broadcast packets you can
simply drop with a ebtables firewall rule. You can still use ZeroConf,
because it is multicast and not broadcast.
And for ARP packets Batman could probably provide some fake proxy, where
the node would answer them directly instead of broadcasting them around.
Or maybe tunnel them directly to the node who can answer them. (Because
Batman knows exactly where any MAC address in the network is. You do not
really have to broadcast around to get this.) In a similar way that
Batman currently handles DHCP by intercepting the packets and responding
itself.
So I am not sure that it is smart to add another layer (another routing
protocol) of complexity to the networking stack, where we could just
learn and build upon existing tools. As you said, if I paraphrase, not
yet another routing protocol. Cannot we have just one and all contribute
to that one? So if Batman works in most cases, let's fix those cases
where it does not.
Quagga is a suit which includes several routing
protocols. Quagga
could be used to federate bat-adv and bmx6. But if you are speaking
about use static routing, I would just say it is a big mistake (what
happens when you have to paths to the same cloud?).
So are you saying that BMX should be run over whole mesh on layer 3 with
Batman below on layer 2? Or are you saying that it should be used only
on gateways. I am not sure what exactly you are saying here. Do you have
some more concrete example/presentation of this idea? So how does one
packet travels around the network in your topology of BMX + Batman?
I agree with your approach about compare overhead and
routing changes.
However I can say this test was made during the WCW-Berlin.
For others, WCW is a yearly mesh-related even in Berlin, Wireless
Community Weekend:
http://wiki.freifunk.net/Wireless_Community_Weekend_2013
More locally targeted for the whole Freifunk community to get together
from all around the country, once a year. (So most of the stuff you will
find will probably be in German. :-) )
The scenario was around 15-20 nodes (ask UFO to to
know it better) in
a mobile scenario (it means someone moving nodes). All protocols
were running at same time in different VLAN (see battlemesh firmware
in github) so all of them were in the same situation.
Is there any description of the scenario? So if they were just moving
the nodes around without communicating with the node at the same time,
then this data is useless.
Just to give you another detail, the tested protocol
which showed
more difference between moving and not moving environment was Babel.
This might be just that Babel adapts in a smart way to the moving and
starts sending more updates. :-)
By the way, the conclusion of this tests was: BATMAN
based protocols
are better in the overhead-mobile test.
Yes. Their ways of updating the information about the network topology
is really interesting and charming. But sadly the overhead is not the
only thing which matters. Speed of convergence to new topology, no
routing loops, and no disruptions in service are other which are
important as well. Personally, I would not really care so much if
routing protocol has bigger overhead if this means it works for people.
And in general nodes do not really move around so much. Clients do
(Batman has roaming support for them), but nodes, not really. At least
until we have nodes installed on cars and bikes. Nodes do come up and
down and at that time it is not so important how fast new topology
converges, that is true.
Cheers, Mitar. Hope to see you in October.
Sadly, I will not have time to attend the summit this time. :-(
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
28 Jul
28 Jul
1:47 a.m.
New subject: [lime-dev] From libre-mesh
On Saturday 27 July 2013 17:50:07 Mitar wrote:
So are you saying that BMX should be run over whole
mesh on layer 3 with
Batman below on layer 2? Or are you saying that it should be used only
on gateways. I am not sure what exactly you are saying here. Do you have
some more concrete example/presentation of this idea? So how does one
packet travels around the network in your topology of BMX + Batman?
At moment there are multiple idea about that so at moment we are developing
in a non specifical manner...
Here is how i see the stuff:
Local mesh should use batman-adv for simpler approach to the user and goodies
like clients roaming, then those local meshes talk each other with BMX6
installed on gateways, from what i can remember BMX6 performed a lot better
than others on all different setup tryed in battlmesh ( correct me if I am
wrong ) moreover it has some goodies that make it very easy to use to make
mesh island talking each other accross internet , one example is the automatic
tunnelling, from what i understood using BMX6 you don't need to use a VPN like
tinc, BMX6 will do the tunnelling too with double gain
1) You don't need to configure the vpn
2) BMX6 known exactly the real topology of tunnels so can take better decision
in respect to other routing protocols that run on top of VPNs ( If i undestood
good tunnel made with tunnel digger doesn't suffer this problem because are
just tunnel not VPN )
Any way i think we should stop duplicatin work...
we have N map server, N firmware, N monitoring protocols and so on...
If we can join forces this would be a big gain and so we can have forces to
develop other kind of things too, just to trhow an example serverless
decentralized secure communication platform to use in the mesh...
5:50 p.m.
New subject: [lime-dev] From libre-mesh
Hi!
Local mesh should use batman-adv for simpler approach
to the user and goodies
like clients roaming, then those local meshes talk each other with BMX6
installed on gateways,
See. This point I don't understand. How exactly will this work. Let's
have a concrete example. We have two gateways in the network, one
default towards the Internet and one towards another mesh:
Internet
.
.
.
[gateway 1]
|
------------ ------------
| | | |
| mesh 1 |------[gateway 2]------| mesh 2 |
| | | |
------------ ------------
Mesh 1 is using (let's say we use IPv4) 10.1/16 and mesh 2 10.2/16.
When I connect with my laptop to mesh 1 I get with DHCP IP from 10.1/16
and for default gateway IP of gateway 1. Now, how can my laptop know
that for 10.2/16 it should route towards IP of gateway 2?
And moreover, why is there even a node for a wireless routing protocol
for this peering between mesh 1 and mesh 2? Wouldn't any routing
protocol (like BGP) be quit the same: nor BGP nor BMX6 would know
anything about underlying link quality *below* the Batman.
BMX6 will do the tunnelling too with double gain
1) You don't need to configure the vpn
So you mean tunnels are done automatically between all nodes in the
mesh? In a way similar to n2n (http://www.ntop.org/products/n2n/)?
2) BMX6 known exactly the real topology of tunnels so
can take better decision
in respect to other routing protocols that run on top of VPNs
This really just depends on how you configure your VPN. Even when we
were using OpenVPN, we just configured it so that all VPN tunnels were
not bridged together. This is the important step. If you have:
[node A]----[VPN server]----[node B]
L3 (or L2) routing protocol should not think that there is a direct link
between node A and node B. We were able to configure OpenVPN and n2n in
this way, so I am not sure this is a big problem with VPN solutions.
( If i undestood good tunnel made with tunnel digger
doesn't suffer
this problem because are just tunnel not VPN )
Yes, Tunneldigger rocks. :-) But from other reasons. You should
experience how it traverses NATs and firewalls and setups two-way
bandwidth limiting. :-)
(I think "tunnels" and "VPNs" are not the best defined terms here. I
am
not 100% sure what you meant here by them. But I assume with VPN you
mean something which combines all VPN clients into one big L2 network.)
Any way i think we should stop duplicatin work...
we have N map server, N firmware, N monitoring protocols and so on...
I agree completely. :-) We just have to agree on what we want to build
together. And for that such discussion (even if they consume a lot of
time) are important. We have to first understand each other.
If we can join forces this would be a big gain and so
we can have forces to
develop other kind of things too, just to trhow an example serverless
decentralized secure communication platform to use in the mesh...
You know that I am and always have been a big proponent of joining
forces. And this is why I am trying and taking time to understand what
is this new idea of combining Batman and BMX. I just don't get it.
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
2:43 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 28/07/13 02:50, Mitar wrote:
I like "firmware" more than "set of packages" because at the end
libre-mesh will be a firmware (software for embedded devices). But OK,
it is just a way to refer to the same thing.
Using ebtables is dirty and a patch to solve something that layer3
solves. And have you thought about IPv6? It does not have broadcast
but multicast link-local domains which can end-up in a big storm too
(RA announcements and requests).
Mitar, you have been in the BattleMesh before. You know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe the
results obtained are relevant since the elite of the mesh networking
was there.
I don't think so. Babel acts as a static protocol when the network is
not moving, but when it moves it produces a very very high overhead
(compared to other distance-vector protocols). I don't see this very
smart since for static deployments you could do the same using BGP or
OSPF.
Of course it is not the only important thing. However in the last
BattleMesh, BMX6 was the better in coverage time and in best-path
selection. You have the results raw data in the battlemesh web page.
Let me ask you something now. Is there any other "hacker" in this
project which knows about mesh networking? How many people do you have
working on firmware? I hope this conversation is useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Cheers
Hi!
Of course people should ask and understand before choosing some
specific existing solution. But I did not want to start this kind of
discussion here (in this post). I just wanted to let you know about
libre-mesh project.
Also I feel like you are trying to find some "week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I just
wanted to let you know about libre-mesh because I have seen in your
WiKi many points in common with us. But of course the decision is yours.
Well, this kind of discussions is what I was
trying to avoid...
but it is my fault for starting it.
No no. It is important to discuss this things. You cannot just
believe that people would just take some firmware without trying to
understand it and reasons for why something is like it is and not
some way around? So don't see this as a flame but more as a way to
teach/show. It is exactly
what we are doing. Please see our repositories you
will find lime-packages which is an OpenWRT feed.
Great!
This maybe means that talking about "firmware" is not the right
word. But more about a set of packages? Because then it is easier
to imagine that another community network takes few of those
packages and add few theirs and maybe even then put them all
together in one feed for later community network to build upon. So I think the most important thing is not to see
firmware as one,
but to learn which problems/issues you already solved with which
packages and see how to build upon that and contribute back, no?
It is not yet done in Libre-Mesh because it is in development. But you
can surf over the qmp.cat git repository to see the amount of code we
have (just the luci-based web iface is more than a "few scripts").
If you want to do a generic solution (like libre-mesh) you need a lot
of code to adapt to any scenario. But of course, if you want to have a
solution just for your network, the amount of code could be quite small.
Well, I would not say "few small
scripts", it is a bit more than
that. I don't know about which firmware are you speaking about
but in my experience if you want to end up in a stable, powerful
and flexible system you need more than "few small scripts".
Can you maybe just show us few examples of such scripts? Just so
that it is easier to imagine what kind of things one have to think
about when developing a firmware? Ask yo
AlterMesh guys who are starting having problems with
scalability. Can you imagine which is the total amount of ARP
packages in a 1000 nodes bat-adv cloud? (just to put an example)
So only ARP packets are the issue. Other broadcast packets you can
simply drop with a ebtables firewall rule. You can still use
ZeroConf, because it is multicast and not broadcast. And for ARP packets Batman could probably provide some
fake proxy,
where the node would answer them directly instead of broadcasting
them around. Or maybe tunnel them directly to the node who can
answer them. (Because Batman knows exactly where any MAC address in
the network is. You do not really have to broadcast around to get
this.) In a similar way that Batman currently handles DHCP by
intercepting the packets and responding itself.
Hey Mitar, would you try to layer2 bridge all the Internet? Or even
just your city? Collision domain is for small sets of computers, the
networking stack we are using based on MAC/IP is not ready to have 1k
computes in the same domain. Broadcast storms, ARP problems (including
poisoning!), huge overhead just to mention some of the problems you
would have. IMHO trying to patch it by modifying batman-adv is a
mistake. Layer3 routing is exactly done to solve these situations.
So I am not sure that it is smart to add another layer
(another
routing protocol) of complexity to the networking stack, where we
could just learn and build upon existing tools. As you said, if I
paraphrase, not yet another routing protocol. Cannot we have just
one and all contribute to that one? So if Batman works in most
cases, let's fix those cases where it does not.
Guido already answered you and I agree with what he said. We had
several meetings with the Batman-adv guys and everybody accepted it
was a problem which has to be fixed using a second routing protocol.
It is complex to explain, if you want we can organize an audioconf.
Quagga is a
suit which includes several routing protocols.
Quagga could be used to federate bat-adv and bmx6. But if you are
speaking about use static routing, I would just say it is a big
mistake (what happens when you have to paths to the same
cloud?).
So are you saying that BMX should be run over whole mesh on layer 3
with Batman below on layer 2? Or are you saying that it should be
used only on gateways. I am not sure what exactly you are saying
here. Do you have some more concrete example/presentation of this
idea? So how does one packet travels around the network in your
topology of BMX + Batman?
I agree with your approach about compare overhead
and routing
changes. However I can say this test was made during the
WCW-Berlin.
For others, WCW is a yearly mesh-related even in Berlin, Wireless
Community Weekend:
http://wiki.freifunk.net/Wireless_Community_Weekend_2013
More locally targeted for the whole Freifunk community to get
together from all around the country, once a year. (So most of the
stuff you will find will probably be in German. :-) )
The scenario was around 15-20 nodes (ask UFO to
to know it
better) in a mobile scenario (it means someone moving nodes). All
protocols were running at same time in different VLAN (see
battlemesh firmware in github) so all of them were in the same
situation.
Is there any description of the scenario? So if they were just
moving the nodes around without communicating with the node at the
same time, then this data is useless. Just to give
you another detail, the tested protocol which
showed more difference between moving and not moving environment
was Babel.
This might be just that Babel adapts in a smart way to the moving
and starts sending more updates. :-) By the way,
the conclusion of this tests was: BATMAN based
protocols are better in the overhead-mobile test.
Yes. Their ways of updating the information about the network
topology is really interesting and charming. But sadly the overhead
is not the only thing which matters. Speed of convergence to new
topology, no routing loops, and no disruptions in service are other
which are important as well. Personally, I would not really care so
much if routing protocol has bigger overhead if this means it works
for people. And in general nodes do not really move around so
much. Clients do
(Batman has roaming support for them), but nodes, not really. At
least until we have nodes installed on cars and bikes. Nodes do
come up and down and at that time it is not so important how fast
new topology converges, that is true.
It will depend on the environment. The scope of libre-mesh is cover
any kind of deployment.
Cheers, Mitar.
Hope to see you in October.
Sadly, I will not have time to attend the summit this time. :-(
Mitar
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9Oe+AAoJEAX7rWpc+YnNpz4H/1wI7kSeihTqZM3QZqn32xwZ
wQjGoyTTvemJPhKAd28fJIe6IeqtlncMCrTAaswjAyg7w+utmfMcapUVKEkoTJY9
h+zTmaWO/p8a6zt7YR2pH+mfCbwy5OtXxzAZwT26dlcC2U0/noocg8cXxEAeZvuw
nt2ABQ7Vs2aqzoTIXw9mSE1PgSAcx3t6r4VvyR8GUMmnVXbSvXimMvub9ie4JbUy
tuqK1zZq6CxHffLatMLJT6tXU+JOtxF6j819NDBjlhuX/Xw0NeJPZjFUa9UVW6C4
/cAKxN/kukvgiNa70MNjNOB2oLJuTH+u2YStMDLVJUS0x9i7uuKCFe6aejwQ/as=
=fYo1
-----END PGP SIGNATURE-----
3:20 a.m.
Hi!
Also I feel like you are trying to find some
"week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I just
wanted to let you know about libre-mesh because I have seen in your
WiKi many points in common with us. But of course the decision is yours.
No no. I just want to understand what is the current architecture you
are proposing. I do not have any emotional attachments to any
architecture. But I do not believe things just because somebody say this
is the way is should be done and we are doing it so you should also be
doing it. So a major part of the firmware is how the network stack and
routing is done and probably what you are saying by proposing that your
firmware should be used is also to use the network stack and routing as
you envisioned it. This is why it is important to understand how your
firmware's network stack works. I don't care who is right.
If I understand you correctly, you are saying that layer 3 protocol
should run on all nodes in parallel with layer 2 protocol, layer 3
protocol on top of layer 2 protocol?
Layer3 routing is exactly done to solve these
situations.
I just don't understand how this combines together.
It is complex to explain, if you want we can organize
an audioconf.
Yes. Let's do it. But even better would be to have this written down
somehow.
Mitar, you have been in the BattleMesh before. You
know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe the
results obtained are relevant since the elite of the mesh networking
was there.
Yes. I have been there. And this is why I don't really trust the
measurements so easily. :-) But are those results you were showing from
WCW or Battlemesh? And I found only raw data results, but no
interpretation of this results?
Let me ask you something now. Is there any other
"hacker" in this
project which knows about mesh networking? How many people do you have
working on firmware? I hope this conversation is useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Yes, they are. Maybe it is really more useful to leave this discussion
to others. But I would still like to understand the architecture of
running both Batman and BMX together.
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
5:23 a.m.
The FNF is 100% behind libre-mesh as the go forward solution for mass deployment (think
Ubuntu of mesh networks). It will become the standard as the FreedomStack sees widespread
deployment over the coming months.
BMX routing between batman-adv domains is the way to go. It's a fairly standard
network design pattern (l2 edge/l3 agg/dist/core).
Pau <pau(a)dabax.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 28/07/13 02:50, Mitar wrote:
I like "firmware" more than "set of packages" because at the end
libre-mesh will be a firmware (software for embedded devices). But OK,
it is just a way to refer to the same thing.
Using ebtables is dirty and a patch to solve something that layer3
solves. And have you thought about IPv6? It does not have broadcast
but multicast link-local domains which can end-up in a big storm too
(RA announcements and requests).
Mitar, you have been in the BattleMesh before. You know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe the
results obtained are relevant since the elite of the mesh networking
was there.
I don't think so. Babel acts as a static protocol when the network is
not moving, but when it moves it produces a very very high overhead
(compared to other distance-vector protocols). I don't see this very
smart since for static deployments you could do the same using BGP or
OSPF.
Of course it is not the only important thing. However in the last
BattleMesh, BMX6 was the better in coverage time and in best-path
selection. You have the results raw data in the battlemesh web page.
Let me ask you something now. Is there any other "hacker" in this
project which knows about mesh networking? How many people do you have
working on firmware? I hope this conversation is useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Cheers
--
Charles N Wyble (818) 280-7059
CTO/Cofounder Free Network Foundation
http://www.thefnf.org
Hi!
Of course people should ask and understand before choosing some
specific existing solution. But I did not want to start this kind of
discussion here (in this post). I just wanted to let you know about
libre-mesh project.
Also I feel like you are trying to find some "week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I just
wanted to let you know about libre-mesh because I have seen in your
WiKi many points in common with us. But of course the decision is
yours.
Well, this kind of discussions is what I was
trying to avoid...
but it is my fault for starting it.
No no. It is important to discuss this things. You cannot just
believe that people would just take some firmware without trying to
understand it and reasons for why something is like it is and not
some way around? So don't see this as a flame but more as a way to
teach/show. It is
exactly what we are doing. Please see our repositories you
will find lime-packages which is an OpenWRT feed.
Great!
This maybe means that talking about "firmware" is not the right
word. But more about a set of packages? Because then it is easier
to imagine that another community network takes few of those
packages and add few theirs and maybe even then put them all
together in one feed for later community network to build upon. So I think the most important thing is not to see
firmware as one,
but to learn which problems/issues you already solved with which
packages and see how to build upon that and contribute back, no?
It is not yet done in Libre-Mesh because it is in development. But you
can surf over the qmp.cat git repository to see the amount of code we
have (just the luci-based web iface is more than a "few scripts").
If you want to do a generic solution (like libre-mesh) you need a lot
of code to adapt to any scenario. But of course, if you want to have a
solution just for your network, the amount of code could be quite
small.
Well, I would not say "few small
scripts", it is a bit more than
that. I don't know about which firmware are you speaking about
but in my experience if you want to end up in a stable, powerful
and flexible system you need more than "few small scripts".
Can you maybe just show us few examples of such scripts? Just so
that it is easier to imagine what kind of things one have to think
about when developing a firmware? Ask yo
AlterMesh guys who are starting having problems with
scalability. Can you imagine which is the total amount of ARP
packages in a 1000 nodes bat-adv cloud? (just to put an example)
So only ARP packets are the issue. Other broadcast packets you can
simply drop with a ebtables firewall rule. You can still use
ZeroConf, because it is multicast and not broadcast. And for ARP packets Batman could probably provide
some fake proxy,
where the node would answer them directly instead of broadcasting
them around. Or maybe tunnel them directly to the node who can
answer them. (Because Batman knows exactly where any MAC address in
the network is. You do not really have to broadcast around to get
this.) In a similar way that Batman currently handles DHCP by
intercepting the packets and responding itself.
Hey Mitar, would you try to layer2 bridge all the Internet? Or even
just your city? Collision domain is for small sets of computers, the
networking stack we are using based on MAC/IP is not ready to have 1k
computes in the same domain. Broadcast storms, ARP problems (including
poisoning!), huge overhead just to mention some of the problems you
would have. IMHO trying to patch it by modifying batman-adv is a
mistake. Layer3 routing is exactly done to solve these situations.
So I am not sure that it is smart to add another
layer (another
routing protocol) of complexity to the networking stack, where we
could just learn and build upon existing tools. As you said, if I
paraphrase, not yet another routing protocol. Cannot we have just
one and all contribute to that one? So if Batman works in most
cases, let's fix those cases where it does not.
Guido already answered you and I agree with what he said. We had
several meetings with the Batman-adv guys and everybody accepted it
was a problem which has to be fixed using a second routing protocol.
It is complex to explain, if you want we can organize an audioconf.
Quagga is
a suit which includes several routing protocols.
Quagga could be used to federate bat-adv and bmx6. But if you are
speaking about use static routing, I would just say it is a big
mistake (what happens when you have to paths to the same
cloud?).
So are you saying that BMX should be run over whole mesh on layer 3
with Batman below on layer 2? Or are you saying that it should be
used only on gateways. I am not sure what exactly you are saying
here. Do you have some more concrete example/presentation of this
idea? So how does one packet travels around the network in your
topology of BMX + Batman?
I agree with your approach about compare overhead
and routing
changes. However I can say this test was made during the
WCW-Berlin.
For others, WCW is a yearly mesh-related even in Berlin, Wireless
Community Weekend:
http://wiki.freifunk.net/Wireless_Community_Weekend_2013
More locally targeted for the whole Freifunk community to get
together from all around the country, once a year. (So most of the
stuff you will find will probably be in German. :-) )
The scenario was around 15-20 nodes (ask UFO to
to know it
better) in a mobile scenario (it means someone moving nodes). All
protocols were running at same time in different VLAN (see
battlemesh firmware in github) so all of them were in the same
situation.
Is there any description of the scenario? So if they were just
moving the nodes around without communicating with the node at the
same time, then this data is useless. Just to
give you another detail, the tested protocol which
showed more difference between moving and not moving environment
was Babel.
This might be just that Babel adapts in a smart way to the moving
and starts sending more updates. :-) By the
way, the conclusion of this tests was: BATMAN based
protocols are better in the overhead-mobile test.
Yes. Their ways of updating the information about the network
topology is really interesting and charming. But sadly the overhead
is not the only thing which matters. Speed of convergence to new
topology, no routing loops, and no disruptions in service are other
which are important as well. Personally, I would not really care so
much if routing protocol has bigger overhead if this means it works
for people. And in general nodes do not really move around so
much. Clients do
(Batman has roaming support for them), but nodes, not really. At
least until we have nodes installed on cars and bikes. Nodes do
come up and down and at that time it is not so important how fast
new topology converges, that is true.
It will depend on the environment. The scope of libre-mesh is cover
any kind of deployment.
Cheers,
Mitar. Hope to see you in October.
Sadly, I will not have time to attend the summit this time. :-(
Mitar
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9Oe+AAoJEAX7rWpc+YnNpz4H/1wI7kSeihTqZM3QZqn32xwZ
wQjGoyTTvemJPhKAd28fJIe6IeqtlncMCrTAaswjAyg7w+utmfMcapUVKEkoTJY9
h+zTmaWO/p8a6zt7YR2pH+mfCbwy5OtXxzAZwT26dlcC2U0/noocg8cXxEAeZvuw
nt2ABQ7Vs2aqzoTIXw9mSE1PgSAcx3t6r4VvyR8GUMmnVXbSvXimMvub9ie4JbUy
tuqK1zZq6CxHffLatMLJT6tXU+JOtxF6j819NDBjlhuX/Xw0NeJPZjFUa9UVW6C4
/cAKxN/kukvgiNa70MNjNOB2oLJuTH+u2YStMDLVJUS0x9i7uuKCFe6aejwQ/as=
=fYo1
-----END PGP SIGNATURE-----
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh 
10:29 a.m.
New subject: [lime-dev] From libre-mesh
I don't know if it's fair to say that it will necessarily become the standard.
We can hope so, but in a way that is besides the point. The point is that some
of the biggest and baddest free networks in the world are just beginning a
firmware collaboration, and it's a huge opportunity for those of us stateside,
and anywhere, to help the movement and help ourselves.
We've had our hands so full with deployment here in Kansas City that we've not
been able to contribute much to LiMe. That said, we're deploying qmp so that we
have an easy upgrade path, and our intention is to join the fray as soon as
possible.
I had the privilege to attend the WCW and some of the meetings where libremesh
was launched. In my opinion, it would be silly to ignore an opportunity to work
on a project that has buy-in from the developers of the highest performance
protocols and the biggest free networks.
It's not %100 final yet, but it looks like Pau and Roger from guifi will be
coming stateside at the end of August. They were able to bring me over there,
and now we're trying to return the favor. Point is that maybe someone from the
oakland freenet would want to come out and pow-wow? Bay Area to Kansas City is
a lot cheaper than Bay Area to Spain! Anyways, just a thought.
I do think that it makes a lot of sense to look at OpenWRT as the debian of
embedded linux, and to look at libremesh as the Ubuntu (or Mint).
imw
On Sun, Jul 28, 2013 at 07:23:29AM -0500, Charles N Wyble wrote:
The FNF is 100% behind libre-mesh as the go forward
solution for mass
deployment (think Ubuntu of mesh networks). It will become the standard as
the FreedomStack sees widespread deployment over the coming months.
BMX routing between batman-adv domains is the way to go. It's a fairly
standard network design pattern (l2 edge/l3 agg/dist/core).
Pau <pau(a)dabax.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 28/07/13 02:50, Mitar wrote:
Hi!
Well, this kind of discussions is what I was trying to avoid...
but it is my fault for starting it.
No no. It is important to discuss this things. You cannot just
believe that people would just take some firmware without trying to
understand it and reasons for why something is like it is and not
some way around? So don't see this as a flame but more as a way to
teach/show.
Of course people should ask and understand before choosing some
specific existing solution. But I did not want to start this kind of
discussion here (in this post). I just w
anted
to let you know about
libre-mesh project.
Also I feel like you are trying to find some "week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I just
wanted to let you know about libre-mesh because I have seen in your
WiKi many points in common with us. But of course the decision is yours.
It is exactly what we are doing. Please see our repositories you
will find lime-packages which is an OpenWRT feed.
Great!
This maybe means that talking about "firmware" is not the right
word. But more about a set of packages? Because then it is easier
to imagine that another
community network takes few of those
packages and add few theirs and maybe even then put them all
together in one feed for later community network to build upon.
I like "firmware" more than "set of packages" because at the end
libre-mesh will be a firmware (software for embedded devices). But OK,
it is just a way to refer to the same thing.
So I think the most important thing is not to see firmware as one,
but to learn which problems/issues you already solved with which
packages and see how to build upon that and contribute back, no?
Well, I would not say "few small scripts", it is a bit more than
that. I don't know about which firmware are you speaking about
but in
my
experience if you want to end up in a stable, powerful
and flexible system you need more than "few small scripts".
Can you maybe just show us few examples of such scripts? Just so
that it is easier to imagine what kind of things one have to think
about when developing a firmware?
It is not yet done in Libre-Mesh because it is in development. But you
can surf over the qmp.cat git repository to see the amount of code we
have (just the luci-based web iface is more than a "few scripts").
If you want to do a generic solution (like libre-mesh) you need a lot
of code to adapt to any scenario. But of course, if you want to have a
solution just for your network, the amount of code could be quite small.
Ask yo AlterMesh guys who are starting having problems with
scalability. Can you imagine which is the total amount of ARP
packages in a 1000 nodes bat-adv cloud? (just to put an example)
So only ARP packets are the issue. Other broadcast packets you can
simply drop with a ebtables firewall rule. You can still use
ZeroConf, because it is multicast and not broadcast.
Using ebtables is dirty and a patch to solve something that layer3
solves. And have you thought about IPv6? It does not have broadcast
but multicast link-local domains which can end-up in a big storm too
(RA announcements and requests).
And for ARP packets Batman could probably provide some fake proxy,
where the node would answer them directly instea
d of
broadcasting
them around. Or maybe tunnel them directly to the node who can
answer them. (Because Batman knows exactly where any MAC address in
the network is. You do not really have to broadcast around to get
this.) In a similar way that Batman currently handles DHCP by
intercepting the packets and responding itself.
Hey Mitar, would you try to layer2 bridge all the Internet? Or even
just your city? Collision domain is for small sets of computers, the
networking stack we are using based on MAC/IP is not ready to have 1k
computes in the same domain. Broadcast storms, ARP problems (including
poisoning!), huge overhead just to mention some of the problems you
would have. IMHO trying to patch it by modifying batman-adv is a
mistake. Layer3 routing is exactly done to solve these situations.
So I am not sure that it is smart to add another layer (another
routing protocol) of complexity to the networking stack, where we
could just learn and build upon existing tools. As you said, if I
paraphrase, not yet another routing protocol. Cannot we have just
one and all contribute to that one? So if Batman works in most
cases, let's fix those cases where it does not.
Guido already answered you and I agree with what he said. We had
several meetings with the Batman-adv guys and everybody accepted it
was a problem which has to be fixed using a second routing protocol.
It is complex to explain, if you want we can organize an audioconf.
Quagga is a suit which includes seve
ral
routing protocols.
Quagga could be used to federate bat-adv and bmx6. But if you are
speaking about use static routing, I would just say it is a big
mistake (what happens when you have to paths to the same
cloud?).
So are you saying that BMX should be run over whole mesh on layer 3
with Batman below on layer 2? Or are you saying that it should be
used only on gateways. I am not sure what exactly you are saying
here. Do you have some more concrete example/presentation of this
idea? So how does one packet travels around the network in your
topology of BMX + Batman?
I agree with your approach about compare overhead and routing
changes. However I can say this test was made during the
WCW-Berlin.
For others, WCW is a yearly mesh-related even in Berlin, Wireless
Community Weekend:
http://wiki.freifunk.net/Wireless_Community_Weekend_2013
More locally targeted for the whole Freifunk community to get
together from all around the country, once a year. (So most of the
stuff you will find will probably be in German. :-) )
The scenario was around 15-20 nodes (ask UFO to to know it
better) in a mobile scenario (it means someone moving nodes). All
protocols were running at same time in different VLAN (see
battlemesh firmware in github) so all of them were in the same
situation.
Is there any description of the scenario? So if they were just
moving the nodes around without communicating with the node at the
same time, then this data is useless.
Mitar
, you
have been in the BattleMesh before. You know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe the
results obtained are relevant since the elite of the mesh networking
was there.
Just to give you another detail, the tested protocol which
showed more difference between moving and not moving environment
was Babel.
This might be just that Babel adapts in a smart way to the moving
and starts sending more updates. :-)
I don't think so. Babel acts as a static protocol when the network is
not moving, but when it moves it produces a very very high overhead
(compar
ed to
other distance-vector protocols). I don't see this very
smart since for static deployments you could do the same using BGP or
OSPF.
By the way, the conclusion of this tests was: BATMAN based
protocols are better in the overhead-mobile test.
Yes. Their ways of updating the information about the network
topology is really interesting and charming. But sadly the overhead
is not the only thing which matters. Speed of convergence to new
topology, no routing loops, and no disruptions in service are other
which are important as well. Personally, I would not really care so
much if routing protocol has bigger overhead if this means it works
for people.
Of course
it is
not the only important thing. However in the last
BattleMesh, BMX6 was the better in coverage time and in best-path
selection. You have the results raw data in the battlemesh web page.
And in general nodes do not really move around so much. Clients do
(Batman has roaming support for them), but nodes, not really. At
least until we have nodes installed on cars and bikes. Nodes do
come up and down and at that time it is not so important how fast
new topology converges, that is true.
It will depend on the environment. The scope of libre-mesh is cover
any kind of deployment.
Cheers, Mitar. Hope to see you in October.
Sadly, I will not have time to attend the summit this time. :-(
Let me ask you something now. Is there any other "hacker" in this
project which knows about mesh networking? How many people do you have
working on firmware? I hope this conversation is useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Cheers
Mitar
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9Oe+AAoJEAX7rWpc+YnNpz4H/1wI7kSeihTqZM3QZqn32xwZ
wQjGoyTTvemJPhKAd28fJIe6IeqtlncMCrTAaswjAyg7w+utmfMcapUVKEkoTJY9
h+zTmaWO/p8a6zt7YR2pH+mfCbwy5OtXxzAZwT26dlcC2U0/noocg8cXxEAeZvuw
nt2ABQ7Vs2aqzoTIXw9mSE1PgSAcx3t6r4VvyR8GUMmnVXbSvXimMvub9ie4JbUy
tuqK1zZq6CxHffLatMLJT6tXU+JOtxF6j819NDBjlhuX/Xw0NeJPZjFUa9UVW6C4
/cAKxN/kukvgiNa70MNjNOB2oLJuTH+u2YStMDLVJUS0x9i7uuKCFe6aejwQ/as=
=fYo1
-----END PGP SIGNATURE-----
----------------------------------------------------------------------
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh
--
Charles N Wyble (818) 280-7059
CTO/Cofounder Free Network Foundation
http://www.thefnf.org _______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
6:35 p.m.
New subject: [lime-dev] From libre-mesh
Hi!
In my opinion, it would be silly to ignore an
opportunity to work on
a project that has buy-in from the developers of the highest
performance protocols and the biggest free networks.
And I completely agree that we should work together. But you should then
understand even more a need for some written whitepaper on what exactly
we should work on. We should start making such a document, we can work
on it collaboratively. Any wiki is good.
This is your current documentation?
http://dev.libre-mesh.org/projects/libre-mesh/wiki
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
12:08 p.m.
Hi!
BMX routing between batman-adv domains is the way to
go. It's a
fairly standard network design pattern (l2 edge/l3 agg/dist/core).
This is what you say but I simply cannot agree with that. It is a stupid
approach, if I understand it correctly (running L3 routing protocol over
L2 routing protocol). Write to the Batman mailing list and get
confirmation that they agree this is the way to go.
It will become the standard as the FreedomStack sees
widespread
deployment over the coming months.
I really doubt FreedomStack will see widespread deployment if your
networking stack will be such a combination. From what I know them,
nobody will move to that (except those who are already using BMX). :-)
But good luck making such a standard. Standard is not made by defining
one, but by using one. Currently, you are not really convincing. When
asked about some whitepaper explaining your rationale and architecture,
you are saying that we should call each other and talk. If this is your
approach to making your firmware popular, then even if the firmware
scales, your way of promoting it will not scale.
I really hate solutions where people think that because they like
features of A and features of B, let's just use both at the same time
and we will have features of A+B. Invest time to or move features from
Batman you like into BMX or to move features from BMX you like to
Batman. This is how the progress is done. Don't be afraid to code and
steal good ideas. This is what open source is about. This is what
happens between FreeBSD and Linux. Stealing (or rather, should I say
sharing - because none loses anything) from each other. But if somebody
would come and say, run FreeBSD and Linux at the same time and you will
have features of both ... Ehm ... In theory, this is doable. You can
have multiple kernels loaded at the same time. But how will this
interact? How much more complications will you have? What is the right
approach is to take features from one and put it into another.
Mitar
Pau <pau(a)dabax.net> wrote:
On 28/07/13 02:50, Mitar wrote:
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
>> Hi!
>>
>>> Well, this kind of discussions is what I was trying to avoid...
>>> but it is my fault for starting it.
>>
>> No no. It is important to discuss this things. You cannot just
>> believe that people would just take some firmware without trying to
>> understand it and reasons for why something is like it is and not
>> some way around? So don't see this as a flame but more as a way to
>> teach/show.
Of course people should ask and understand before choosing some
specific existing solution. But I did not want to start this kind of
discussion here (in this post). I just wanted to let you know about
libre-mesh project.
Also I feel like you are trying to find some "week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I just
wanted to let you know about libre-mesh because I have seen in your
WiKi many points in common with us. But of course the decision is
yours.
>>> It is exactly what we are doing.
Please see our repositories you
>>> will find lime-packages which is an OpenWRT feed.
>>
>> Great!
>>
>> This maybe means that talking about "firmware" is not the right
>> word. But more about a set of packages? Because then it is easier
>> to imagine that another community network takes few of those
>> packages and add few theirs and maybe even then put them all
>> together in one feed for later community network to build upon.
I like "firmware" more than "set of packages" because at the end
libre-mesh will be a firmware (software for embedded devices). But OK,
it is just a way to refer to the same thing.
>> So I think the most important thing is
not to see firmware as one,
>> but to learn which problems/issues you already solved with which
>> packages and see how to build upon that and contribute back, no?
>>
>>> Well, I would not say "few small scripts", it is a bit more than
>>> that. I don't know about which firmware are you speaking about
>>> but in my experience if you want to end up in a stable, powerful
>>> and flexible system you need more than "few small scripts".
>>
>> Can you maybe just show us few examples of such scripts? Just so
>> that it is easier to imagine what kind of things one have to think
>> about when developing a firmware?
It is not yet done in Libre-Mesh because it is in development. But you
can surf over the qmp.cat git repository to see the amount of code we
have (just the luci-based web iface is more than a "few scripts").
If you want to do a generic solution (like libre-mesh) you need a lot
of code to adapt to any scenario. But of course, if you want to have a
solution just for your network, the amount of code could be quite
small.
>>> Ask yo AlterMesh guys who are
starting having problems with
>>> scalability. Can you imagine which is the total amount of ARP
>>> packages in a 1000 nodes bat-adv cloud? (just to put an example)
>>
>> So only ARP packets are the issue. Other broadcast packets you can
>> simply drop with a ebtables firewall rule. You can still use
>> ZeroConf, because it is multicast and not broadcast.
Using ebtables is dirty and a patch to solve something that layer3
solves. And have you thought about IPv6? It does not have broadcast
but multicast link-local domains which can end-up in a big storm too
(RA announcements and requests).
>> And for ARP packets Batman could probably
provide some fake proxy,
>> where the node would answer them directly instead of broadcasting
>> them around. Or maybe tunnel them directly to the node who can
>> answer them. (Because Batman knows exactly where any MAC address in
>> the network is. You do not really have to broadcast around to get
>> this.) In a similar way that Batman currently handles DHCP by
>> intercepting the packets and responding itself.
Hey Mitar, would you try to layer2 bridge all the Internet? Or even
just your city? Collision domain is for small sets of computers, the
networking stack we are using based on MAC/IP is not ready to have 1k
computes in the same domain. Broadcast storms, ARP problems (including
poisoning!), huge overhead just to mention some of the problems you
would have. IMHO trying to patch it by modifying batman-adv is a
mistake. Layer3 routing is exactly done to solve these situations.
>> So I am not sure that it is smart to add
another layer (another
>> routing protocol) of complexity to the networking stack, where we
>> could just learn and build upon existing tools. As you said, if I
>> paraphrase, not yet another routing protocol. Cannot we have just
>> one and all contribute to that one? So if Batman works in most
>> cases, let's fix those cases where it does not.
Guido already answered you and I agree with what he said. We had
several meetings with the Batman-adv guys and everybody accepted it
was a problem which has to be fixed using a second routing protocol.
It is complex to explain, if you want we can organize an audioconf.
>>> Quagga is a suit which includes
several routing protocols.
>>> Quagga could be used to federate bat-adv and bmx6. But if you are
>>> speaking about use static routing, I would just say it is a big
>>> mistake (what happens when you have to paths to the same
>>> cloud?).
>>
>> So are you saying that BMX should be run over whole mesh on layer 3
>> with Batman below on layer 2? Or are you saying that it should be
>> used only on gateways. I am not sure what exactly you are saying
>> here. Do you have some more concrete example/presentation of this
>> idea? So how does one packet travels around the network in your
>> topology of BMX + Batman?
>>
>>> I agree with your approach about compare overhead and routing
>>> changes. However I can say this test was made during the
>>> WCW-Berlin.
>>
>> For others, WCW is a yearly mesh-related even in Berlin, Wireless
>> Community Weekend:
>>
>> http://wiki.freifunk.net/Wireless_Community_Weekend_2013
>>
>> More locally targeted for the whole Freifunk community to get
>> together from all around the country, once a year. (So most of the
>> stuff you will find will probably be in German. :-) )
>>
>>> The scenario was around 15-20 nodes (ask UFO to to know it
>>> better) in a mobile scenario (it means someone moving nodes). All
>>> protocols were running at same time in different VLAN (see
>>> battlemesh firmware in github) so all of them were in the same
>>> situation.
>>
>> Is there any description of the scenario? So if they were just
>> moving the nodes around without communicating with the node at the
>> same time, then this data is useless.
Mitar, you have been in the BattleMesh before. You know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe the
results obtained are relevant since the elite of the mesh networking
was there.
>>> Just to give you another detail, the
tested protocol which
>>> showed more difference between moving and not moving environment
>>> was Babel.
>>
>> This might be just that Babel adapts in a smart way to the moving
>> and starts sending more updates. :-)
I don't think so. Babel acts as a static protocol when the network is
not moving, but when it moves it produces a very very high overhead
(compared to other distance-vector protocols). I don't see this very
smart since for static deployments you could do the same using BGP or
OSPF.
>>> By the way, the conclusion of this
tests was: BATMAN based
>>> protocols are better in the overhead-mobile test.
>>
>> Yes. Their ways of updating the information about the network
>> topology is really interesting and charming. But sadly the overhead
>> is not the only thing which matters. Speed of convergence to new
>> topology, no routing loops, and no disruptions in service are other
>> which are important as well. Personally, I would not really care so
>> much if routing protocol has bigger overhead if this means it works
>> for people.
Of course it is not the only important thing. However in the last
BattleMesh, BMX6 was the better in coverage time and in best-path
selection. You have the results raw data in the battlemesh web page.
>> And in general nodes do not really move
around so much. Clients do
>> (Batman has roaming support for them), but nodes, not really. At
>> least until we have nodes installed on cars and bikes. Nodes do
>> come up and down and at that time it is not so important how fast
>> new topology converges, that is true.
It will depend on the environment. The scope of libre-mesh is cover
any kind of deployment.
>>> Cheers, Mitar. Hope to see you in
October.
>>
>> Sadly, I will not have time to attend the summit this time. :-(
>>
Let me ask you something now. Is there any other "hacker" in this
project which knows about mesh networking? How many people do you have
working on firmware? I hope this conversation is useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Cheers
>> Mitar
>>
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh
12:12 p.m.
One network vendor (who I won't name) built their firewall appliance
using Linux, but with the FreeBSD networking stack running in
userland.
Sometimes, people do the strangest crap...
2c,
-adrian
On 28 July 2013 12:08, Mitar <mitar(a)tnode.com> wrote:
Hi!
BMX routing between batman-adv domains is the way
to go. It's a
fairly standard network design pattern (l2 edge/l3 agg/dist/core).
This is what you say but I simply cannot agree with that. It is a stupid
approach, if I understand it correctly (running L3 routing protocol over
L2 routing protocol). Write to the Batman mailing list and get
confirmation that they agree this is the way to go.
It will become the standard as the FreedomStack
sees widespread
deployment over the coming months.
I really doubt FreedomStack will see widespread deployment if your
networking stack will be such a combination. From what I know them,
nobody will move to that (except those who are already using BMX). :-)
But good luck making such a standard. Standard is not made by defining
one, but by using one. Currently, you are not really convincing. When
asked about some whitepaper explaining your rationale and architecture,
you are saying that we should call each other and talk. If this is your
approach to making your firmware popular, then even if the firmware
scales, your way of promoting it will not scale.
I really hate solutions where people think that because they like
features of A and features of B, let's just use both at the same time
and we will have features of A+B. Invest time to or move features from
Batman you like into BMX or to move features from BMX you like to
Batman. This is how the progress is done. Don't be afraid to code and
steal good ideas. This is what open source is about. This is what
happens between FreeBSD and Linux. Stealing (or rather, should I say
sharing - because none loses anything) from each other. But if somebody
would come and say, run FreeBSD and Linux at the same time and you will
have features of both ... Ehm ... In theory, this is doable. You can
have multiple kernels loaded at the same time. But how will this
interact? How much more complications will you have? What is the right
approach is to take features from one and put it into another.
Mitar
Pau <pau(a)dabax.net> wrote:
On 28/07/13 02:50, Mitar wrote:
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh >> Hi!
>>
>>> Well, this kind of discussions is what I was trying to avoid...
>>> but it is my fault for starting it.
>>
>> No no. It is important to discuss this things. You cannot just
>> believe that people would just take some firmware without trying to
>> understand it and reasons for why something is like it is and not
>> some way around? So don't see this as a flame but more as a way to
>> teach/show.
Of course people should ask and understand before choosing some
specific existing solution. But I did not want to start this kind of
discussion here (in this post). I just wanted to let you know about
libre-mesh project.
Also I feel like you are trying to find some "week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I just
wanted to let you know about libre-mesh because I have seen in your
WiKi many points in common with us. But of course the decision is
yours.
>>> It is exactly what we are doing.
Please see our repositories you
>>> will find lime-packages which is an OpenWRT feed.
>>
>> Great!
>>
>> This maybe means that talking about "firmware" is not the right
>> word. But more about a set of packages? Because then it is easier
>> to imagine that another community network takes few of those
>> packages and add few theirs and maybe even then put them all
>> together in one feed for later community network to build upon.
I like "firmware" more than "set of packages" because at the end
libre-mesh will be a firmware (software for embedded devices). But OK,
it is just a way to refer to the same thing.
>> So I think the most important thing is
not to see firmware as one,
>> but to learn which problems/issues you already solved with which
>> packages and see how to build upon that and contribute back, no?
>>
>>> Well, I would not say "few small scripts", it is a bit more than
>>> that. I don't know about which firmware are you speaking about
>>> but in my experience if you want to end up in a stable, powerful
>>> and flexible system you need more than "few small scripts".
>>
>> Can you maybe just show us few examples of such scripts? Just so
>> that it is easier to imagine what kind of things one have to think
>> about when developing a firmware?
It is not yet done in Libre-Mesh because it is in development. But you
can surf over the qmp.cat git repository to see the amount of code we
have (just the luci-based web iface is more than a "few scripts").
If you want to do a generic solution (like libre-mesh) you need a lot
of code to adapt to any scenario. But of course, if you want to have a
solution just for your network, the amount of code could be quite
small.
>>> Ask yo AlterMesh guys who are
starting having problems with
>>> scalability. Can you imagine which is the total amount of ARP
>>> packages in a 1000 nodes bat-adv cloud? (just to put an example)
>>
>> So only ARP packets are the issue. Other broadcast packets you can
>> simply drop with a ebtables firewall rule. You can still use
>> ZeroConf, because it is multicast and not broadcast.
Using ebtables is dirty and a patch to solve something that layer3
solves. And have you thought about IPv6? It does not have broadcast
but multicast link-local domains which can end-up in a big storm too
(RA announcements and requests).
>> And for ARP packets Batman could probably
provide some fake proxy,
>> where the node would answer them directly instead of broadcasting
>> them around. Or maybe tunnel them directly to the node who can
>> answer them. (Because Batman knows exactly where any MAC address in
>> the network is. You do not really have to broadcast around to get
>> this.) In a similar way that Batman currently handles DHCP by
>> intercepting the packets and responding itself.
Hey Mitar, would you try to layer2 bridge all the Internet? Or even
just your city? Collision domain is for small sets of computers, the
networking stack we are using based on MAC/IP is not ready to have 1k
computes in the same domain. Broadcast storms, ARP problems (including
poisoning!), huge overhead just to mention some of the problems you
would have. IMHO trying to patch it by modifying batman-adv is a
mistake. Layer3 routing is exactly done to solve these situations.
>> So I am not sure that it is smart to add
another layer (another
>> routing protocol) of complexity to the networking stack, where we
>> could just learn and build upon existing tools. As you said, if I
>> paraphrase, not yet another routing protocol. Cannot we have just
>> one and all contribute to that one? So if Batman works in most
>> cases, let's fix those cases where it does not.
Guido already answered you and I agree with what he said. We had
several meetings with the Batman-adv guys and everybody accepted it
was a problem which has to be fixed using a second routing protocol.
It is complex to explain, if you want we can organize an audioconf.
>>> Quagga is a suit which includes
several routing protocols.
>>> Quagga could be used to federate bat-adv and bmx6. But if you are
>>> speaking about use static routing, I would just say it is a big
>>> mistake (what happens when you have to paths to the same
>>> cloud?).
>>
>> So are you saying that BMX should be run over whole mesh on layer 3
>> with Batman below on layer 2? Or are you saying that it should be
>> used only on gateways. I am not sure what exactly you are saying
>> here. Do you have some more concrete example/presentation of this
>> idea? So how does one packet travels around the network in your
>> topology of BMX + Batman?
>>
>>> I agree with your approach about compare overhead and routing
>>> changes. However I can say this test was made during the
>>> WCW-Berlin.
>>
>> For others, WCW is a yearly mesh-related even in Berlin, Wireless
>> Community Weekend:
>>
>> http://wiki.freifunk.net/Wireless_Community_Weekend_2013
>>
>> More locally targeted for the whole Freifunk community to get
>> together from all around the country, once a year. (So most of the
>> stuff you will find will probably be in German. :-) )
>>
>>> The scenario was around 15-20 nodes (ask UFO to to know it
>>> better) in a mobile scenario (it means someone moving nodes). All
>>> protocols were running at same time in different VLAN (see
>>> battlemesh firmware in github) so all of them were in the same
>>> situation.
>>
>> Is there any description of the scenario? So if they were just
>> moving the nodes around without communicating with the node at the
>> same time, then this data is useless.
Mitar, you have been in the BattleMesh before. You know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe the
results obtained are relevant since the elite of the mesh networking
was there.
>>> Just to give you another detail, the
tested protocol which
>>> showed more difference between moving and not moving environment
>>> was Babel.
>>
>> This might be just that Babel adapts in a smart way to the moving
>> and starts sending more updates. :-)
I don't think so. Babel acts as a static protocol when the network is
not moving, but when it moves it produces a very very high overhead
(compared to other distance-vector protocols). I don't see this very
smart since for static deployments you could do the same using BGP or
OSPF.
>>> By the way, the conclusion of this
tests was: BATMAN based
>>> protocols are better in the overhead-mobile test.
>>
>> Yes. Their ways of updating the information about the network
>> topology is really interesting and charming. But sadly the overhead
>> is not the only thing which matters. Speed of convergence to new
>> topology, no routing loops, and no disruptions in service are other
>> which are important as well. Personally, I would not really care so
>> much if routing protocol has bigger overhead if this means it works
>> for people.
Of course it is not the only important thing. However in the last
BattleMesh, BMX6 was the better in coverage time and in best-path
selection. You have the results raw data in the battlemesh web page.
>> And in general nodes do not really move
around so much. Clients do
>> (Batman has roaming support for them), but nodes, not really. At
>> least until we have nodes installed on cars and bikes. Nodes do
>> come up and down and at that time it is not so important how fast
>> new topology converges, that is true.
It will depend on the environment. The scope of libre-mesh is cover
any kind of deployment.
>>> Cheers, Mitar. Hope to see you in
October.
>>
>> Sadly, I will not have time to attend the summit this time. :-(
>>
Let me ask you something now. Is there any other "hacker" in this
project which knows about mesh networking? How many people do you have
working on firmware? I hope this conversation is useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Cheers
>> Mitar
>>
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh
1:28 p.m.
Mitar,
I certainly don't fault you for this, because you haven't been provided with the
proper documentation, but I don't think you're correct in your assesment of how
the system would work. I certainly don't consider myself an expert in either bmx
or batman-adv, but here's my understand of how such a system could/should work:
In batman-adv you have the concept of communities, so it would be possible to
have nodes run a very lightweight daemon that watches for batman-adv packets
with a different community ID. If such a link is persistent, and of a sufficient
quality then those node (and only those nodes) would route between communities
using bmx. So you end up with a situation where batman-adv link-locals are
essentially 'nodes' in the layer-3 routed network. Naturally, you could also set
up point-to-points that run bmx by default. Community edge nodes would just have
to keep their arp table up to date in order to move between layer 3 and layer 2.
It's not that you would run both at the same time - that would be wasteful and
cumbersome. It's that they would play different (and I think appropriate) roles
in the network. If I want the utility of a hammer and screwdriver, I don't try
to fuse them together, because I want them to perform different functions.
I agree strongly that the way to encourage adoption is to build, use, and
demonstrate. At the same time, we will make much more progress if we can find
ways to collaborate. I tend to agree with the comments regarding in-person
collaboration. Perhaps it would be possible for you to come and talk things over
when Pau and Roger are in the states?
imw
On Sun, Jul 28, 2013 at 12:08:55PM -0700, Mitar wrote:
Hi!
BMX routing between batman-adv domains is the way
to go. It's a
fairly standard network design pattern (l2 edge/l3 agg/dist/core).
This is what you say but I simply cannot agree with that. It is a stupid
approach, if I understand it correctly (running L3 routing protocol over
L2 routing protocol). Write to the Batman mailing list and get
confirmation that they agree this is the way to go.
It will become the standard as the FreedomStack
sees widespread
deployment over the coming months.
I really doubt FreedomStack will see widespread deployment if your
networking stack will be such a combination. From what I know them,
nobody will move to that (except those who are already using BMX). :-)
But good luck making such a standard. Standard is not made by defining
one, but by using one. Currently, you are not really convincing. When
asked about some whitepaper explaining your rationale and architecture,
you are saying that we should call each other and talk. If this is your
approach to making your firmware popular, then even if the firmware
scales, your way of promoting it will not scale.
I really hate solutions where people think that because they like
features of A and features of B, let's just use both at the same time
and we will have features of A+B. Invest time to or move features from
Batman you like into BMX or to move features from BMX you like to
Batman. This is how the progress is done. Don't be afraid to code and
steal good ideas. This is what open source is about. This is what
happens between FreeBSD and Linux. Stealing (or rather, should I say
sharing - because none loses anything) from each other. But if somebody
would come and say, run FreeBSD and Linux at the same time and you will
have features of both ... Ehm ... In theory, this is doable. You can
have multiple kernels loaded at the same time. But how will this
interact? How much more complications will you have? What is the right
approach is to take features from one and put it into another.
Mitar
Pau <pau(a)dabax.net> wrote:
On 28/07/13 02:50, Mitar wrote:
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh >> Hi!
>>
>>> Well, this kind of discussions is what I was trying to avoid...
>>> but it is my fault for starting it.
>>
>> No no. It is important to discuss this things. You cannot just
>> believe that people would just take some firmware without trying to
>> understand it and reasons for why something is like it is and not
>> some way around? So don't see this as a flame but more as a way to
>> teach/show.
Of course people should ask and understand before choosing some
specific existing solution. But I did not want to start this kind of
discussion here (in this post). I just wanted to let you know about
libre-mesh project.
Also I feel like you are trying to find some "week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I just
wanted to let you know about libre-mesh because I have seen in your
WiKi many points in common with us. But of course the decision is
yours.
>>> It is exactly what we are doing.
Please see our repositories you
>>> will find lime-packages which is an OpenWRT feed.
>>
>> Great!
>>
>> This maybe means that talking about "firmware" is not the right
>> word. But more about a set of packages? Because then it is easier
>> to imagine that another community network takes few of those
>> packages and add few theirs and maybe even then put them all
>> together in one feed for later community network to build upon.
I like "firmware" more than "set of packages" because at the end
libre-mesh will be a firmware (software for embedded devices). But OK,
it is just a way to refer to the same thing.
>> So I think the most important thing is
not to see firmware as one,
>> but to learn which problems/issues you already solved with which
>> packages and see how to build upon that and contribute back, no?
>>
>>> Well, I would not say "few small scripts", it is a bit more than
>>> that. I don't know about which firmware are you speaking about
>>> but in my experience if you want to end up in a stable, powerful
>>> and flexible system you need more than "few small scripts".
>>
>> Can you maybe just show us few examples of such scripts? Just so
>> that it is easier to imagine what kind of things one have to think
>> about when developing a firmware?
It is not yet done in Libre-Mesh because it is in development. But you
can surf over the qmp.cat git repository to see the amount of code we
have (just the luci-based web iface is more than a "few scripts").
If you want to do a generic solution (like libre-mesh) you need a lot
of code to adapt to any scenario. But of course, if you want to have a
solution just for your network, the amount of code could be quite
small.
>>> Ask yo AlterMesh guys who are
starting having problems with
>>> scalability. Can you imagine which is the total amount of ARP
>>> packages in a 1000 nodes bat-adv cloud? (just to put an example)
>>
>> So only ARP packets are the issue. Other broadcast packets you can
>> simply drop with a ebtables firewall rule. You can still use
>> ZeroConf, because it is multicast and not broadcast.
Using ebtables is dirty and a patch to solve something that layer3
solves. And have you thought about IPv6? It does not have broadcast
but multicast link-local domains which can end-up in a big storm too
(RA announcements and requests).
>> And for ARP packets Batman could probably
provide some fake proxy,
>> where the node would answer them directly instead of broadcasting
>> them around. Or maybe tunnel them directly to the node who can
>> answer them. (Because Batman knows exactly where any MAC address in
>> the network is. You do not really have to broadcast around to get
>> this.) In a similar way that Batman currently handles DHCP by
>> intercepting the packets and responding itself.
Hey Mitar, would you try to layer2 bridge all the Internet? Or even
just your city? Collision domain is for small sets of computers, the
networking stack we are using based on MAC/IP is not ready to have 1k
computes in the same domain. Broadcast storms, ARP problems (including
poisoning!), huge overhead just to mention some of the problems you
would have. IMHO trying to patch it by modifying batman-adv is a
mistake. Layer3 routing is exactly done to solve these situations.
>> So I am not sure that it is smart to add
another layer (another
>> routing protocol) of complexity to the networking stack, where we
>> could just learn and build upon existing tools. As you said, if I
>> paraphrase, not yet another routing protocol. Cannot we have just
>> one and all contribute to that one? So if Batman works in most
>> cases, let's fix those cases where it does not.
Guido already answered you and I agree with what he said. We had
several meetings with the Batman-adv guys and everybody accepted it
was a problem which has to be fixed using a second routing protocol.
It is complex to explain, if you want we can organize an audioconf.
>>> Quagga is a suit which includes
several routing protocols.
>>> Quagga could be used to federate bat-adv and bmx6. But if you are
>>> speaking about use static routing, I would just say it is a big
>>> mistake (what happens when you have to paths to the same
>>> cloud?).
>>
>> So are you saying that BMX should be run over whole mesh on layer 3
>> with Batman below on layer 2? Or are you saying that it should be
>> used only on gateways. I am not sure what exactly you are saying
>> here. Do you have some more concrete example/presentation of this
>> idea? So how does one packet travels around the network in your
>> topology of BMX + Batman?
>>
>>> I agree with your approach about compare overhead and routing
>>> changes. However I can say this test was made during the
>>> WCW-Berlin.
>>
>> For others, WCW is a yearly mesh-related even in Berlin, Wireless
>> Community Weekend:
>>
>> http://wiki.freifunk.net/Wireless_Community_Weekend_2013
>>
>> More locally targeted for the whole Freifunk community to get
>> together from all around the country, once a year. (So most of the
>> stuff you will find will probably be in German. :-) )
>>
>>> The scenario was around 15-20 nodes (ask UFO to to know it
>>> better) in a mobile scenario (it means someone moving nodes). All
>>> protocols were running at same time in different VLAN (see
>>> battlemesh firmware in github) so all of them were in the same
>>> situation.
>>
>> Is there any description of the scenario? So if they were just
>> moving the nodes around without communicating with the node at the
>> same time, then this data is useless.
Mitar, you have been in the BattleMesh before. You know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe the
results obtained are relevant since the elite of the mesh networking
was there.
>>> Just to give you another detail, the
tested protocol which
>>> showed more difference between moving and not moving environment
>>> was Babel.
>>
>> This might be just that Babel adapts in a smart way to the moving
>> and starts sending more updates. :-)
I don't think so. Babel acts as a static protocol when the network is
not moving, but when it moves it produces a very very high overhead
(compared to other distance-vector protocols). I don't see this very
smart since for static deployments you could do the same using BGP or
OSPF.
>>> By the way, the conclusion of this
tests was: BATMAN based
>>> protocols are better in the overhead-mobile test.
>>
>> Yes. Their ways of updating the information about the network
>> topology is really interesting and charming. But sadly the overhead
>> is not the only thing which matters. Speed of convergence to new
>> topology, no routing loops, and no disruptions in service are other
>> which are important as well. Personally, I would not really care so
>> much if routing protocol has bigger overhead if this means it works
>> for people.
Of course it is not the only important thing. However in the last
BattleMesh, BMX6 was the better in coverage time and in best-path
selection. You have the results raw data in the battlemesh web page.
>> And in general nodes do not really move
around so much. Clients do
>> (Batman has roaming support for them), but nodes, not really. At
>> least until we have nodes installed on cars and bikes. Nodes do
>> come up and down and at that time it is not so important how fast
>> new topology converges, that is true.
It will depend on the environment. The scope of libre-mesh is cover
any kind of deployment.
>>> Cheers, Mitar. Hope to see you in
October.
>>
>> Sadly, I will not have time to attend the summit this time. :-(
>>
Let me ask you something now. Is there any other "hacker" in this
project which knows about mesh networking? How many people do you have
working on firmware? I hope this conversation is useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Cheers
>> Mitar
>>
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh
8:09 p.m.
Hi!
but I don't think you're correct in your
assesment of how the system
would work.
Probably. :-) I don't have a clear mental picture of it.
If such a link is persistent, and of a sufficient
quality then those node (and only those nodes) would route between communities
using bmx.
And why not just BGP? So why using a routing protocol which was
optimized for wireless links to run over something which is not a
wireless network anymore (but an abstracted L2 Batman network, which
might be somewhere deep in a wireless network, but none of this is seen
to BMX)?
The only thing you need is "network is available"/"network is not
available" announcements which knows how to read Batman community IDs,
no? You don't really need packet loss measurements for wireless links?
Can Batman on one node participate in multiple communities at the same time?
Have you seen this?
http://www.open-mesh.org/projects/open-mesh/wiki/Connecting-Batman-adv-clou…
So I do understand that you need some kind of L3 routing protocol on
borders between L2 routing domains. But I am not exactly sure how this
would work as a generic auto-configuring firmware. For example, if we
have two L2 mesh networks:
------------ ------------
| [gateway1a]--link A--[gateway2a] |
| mesh 1 | | mesh 2 |
| [gateway1b]--link B--[gateway2b] |
------------ ------------
I am not sure how could gateway1b and gateway2b be one device, one node?
And with an auto-configuring firmware?
Both mesh 1 and mesh 2 are big L2 blobs. What I can understand is that
gateway1a and gateway1b is part of mesh 1. And gateway2a and gateway2b
part of mesh 2. They have between them each a special network link,
respectively. So gateway1a/b have their own IPs inside mesh 1 and they
also have IP inside the peering links. Same for gateway2a/b.
So I know how to configure this manually. But I am not sure how BMX6
running on gateway nodes can just discover this automatically? And even
more, how it can know over which link to route traffic? Link A or link
B? It does not have any special knowledge of how well gatewa1a or
gateway1b is connected to the rest of mesh 1. But even if we ignore that
(which is really a hard problem to solve), the reason why BMX6 would be
useful is because link A and link B can be of different link qualities
and you want to route over better one?
And how does BMX6 then propagate this information that link 1 is better
than link 2 to clients in the mesh network?
And still, how you configure those links automatically?
I agree strongly that the way to encourage adoption is
to build, use, and
demonstrate. At the same time, we will make much more progress if we can find
ways to collaborate. I tend to agree with the comments regarding in-person
collaboration. Perhaps it would be possible for you to come and talk things over
when Pau and Roger are in the states?
I agree that discussion in person can help. But sooner or later we have
to write something down. If you already have clear image what you want
to build, then just write this down. Discussions are important if we
need to create a solution. But in this case you are saying that you
already have a solution. Can you just write this down?
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
29 Jul
29 Jul
3:29 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
First of all, running layer3 protocol over layer2 protocols would be
completely stupid, so just discard this idea.
The Isaac explanation is right. But as said the scope of libre-mesh is
to be compatible with most of the possible scenarios, so what Isaac
said is just one of the models libre-mesh will be able to support.
Another scenario (the one I like more) is having small batman-adv
communities (let's say a building, a neighborhood or maybe a
district). These communities are connected with other communities
using layer3 protocol (such as BMX6). So at the end you can end-up in
a city with 20 bat-adv clous connected all of them with BMX6.
The selection of the border-nodes have to be made automatically (to
scale better and to be as easy as possible for the normal user). So
there will be a mechanism to discover if a node is border-node or not
(if it is connecting with another node which is using anode
batmand-adv ID**). It can be achieved by a very simple protocol based
on ICMPv6.
So, once a node see that he is a border node, it starts BMX6
automatically to start sharing routes between both batman-adv clouds.
Following this approach libre-mesh will be able to cover both
scenarios depending on the user needs:
- - A big bat-adv cloud for all the city (if batman-adv ID is the same
for all nodes).
- - A lot of small bat-adv clouds connected with BMX6 (each small
community decides the batman-adv ID to isolate from other small
communities).
At this point I believe you understand why using a mesh dymanic
routing protocol instead of BGP.
Please, take a look again on the diagrams I included in my first mail,
they are trying to explain it.
** batman-adv ID is the VLAN tag used to isolate clouds
Cheers
On 29/07/13 05:09, Mitar wrote:
Hi!
- --
./p4u
but I don't think you're correct in your
assesment of how the
system would work.
Probably. :-) I don't have a clear mental picture of it.
If such a link is persistent, and of a sufficient
quality then
those node (and only those nodes) would route between
communities using bmx.
And why not just BGP? So why using a routing protocol which was
optimized for wireless links to run over something which is not a
wireless network anymore (but an abstracted L2 Batman network,
which might be somewhere deep in a wireless network, but none of
this is seen to BMX)?
The only thing you need is "network is available"/"network is not
available" announcements which knows how to read Batman community
IDs, no? You don't really need packet loss measurements for
wireless links?
Can Batman on one node participate in multiple communities at the
same time?
Have you seen this?
http://www.open-mesh.org/projects/open-mesh/wiki/Connecting-Batman-adv-clou…
So I do understand that you need some kind of L3 routing protocol
on borders between L2 routing domains. But I am not exactly sure
how this would work as a generic auto-configuring firmware. For
example, if we have two L2 mesh networks:
------------ ------------ |
[gateway1a]--link A--[gateway2a] | | mesh 1 |
| mesh 2 | | [gateway1b]--link B--[gateway2b] |
------------ ------------
I am not sure how could gateway1b and gateway2b be one device, one
node? And with an auto-configuring firmware?
Both mesh 1 and mesh 2 are big L2 blobs. What I can understand is
that gateway1a and gateway1b is part of mesh 1. And gateway2a and
gateway2b part of mesh 2. They have between them each a special
network link, respectively. So gateway1a/b have their own IPs
inside mesh 1 and they also have IP inside the peering links. Same
for gateway2a/b.
So I know how to configure this manually. But I am not sure how
BMX6 running on gateway nodes can just discover this automatically?
And even more, how it can know over which link to route traffic?
Link A or link B? It does not have any special knowledge of how
well gatewa1a or gateway1b is connected to the rest of mesh 1. But
even if we ignore that (which is really a hard problem to solve),
the reason why BMX6 would be useful is because link A and link B
can be of different link qualities and you want to route over
better one?
And how does BMX6 then propagate this information that link 1 is
better than link 2 to clients in the mesh network?
And still, how you configure those links automatically?
I agree strongly that the way to encourage
adoption is to build,
use, and demonstrate. At the same time, we will make much more
progress if we can find ways to collaborate. I tend to agree with
the comments regarding in-person collaboration. Perhaps it would
be possible for you to come and talk things over when Pau and
Roger are in the states?
I agree that discussion in person can help. But sooner or later we
have to write something down. If you already have clear image what
you want to build, then just write this down. Discussions are
important if we need to create a solution. But in this case you are
saying that you already have a solution. Can you just write this
down?
Mitar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9kQFAAoJEAX7rWpc+YnNcwkIAIpBZoUfoWj+hylKPITGBMv7
zBh/TUufvPBkCl12Nf5W5dUDT1jqYnpYC07Kp7i/Iujwh3ii5WofIXQ8b3C878ux
WQJ6eVyqjtyAk7oyH8G2UfJBOrK4vsLhXNugUbcaL5gQcHjqTAXQMAdbywW/q9vY
oIAVCjLHvAu65X72VsFfvVFcLB0ZoNY2YJpyfCE/+21nwABsjdKwQHCL8yfH+ctM
raUEJ2KAFkmnCDHsjQj9FTu2eazBVaJ5gnqGS8Z9hWpBbE5gygeymQO724YR2M2E
3lEJPdgsb4/DmGQjnWP0rb5quklK7jZEvlkCwUxc68/JcK3F0qnscTqLavMQ2/I=
=RyzU
-----END PGP SIGNATURE-----
7:53 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
CCed libre-mesh mailing list.
On 29/07/13 12:29, Pau wrote:
Hi.
First of all, running layer3 protocol over layer2 protocols would
be completely stupid, so just discard this idea.
The Isaac explanation is right. But as said the scope of libre-mesh
is to be compatible with most of the possible scenarios, so what
Isaac said is just one of the models libre-mesh will be able to
support.
Another scenario (the one I like more) is having small batman-adv
communities (let's say a building, a neighborhood or maybe a
district). These communities are connected with other communities
using layer3 protocol (such as BMX6). So at the end you can end-up
in a city with 20 bat-adv clous connected all of them with BMX6.
The selection of the border-nodes have to be made automatically
(to scale better and to be as easy as possible for the normal
user). So there will be a mechanism to discover if a node is
border-node or not (if it is connecting with another node which is
using anode batmand-adv ID**). It can be achieved by a very simple
protocol based on ICMPv6. So, once a node see that he is a border
node, it starts BMX6 automatically to start sharing routes between
both batman-adv clouds.
Following this approach libre-mesh will be able to cover both
scenarios depending on the user needs:
- A big bat-adv cloud for all the city (if batman-adv ID is the
same for all nodes).
- A lot of small bat-adv clouds connected with BMX6 (each small
community decides the batman-adv ID to isolate from other small
communities).
At this point I believe you understand why using a mesh dymanic
routing protocol instead of BGP.
Please, take a look again on the diagrams I included in my first
mail, they are trying to explain it.
** batman-adv ID is the VLAN tag used to isolate clouds
Cheers
On 29/07/13 05:09, Mitar wrote:
- --
./p4u
Hi!
> but I don't think you're correct in
your assesment of how the
> system would work.
Probably. :-) I don't have a clear mental
picture of it.
> If such a link is persistent, and of a
sufficient quality then
> those node (and only those nodes) would route between
> communities using bmx.
And why not just BGP? So why using a routing
protocol which was
optimized for wireless links to run over something which is not a
wireless network anymore (but an abstracted L2 Batman network,
which might be somewhere deep in a wireless network, but none of
this is seen to BMX)?
The only thing you need is "network is
available"/"network is not
available" announcements which knows how to read Batman
community IDs, no? You don't really need packet loss measurements
for wireless links?
Can Batman on one node participate in multiple
communities at
the same time?
Have you seen this?
So I do understand that you need some kind of L3
routing
protocol on borders between L2 routing domains. But I am not
exactly sure how this would work as a generic auto-configuring
firmware. For example, if we have two L2 mesh networks:
------------
------------ |
[gateway1a]--link A--[gateway2a] | | mesh 1 | | mesh 2
| | [gateway1b]--link B--[gateway2b] |
------------ ------------
I am not sure how could gateway1b and gateway2b
be one device,
one node? And with an auto-configuring firmware?
Both mesh 1 and mesh 2 are big L2 blobs. What I
can understand
is that gateway1a and gateway1b is part of mesh 1. And gateway2a
and gateway2b part of mesh 2. They have between them each a
special network link, respectively. So gateway1a/b have their own
IPs inside mesh 1 and they also have IP inside the peering links.
Same for gateway2a/b.
So I know how to configure this manually. But I
am not sure how
BMX6 running on gateway nodes can just discover this
automatically? And even more, how it can know over which link to
route traffic? Link A or link B? It does not have any special
knowledge of how well gatewa1a or gateway1b is connected to the
rest of mesh 1. But even if we ignore that (which is really a
hard problem to solve), the reason why BMX6 would be useful is
because link A and link B can be of different link qualities and
you want to route over better one?
And how does BMX6 then propagate this information
that link 1 is
better than link 2 to clients in the mesh network?
And still, how you configure those links
automatically?
> I agree strongly that the way to encourage
adoption is to
> build, use, and demonstrate. At the same time, we will make
> much more progress if we can find ways to collaborate. I tend
> to agree with the comments regarding in-person collaboration.
> Perhaps it would be possible for you to come and talk things
> over when Pau and Roger are in the states?
I agree that discussion in person can help. But
sooner or later
we have to write something down. If you already have clear image
what you want to build, then just write this down. Discussions
are important if we need to create a solution. But in this case
you are saying that you already have a solution. Can you just
write this down?
Mitar
_______________________________________________ mesh mailing list
mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9oH9AAoJEAX7rWpc+YnN4cUH/2MXqLVEQjQMpkEDifKBeA7C
Rpwd0FfYb3xTRqaykK2O0zfS8g5z6KQKjxqw+HEen0VELPNcedeMu2n5AVvsSdvQ
YPwmBgHMeA5WxQUAM5TO+CsF03+veKTkE26ZynVsp2ZQojv/uCa22BustKYZXiZq
hB2o03Rx03JnM6GFB0b4cLzmw3rHWSApuFGj7Fa7uwrdQRrPIW5k12R72zNDJzWT
0EijNQADhSctIhdB2LRpXeYkLbdaSLcseHuY0oAwTfIblbugsgDFnR96iwffXdF+
YeY2YdGQh2uzZsa2PVD4/1DE2iVQf4/J/UCRBWSZSRBLLLMrS5hRwMFLm/tXU78=
=PcuD
-----END PGP SIGNATURE-----
31 Jul
31 Jul
4:17 a.m.
Hi!
At this point I believe you understand why using a
mesh dymanic
routing protocol instead of BGP.
Not really. BMX6 cannot really measure any packet loss over Batman
clouds because all the packet loss is abstracted away anyway, no? So it
sees whole Batman cloud as one hop? Still, for best performance, some
information from WiFi layer below should be available to BMX6. This is
why I am not sure if BMX6 is suitable. Probably it would be easier to
adapt Batman itself to be able to do some simple L3 announcements on
border nodes? It would have access to underlying data as well.
But yes, BMX6 can probably work as well and the job. I am just unsure if
it is the best option for the given task. BMX6 was developed with some
other design parameters (running on wireless mesh, measuring packet
loss, finding the best path there) and now you are moving it to some
other problem domain. Maybe BMX7 would be more suitable. :-) BMX7 which
would talk with underlying Batman and collect real link quality
information. Because if it does not talk with it, then maybe something
like running cjdns on top of those Batman clouds to merge them together
would be more suitable? You would get crypto for free. And you would not
care about physical topology anyway.
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
6:41 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 31/07/13 13:17, Mitar wrote:
Hi!
Yes, BMX6 will measure packet loss too. Border nodes will have BMX6
enabled, but each BAT-ADV cloud will have as many border nodes as
possible. As said, a BAT-ADV community can be a single building and
the next building will be another community, both can be connected by
several BMX6 links, and even the border-nodes can connect between them.
So you can end up with any kind of crazy topology which BGP cannot
manage as good as any mesh routing protocol. Also, probably most of
these links will be WiFi so having a protocol which bases its metric
in the packet loss would be a good idea.
At this point I believe you understand why using
a mesh dymanic
routing protocol instead of BGP.
Not really. BMX6 cannot really measure any packet loss over Batman
clouds because all the packet loss is abstracted away anyway, no?
So it sees whole Batman cloud as one hop? Still, for best
performance, some information from WiFi layer below should be
available to BMX6. This is why I am not sure if BMX6 is suitable.
Probably it would be easier to adapt Batman itself to be able to do
some simple L3 announcements on border nodes? It would have access
to underlying data as well. But yes, BMX6 can probably work as well and the job. I
am just
unsure if it is the best option for the given task. BMX6 was
developed with some other design parameters (running on wireless
mesh, measuring packet loss, finding the best path there) and now
you are moving it to some other problem domain.
I don't know how deep is your knowledge about BMX6 but it is *NOT*
just designed for WiFi links. In our networks with bmx6 we are mixing
wired and wireless.
Maybe BMX7 would be more suitable. :-) BMX7 which
would talk with
underlying Batman and collect real link quality information.
Because if it does not talk with it, then maybe something like
running cjdns on top of those Batman clouds to merge them together
would be more suitable? You would get crypto for free. And you
would not care about physical topology anyway.
During the WCW Axel, Simon, Guido, Nico, Giohack and me were talking
about a small daemon named two-faces which will share metrics between
Batman-adv and BMX6 to be able to get more profit from this
dual-protocol setup. But for the moment it is not implemented so we
have to deal which what we have now.
Mitar
I'm going in vacations for some weeks, so I don't think I will be able
to reply more mails.
Cheers.
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR+RP+AAoJEAX7rWpc+YnNPNIH/j7hCDlkGqviIrr8cEg1AJws
z1oxSn+AbWQCARLIWXkhDbOlFCJHnnbKFpl3pdyC0VOHWtHI4m7VBGzaQt0uu2Mb
RdpHplE2EeaoxZawYJk5GezfQUhlCH6Hcw3SsfKajDXkeZ0qp4n0Q4p3qpVfVZMd
FhsCQrjeuX1iucKYM3Ivso5psMT1P60EmBnYSDEG2Hd0Je94eIIiFMg/zNxdf/ls
tVfnZ3dcLwUxbNmGurS5U1TKIBgz3hj9kt6f5qJEyVN0PxCz7T25LE+/D5hssgoK
t5+n//Yg7NxkupjuQ7iqX9hdFHeFqtTbi3U7OT3ehMiWmJqgrnqjtr9vAzcHIzw=
=594B
-----END PGP SIGNATURE-----
7:53 a.m.
(rah rah networking rah rah theory rah rah practice rah rah..)
... build it (again) and try!
-adrian
7:50 p.m.
Hi!
Also, probably most of these links will be WiFi so
having a protocol
which bases its metric in the packet loss would be a good idea.
No, they will not be WiFi. They will be some abstracted away L2
LAN-look-alike. They will have no idea about underlying WiFi links.
I don't know how deep is your knowledge about BMX6
but it is *NOT*
just designed for WiFi links. In our networks with bmx6 we are mixing
wired and wireless.
What I am saying is that it is designed with assumptions of direct
possibly lossy links (wireless or wired) and not with assumption of some
strange blob of multiple nodes which behave like one giant L2 LAN blob
where you send a packet and it just works and is once routed over one
path over physical links and another time over another packet.
During the WCW Axel, Simon, Guido, Nico, Giohack and
me were talking
about a small daemon named two-faces which will share metrics between
Batman-adv and BMX6 to be able to get more profit from this
dual-protocol setup. But for the moment it is not implemented so we
have to deal which what we have now.
Yes. I think more we will peer between our networks over wireless in
general, more a need for such a daemon will be. We are getting to the
point where this is really needed. So not just for peering smaller
clouds, but for peering whole networks together.
I'm going in vacations for some weeks, so I
don't think I will be able
to reply more mails.
No problem. You were really helpful with explanations and making me
better understand your ideas and plans. Thank you very much!
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
28 Jul
28 Jul
3:09 p.m.
We will all have to take our approaches and see what shakes out.
Competition/forks/different approaches are what its all about! :)
Mitar <mitar(a)tnode.com> wrote:
Hi!
just
in
(including
the
have
--
Charles N Wyble (818) 280-7059
CTO/Cofounder Free Network Foundation
http://www.thefnf.org
BMX routing between batman-adv domains is the way
to go. It's a
fairly standard network design pattern (l2 edge/l3 agg/dist/core).
This is what you say but I simply cannot agree with that. It is a
stupid
approach, if I understand it correctly (running L3 routing protocol
over
L2 routing protocol). Write to the Batman mailing list and get
confirmation that they agree this is the way to go.
It will become the standard as the FreedomStack
sees widespread
deployment over the coming months.
I really doubt FreedomStack will see widespread deployment if your
networking stack will be such a combination. From what I know them,
nobody will move to that (except those who are already using BMX). :-)
But good luck making such a standard. Standard is not made by defining
one, but by using one. Currently, you are not really convincing. When
asked about some whitepaper explaining your rationale and architecture,
you are saying that we should call each other and talk. If this is your
approach to making your firmware popular, then even if the firmware
scales, your way of promoting it will not scale.
I really hate solutions where people think that because they like
features of A and features of B, let's just use both at the same time
and we will have features of A+B. Invest time to or move features from
Batman you like into BMX or to move features from BMX you like to
Batman. This is how the progress is done. Don't be afraid to code and
steal good ideas. This is what open source is about. This is what
happens between FreeBSD and Linux. Stealing (or rather, should I say
sharing - because none loses anything) from each other. But if somebody
would come and say, run FreeBSD and Linux at the same time and you will
have features of both ... Ehm ... In theory, this is doable. You can
have multiple kernels loaded at the same time. But how will this
interact? How much more complications will you have? What is the right
approach is to take features from one and put it into another.
Mitar
Pau <pau(a)dabax.net> wrote:
On 28/07/13 02:50, Mitar wrote:
>>> Hi!
>>>
>>>> Well, this kind of discussions is what I was trying to avoid...
>>>> but it is my fault for starting it.
>>>
>>> No no. It is important to discuss this things. You cannot just
>>> believe that people would just take some firmware without trying
to
>>
understand it and reasons for why something is like it is and not
>> some way around? So don't see this as a flame but more as a way to
>> teach/show.
Of course people should ask and understand before choosing some
specific existing solution. But I did not want to start this kind of
discussion here (in this post). I just wanted to let you know about
libre-mesh project.
Also I feel like you are trying to find some "week points" in our
approach to be able to say "it does not work for us" and I have to
defend it to convince you. I don't feel comfortable doing this, I wanted to let you know about libre-mesh because I
have seen in your
WiKi many points in common with us. But of course the decision is
yours.
OK,
>>> It is exactly what we are doing.
Please see our repositories you
>>> will find lime-packages which is an OpenWRT feed.
>>
>> Great!
>>
>> This maybe means that talking about "firmware" is not the right
>> word. But more about a set of packages? Because then it is easier
>> to imagine that another community network takes few of those
>> packages and add few theirs and maybe even then put them all
>> together in one feed for later community network to build upon.
I like "firmware" more than "set of packages" because at the end
libre-mesh will be a firmware (software for embedded devices). But it is just a way to refer to the same thing.
you
>> So I think the most important thing is
not to see firmware as one,
>> but to learn which problems/issues you already solved with which
>> packages and see how to build upon that and contribute back, no?
>>
>>> Well, I would not say "few small scripts", it is a bit more than
>>> that. I don't know about which firmware are you speaking about
>>> but in my experience if you want to end up in a stable, powerful
>>> and flexible system you need more than "few small scripts".
>>
>> Can you maybe just show us few examples of such scripts? Just so
>> that it is easier to imagine what kind of things one have to think
>> about when developing a firmware?
It is not yet done in Libre-Mesh because it is in development. But can surf over the qmp.cat git repository to see
the amount of code we
have (just the luci-based web iface is more than a "few scripts").
If you want to do a generic solution (like libre-mesh) you need a lot
of code to adapt to any scenario. But of course, if you want to have
a
solution just for your network, the amount of
code could be quite
small.
>>>> Ask yo AlterMesh guys who are starting having problems with
>>>> scalability. Can you imagine which is the total amount of ARP
>>>> packages in a 1000 nodes bat-adv cloud? (just to put an example)
>>>
>>> So only ARP packets are the issue. Other broadcast packets you can
>>
simply drop with a ebtables firewall rule. You can still use
>> ZeroConf, because it is multicast and not broadcast.
Using ebtables is dirty and a patch to solve something that layer3
solves. And have you thought about IPv6? It does not have broadcast
but multicast link-local domains which can end-up in a big storm too
(RA announcements and requests).
>>> And for ARP packets Batman could probably provide some fake proxy,
>>> where the node would answer them directly instead of broadcasting
>>> them around. Or maybe tunnel them directly to the node who can
>>> answer them. (Because Batman knows exactly where any MAC address >>
the network is. You do not really have to broadcast around to get
>> this.) In a similar way that Batman currently handles DHCP by
>> intercepting the packets and responding itself.
Hey Mitar, would you try to layer2 bridge all the Internet? Or even
just your city? Collision domain is for small sets of computers, the
networking stack we are using based on MAC/IP is not ready to have 1k
computes in the same domain. Broadcast storms, ARP problems poisoning!), huge overhead just to mention some
of the problems you
would have. IMHO trying to patch it by modifying batman-adv is a
mistake. Layer3 routing is exactly done to solve these situations.
3
>> So I am not sure that it is smart to add
another layer (another
>> routing protocol) of complexity to the networking stack, where we
>> could just learn and build upon existing tools. As you said, if I
>> paraphrase, not yet another routing protocol. Cannot we have just
>> one and all contribute to that one? So if Batman works in most
>> cases, let's fix those cases where it does not.
Guido already answered you and I agree with what he said. We had
several meetings with the Batman-adv guys and everybody accepted it
was a problem which has to be fixed using a second routing protocol.
It is complex to explain, if you want we can organize an audioconf.
>>>> Quagga is a suit which includes several routing protocols.
>>>> Quagga could be used to federate bat-adv and bmx6. But if you are
>>>> speaking about use static routing, I would just say it is a big
>>>> mistake (what happens when you have to paths to the same
>>>> cloud?).
>>>
>>> So are you saying that BMX should be run over whole mesh on layer >>
with Batman below on layer 2? Or are you saying that it should be
>> used only on gateways. I am not sure what exactly you are saying
>> here. Do you have some more concrete example/presentation of this
>> idea? So how does one packet travels around the network in your
>> topology of BMX + Batman?
>>
>>> I agree with your approach about compare overhead and routing
>>> changes. However I can say this test was made during the
>>> WCW-Berlin.
>>
>> For others, WCW is a yearly mesh-related even in Berlin, Wireless
>> Community Weekend:
>>
>> http://wiki.freifunk.net/Wireless_Community_Weekend_2013
>>
>> More locally targeted for the whole Freifunk community to get
>> together from all around the country, once a year. (So most of the
>> stuff you will find will probably be in German. :-) )
>>
>>> The scenario was around 15-20 nodes (ask UFO to to know it
>>> better) in a mobile scenario (it means someone moving nodes). All
>>> protocols were running at same time in different VLAN (see
>>> battlemesh firmware in github) so all of them were in the same
>>> situation.
>>
>> Is there any description of the scenario? So if they were just
>> moving the nodes around without communicating with the node at the
>> same time, then this data is useless.
Mitar, you have been in the BattleMesh before. You know this is not a
perfect research environment. But Axel, Henning, Jow, Simon, Elektra
etc... were there supervising the experiments so I want to believe results obtained are relevant since the elite of
the mesh networking
was there.
overhead
>>> Just to give you another detail, the
tested protocol which
>>> showed more difference between moving and not moving environment
>>> was Babel.
>>
>> This might be just that Babel adapts in a smart way to the moving
>> and starts sending more updates. :-)
I don't think so. Babel acts as a static protocol when the network is
not moving, but when it moves it produces a very very high overhead
(compared to other distance-vector protocols). I don't see this very
smart since for static deployments you could do the same using BGP or
OSPF.
>>>> By the way, the conclusion of this tests was: BATMAN based
>>>> protocols are better in the overhead-mobile test.
>>>
>>> Yes. Their ways of updating the information about the network
>>> topology is really interesting and charming. But sadly the >>> is not the only thing which matters.
Speed of convergence to new
>>> topology, no routing loops, and no disruptions in service are
other
>>> which are important as well.
Personally, I would not really care
so
>>> much if routing protocol has bigger
overhead if this means it
works
>>
for people.
Of course it is not the only important thing. However in the last
BattleMesh, BMX6 was the better in coverage time and in best-path
selection. You have the results raw data in the battlemesh web page.
>>> And in general nodes do not really move around so much. Clients do >>
(Batman has roaming support for them), but nodes, not really. At
>> least until we have nodes installed on cars and bikes. Nodes do
>> come up and down and at that time it is not so important how fast
>> new topology converges, that is true.
It will depend on the environment. The scope of libre-mesh is cover
any kind of deployment.
>>> Cheers, Mitar. Hope to see you in
October.
>>
>> Sadly, I will not have time to attend the summit this time. :-(
>>
Let me ask you something now. Is there any other "hacker" in this
project which knows about mesh networking? How many people do you working on firmware? I hope this conversation is
useful for someone
else because at the end we are always the same people discussing the
same things (I did not know you were involved here!).
Cheers
--
http://mitar.tnode.com/
https://twitter.com/mitar_m >> Mitar
>>
_______________________________________________
mesh mailing list
mesh(a)lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh
3943
days inactive
3948
days old
21 comments
6 participants
participants (6)
-
Adrian Chadd -
Charles N Wyble -
Gioacchino Mazzurco -
Isaac Wilder -
Mitar -
Pau