Hi,
Currently, broswing to https://libre-mesh.org/ results in: 502 Bad Gateway
and http://libre-mesh.org directs by to a map (NOT the unsecured
libre-mesh project side).
Anybody available and able to fix that problem?
thanks
/axel
-----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:
>> 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
>
>
>
> _______________________________________________ mesh mailing list
> mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh
>
- --
./p4u
-----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-----
-----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:
> 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.
It is exactly what we are doing. Please see our repositories you will
find lime-packages which is an OpenWRT feed.
> 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)?
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, 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?
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?).
>> 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.
>
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.
> 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-----
On 07/28/2013 06:53 AM, Mitar wrote:
> Hi!
>
>> We had several long, insightful discussions with the bat-team in Aalborg
>> last battlemesh, it's a pity you couldn't attend :(
>
> Are there any summaries/minutes of those discussions? Because it seems
> you have more knowledge about this and it would be sad that it would
> stay locked just into discussions. Even if we meet on mumble, I will
> maybe understand, but ideas and conclusions you are presenting still
> would not be available to others. I think the best would be to write
> this things down. There are measurements, there are all the discussion
> from all the mesh events and it seems there is a common idea of "best
> practices" shared by routing protocols. Could this be written down
> somewhere and then it will be easier to understand?
Writing things down is important, but takes time, and emails take even
more time :)
At the battlemesh, I was left with the cristal clear conclusion that the
bandwidth of information flow in a physical meeting is incomparable to
any other kind of communication
meeting >>>>> video >> voice >> chat/email/etc
in a week i learnt much more than i could have read in a year, let alone
write down
The executive summary of what we envision for libre-mesh (guys just like
you Mitar, which met for the first time in april, and in a couple of
physical afternoons agreed on a common working ground, after months of
mail-misunderstandings) is published on http://dev.libre-mesh.org/, and
is soooo similar to
https://sudoroom.org/wiki/Mesh/Firmware
that i think if we meet, in an afternoon we'll be working together.
until then, let's start writing down... code!
so, let's show each other code, and i'm confident all doubts and
questions will settle themselves out, or be discussed over real,
concrete designs and experiences :)
>
>> i'm really looking forward to meet you Mitar! maybe we can at least have
>> a mumble one of these days?
>
> Sure, we could! But I believe the best would be first to write things
> down, for others in the network and in general for all community
> wireless networks.
>
>
> Mitar
>
-----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-----
Hi guys,
Guido and I will be working during the whole next week on libre-mesh stuff.
Our work time will be starting at 12 UTC every day of the week.
We would like to work on this topics:
* properly debug and report outstanding batman bugs: OGM starving and
ttvn drops.
* test the configuration guido and gioaccino did in Berlin on a local
testbed.
* start working on auto-configurtation scripts, looking into the
existing work done during the battlemesh and afterwords.
* luci-based web interface for antenna alignment
It would be nice to work together with the rest of you if you have some
time available during the week, so we can get the ball rolling.
Cheers,
Nico
Hi txantxitos,
I wanted to let you know that after some weeks of network instability
here in Quintana while we tested a more recent revision of
OpenWRT/AlterMesh I am now done with that so I can get back to other
things. How about your time schedules?
Could we agree on an IRC (#libre-mesh) meeting for this week to organize
the work ahead?
It could be Thursday at 4PM Barcelona, 11AM Buenos Aires for example.
Are you guido on a plane at that time or is it oK?
Cheers,
Nico
PS: I am seeing an error (502 Bad Gateway) in:
https://dev.libre-mesh.org/
Guido could you have a look?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maybe this can be of some use to us... it would also be an excuse to
interact with the Commotion guys.
cheers,
Nico
- -------- Original Message --------
Date: Wed, 29 May 2013 10:03:56 -0400
From: Dan Staples <danstaples(a)opentechinstitute.org>
To: nodogsplash(a)ml.ninux.org
Subject: [Nodogsplash] LuCI page for configuring Nodogsplash
Hi all,
As part of another project, I created an OpenWRT LuCI page for
configuring Nodogsplash (similar to luci-app-splash). It lets the
administrator set leasetime, which interfaces/zones to captive portal,
whitelist and blacklist MACs, whitelist IP ranges, and set the splash
page text. It's certainly not all the Nodogsplash options, but enough
for a simple setup.
The Nodogsplash default splash page I include also uses a simple
javascript redirect to point to a LuCI-created splash page, which allows
you to use your router's web interface theme and include LuCI
headers/footers and whatnot on the splash page.
Just wanted to throw it out there in case it would be of use to anyone.
The source is here: https://github.com/opentechinstitute/commotion-splash
I would love feedback on it if anyone has any. I also haven't tried it
on vanilla Attitude Adjustment, I've only used it as part of the
Commotion OpenWRT-based firmware. So the one caveat is that it depends
on a small lua file being present in /usr/lib/lua/, which can be found
here:
https://github.com/opentechinstitute/luci-commotion/blob/master/luasrc/comm…
cheers,
Dan
- --
Dan Staples
Open Technology Institute
https://commotionwireless.net
_______________________________________________
Nodogsplash mailing list
Nodogsplash(a)ml.ninux.org
http://ml.ninux.org/mailman/listinfo/nodogsplash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBAgAGBQJRpi7dAAoJEPHORz17N0TFOKYIANRQuLr74RU+H0rtXa26KInh
cWOLlrYLi6sjB02NFL1kID7C2pVaWV+F/oYghTs//Z9PZM1EwmqP3OZwm4mB4Vni
EWxN8Ol+Mlf2XVJkntAlSNEShzNFrt9VDt6dz1+eJ43Pwy21IYFdJ1wfXpKvkRQ5
/UkajGkAKk5Pl2jAy7r3WBwIUh74KlpyklEQvQlkbWdTZk1SezErci2HbTGo5VLz
MI69cYtoHNLcDH8ChHQAooTCnTH3OgWEte2t6ZMZBcz03hFpV91PIb+HlKBBtLpS
zrZWDctHal5hoKP37wv582nLPWClr9onc+AtAHs7UTESNI5798xf+5B/S3qjOR4=
=qqdW
-----END PGP SIGNATURE-----
In eigennet firmware we really didn't have a build system, so have an autconfig
script inside the device make a lot of sense, but in libre-mesh we have lime-
build and chef, so were we put the limit between autobuild and autoconfig ?
Autoconfig works well on simple devices like picostation or nanostation, but on
more complex setup like the black tplink is not the good approach, so i was
thinking about completely moving to a build + profile system without or with
minimal autoconfig script on the device
what do you think about that ?
Hi Pau and SAn,
during the brainstorming sessions that gave birth to libre-mesh we
talked about integrating qmpfw and the firmware Chef.
Pau and SAn are the guys behind the development of these tools, maybe it
would be interesting to start coordinating how this can be actually
implemented?
Cheers,
Nico.
