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