-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
What do you think about this?
https://github.com/p4u/dhcpdiscover
Could be useful for us? It can be executed to know if there are DHCP
servers (different to you) in a network interface.
root@qMp76:/tmp# dhcpdiscover -i br-lan
DHCP ok: Received 1 DHCPOFFER(s), max lease time = 3600 sec.
root@qMp76:/tmp# dhcpdiscover -i br-lan -b 172.30.22.1
DHCP offer comming from the banned addr 172.30.22.1, ignoring it
DHCP problem: No DHCPOFFERs were received.
Could be used for knowing if a network device is plugged to a WAN
modem or not.
Cheers
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR3FUmAAoJEAX7rWpc+YnNtxAH/3YeM1OdlvPP1A3dXQOQC4Wl
bVC0i6F8JRU1sIWaFpLbEIFXteCgPn8EhGD0Li+77ZDkbKJT2vPuBLpgmumdGABb
38P04bTFj0Mag1mlUmF7RdyXpNOAofNBq0Ok4gWOp1AISwDOATFueOtuOZihkJVJ
HV8m7KvR9BLR9q1ssod5Hm/t7ca7n+pgCV39plmRMHOahwnR32PkuLZsbiniV3v2
qujV92/ymtCJR5Wv44iwGK0m8jl7GU9YJwUCvPXdVkXm+aY6cxyYU+t5m9l50yoA
gfTyQN57nK0Q/8GT0TrL4UUQpumdfqLRO3OynCDJkofAtCUIAlWDkpGWLD9oNTk=
=lGut
-----END PGP SIGNATURE-----
-----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
