I'm Ilario from NinuxVerona (Italy), in NinuxVerona we use Libre-Mesh
but up to now we have only one wireless link
I registered on the libre-mesh site but the confirmation email never
arrived, now the "lost password" page says "An email with instructions
to choose a new password has been sent to you." but I can't see any email.
Is it possible to become an editor of the libre-mesh site?
I have compiled the firmware using lime-build for tl-mr3020, and then
installed the firmware on two routers. The mesh works, they can see
each other and I can connect to them as Access Points. Now I have two
1. How do I connect a router to the Internet?
2. How do I share this connection with the mesh?
For (1), I tried scanning for wifi networks but I got an error that
libiwinfo-lua was missing. I connected to a network through ssh using
wpa_supplicant and installed libiwinfo-lua, so now I can properly
connect from the web interface. It seems libiwinfo-lua should be
installed by default, shouldn't it?
For (2), I'm not quite sure how to proceed.
so, we've scratching our heads today, facing some MTU issues on our
shiny new libre-mesh network,
and after a few hours debugging, tcpdumping and discussing, we came to
* the invented src-addr in the bmxOut tunnel makes it impossible for
hops along the path to return "Packet Too Big" to the originating node.
So, if a particular link has a smaller MTU than the first link (say, a
VPN is involved), the packet will be silently dropped.
A wants to send a packet to a network announced by D; so it creates a
tunnel with D as destination, and a "D-derived" fake address as src,
that matches the bmxIn "catchall" tunnel peer-addr in D
Then sends a 1460 + 40 = 1500 bytes packet through that tunnel,
B cannot push that packet to C, then tries to send back a ICMPv6 PTB...
but the src-addr it finds in the encapsulation is not A, but instead the
"D-derived" fake addr. Then, the ICMPv6 PTB is lost and A can never find
out about the smaller MTU.
This fundamentally breaks PMTUD which is a bad idea in IPv6
to avoid this there are 3 options:
* set mtu=1280 on every bmxOut tunnel (yuck! :( )
* probe before establishing each tunnel, with the real src-addr so that
PMTUD can happen correctly, until it reaches the desired endpoint node.
Then, use discovered PMTU for new tunnel. (*downside*: this will only
work as long as path doesn't change to pass through some thinner link.
In that case, PMTU will not be rediscovered, and packets will be dropped
* use the current bmxIn "catchall" tunnels only for sending special bmx6
control packets, that ask for a symmetric tunnel.
1) A sends to D (2001:db8::D) a packet (encapsulated with a fake
src-addr, to be catched by the catchall @ D) with content "I'm A and
this is my real address 2001:db8::A; please make a dedicated tunnel for me"
2) D gets that packet and creates a tunnel with "peer 2001:db8::A", then
sends back an ACK to A, again using "A-derived" fake-addr as src
3) A gets the ACK and creates the tunnel with "peer 2001:db8::D"
*** now both ends have a symmetric tunnel between them, with real src
and dest address ***
4) A finally sends the real payload through the symmetric tunnel, this
payload (may be bigger than 1280, say... 1450) will be encapsulated with
the real src-addr of A, so if any node in the path needs to send back a
Packet-too-big, will be able to, and PMTUD will happen correctly.
(at the cost of a full RTT latency before the first payload packet, but
with a reasonable tunnel expire time as it has currently, that shouldn't
back in April, i remember we discussed the idea of symmetric tunnels,
and you brought up this "control connection" idea which i'm simply
But that discussion was in another context, more like a 'feature', and
finally didn't really solve the idea we had originally,
yet, this PMTUD issue was not taken into account AFAIR, so the
"symmetric tunnel" idea now becomes more like a bugfix (i.e. don't
create PMTUD blackholes)
what do you think?
I have already published it on the blog:
I have selected Software as kategorien, Is it correct? let's me know if
something is wrong so I will change it
thank you!! ;)
2014-05-09 14:04 GMT+02:00 Mario Behling <mariobehling(a)gmail.com>:
> Please let us know when your posts are in the final version and if you
> want to publish it yourself on the blog or we should do it.
> On May 8, 2014 2:44 PM, "Andreas Bräu" <ab(a)andi95.de> wrote:
>> Hi Francisco,
>> if you plan to publish your blog post at http://blog.freifunk.net I
>> could create an account for you.
>> Am Mittwoch, den 07.05.2014, 22:02 +0200 schrieb Francisco Jiménez
>> > Hi everyone!
>> > I have written the post for the Freifunk's blog here:
>> > http://pad.eigenlab.org/p/QPRE5WCuW0
>> > Feel free to contribute on it by changing, adding or removing things
>> > Thank you and regards,
>> > Francisco
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Freifunk GSoC Students" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an email to freifunk-gsoc+unsubscribe(a)googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
I have written the post for the Freifunk's blog here:
Feel free to contribute on it by changing, adding or removing things
Thank you and regards,
Hi from Garraf (Barcelona). Here we are with Gioacchino installing Libre-mesh nodes around and we are going to train a local group to lead Libre-mesh. People here use, understand and install guifi.net infraestructure nodes (RouterOS, AirOS, AP-WDS and BGP in both 5GHz and 2.4GHz), and they don't know more. So I just start to write a Libre-mesh HowTo oriented to this kind of base knowledge. I'm writing it in spanish and later I'm going to translate it to english and catalan. It's going to become a first approach to concepts like OpenWRT, ad-hoc, BMX6 and BATMAN-adv (without miths) for Guifi.net people.
It is based on questions and answers, so, if you want to help, you can write some questions or try to write some answer. I'm doing it ehterpad here: