Hello from Guifi.net - Catalonia.
People from a rural hacklab in Itatiaia (Brasil)[1] are going to suporpt a intensive project for start to develop a free, open and neutral network in rural areas in Brasil.
1st part of project start September 5th until 20th. We're going to research social, economical and technological reality in rural areas in Brasil, to make some links in this area and to develop free software for their needs.
Of course I was thinking to do it with Libre-Mesh in cheap routers and I hope some of you find this project interesting to come to work on it together. They pay travels, food and host for a little team (3-4 people).
I can not to decide who (they do it), but they tell me that if I know about people that have the profile that I contact them and say them that tomorrow 13th or 14th they are going to open the call to collaborators. So, you are the people with perfect profile :) They are going to choose first people that propose him or herself to the project.
At same time they are 3 or 4 other several projects about rural and tech's.
After this meeting we want to continue development of free networks in Brasil and we're going to work in to get more supporters in contact with "forumdainternet.cgi.br", "Tropixel" and "Saravea.net".
Thank you!
PD: Some of you can give me permissions to edit Libre-Mesh wiki? My username is "al". Thank you.
[1] http://nuvem.tk/
-----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-----
Hi!
Thanks to help of people on retroshare we achieved to have #libre-mesh on
freenode bridged with libre-mesh on RetroShare so now we can chat on bot
networks with all, the only glitch is that people on one network will not see
people on the other but just on the list, the messages will be relayed by the
Bridge nick that will report real author as part of the message
This is an important step, RetroShare is a P2P secure and encripted netwok, so
there is no need for servers, it is just like mesh but on layer 7 and it is
particular important because it will encourage local traffic instead of remote
one, and decentralization that is all good for our fredom networks :D
Also ipv6 for retroshare is in plan for 0.6 version ( we are at end of 0.5.x
series ;) so we will have it soon )
And i am developing the GUI for androis so we will have scure messaging on
phone too ( VoIP is in plan we already have some working plugin prototype so
soon secure call too :D )
see you!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
The web page is down again: http://dev.libre-mesh.org
Do you have problems with the server? I could find some server to
allow it if needed.
Cheers
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJSE0BZAAoJEAX7rWpc+YnN+roIALii6E3yiHJM7YeUxTLaq9qi
+I7Iz1Mui/eRhQ1Hiclul6akRnmFbXhOZ/kPepT889W9kUQVhg34CkF74S8mN+Tq
MMgLAK9+uel3dr1hXrd7a9od7NbEgCnzKPpyVCVVQ9hYOIoO2YYug6hyNMrlq4jl
HdEDSS1IpfUhIexWOgU6eLr/jJmyslfi+xIwtLbamwZ5MuZWAfLF3gZVsRM8LlwX
nIUT/epu5tUENgJcC8nDhHxHCcR9BAMZxzOEdY6wdXLHRSl4tHjQAdB9GvSaghpn
bUPf7siz8MEhpIuye7Xm3uBs7DyXdTsmAVdxYayIfudhn+iGofk38oYVuRyIC6E=
=opzk
-----END PGP SIGNATURE-----
----- Mensaje original -----
> De: "al" <al(a)blogmail.cc>
> Para: "libre-mesh developement" <dev(a)lists.libre-mesh.org>
>
> https://docs.google.com/forms/d/10bij_tMJSGkZrt2LYDhmI14Wo-xtM1O-oS0llG-481…
>
> Please developers, ask for your travel.
>
> They just opened call for collaborators. They're going to choose
> first people.
>
> It only take 10 minutes.
Organizators wrote "Guifi.net" in project. But it is a new free, open and neutral network based on Libre-Mesh.
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-----