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?
Some times ago I downloaded and compiled LiMe as suggested on your site:
git clone https://github.com/libre-mesh/lime-build.git
make T=ar71xx J=4
Now I would like to build an updated image, how should I update all the repositories (openwrt, libre-mesh, luci...)?
Is there something like a "make update" ?
Thanks 'n' bye,
Some thoughts about my experience with libremap.
1. Routers -> Cluster should be disabled by default IMO
2. Same for filter links, since it is quite common to have "not perfect"
links in a wifi community
3. Would be very useful to have more view levels. When there are some
routers close you cannot see the specific position. In the other hand,
Altermap allows to make quite more zoom, so this should be possible in OSM.
4. Would be nice to have a "LuCi" web plugin to manage the
/etc/config/libremap agent. Is there something developed? If not I can
5. I would like to create some specific plugins, for instance to send
bmx6 information to the server. I see how the plugins work in the node,
but I miss the web page part. Is there some "easy way" to add new
plugins in the web page?
some months ago in a sprint, we finally both sat down together with Nico
to fight with lua, and at some point stumbled upon this
This is a collection of Lua libraries for Lua 5.1 and 5.2. You can load
the standard set with
then i found out about luarocks, which is analog to ruby gems and python
and from there, other interesting libraries
This function transform any Lua table into a human-readable
representation of that table.
The objective here is human understanding (i.e. for debugging), not
serialization or compactness.
(Dedicated to Nico, a python programmer horrified by lua being
unable to print(table))
O projeto Luno tem o objetivo de prover API's para uso com a
linguagem de programação Lua que visem a facilitar a execução de tarefas
corriqueiras mas que não estão diretamente implementadas pela biblioteca
padrão do Lua.
Luno conta com os módulos luno.string, luno.table e luno.io. Esses
módulos provêem funções extras para manipular strings (trim, split,
join, charAt, ...), io (getTextFromFile, ...), tabelas (imprimir
tabelas, concatenar, ...). O módulo luno.util provê funções de uso geral
como cópia (deep copy) e impressão (deep print) de variáveis.
finally, i found the following blogpost enlightening, it's a thorough
summary of differences and unexpected things, very helpful for me,
dealing with lua for the first time
hope that helps someone,
Hello, I remember first times with Freifunk firmware (OpenWrt White Russian):
They put in main web page a link with a direct download of image that was working in same router. I suposse that it was generated from binaries when you click on.
I think is a very good tool to make network bigger with same routers (you don't need to connect to any place to get firmware). Do you know about that?
I think we can put it on libre-mesh (and also I need it now to make easy an exact copy from one of our libre-mesh routers here in Garraf).
I've added a news entry in the libre-mesh page to endorse the WBMv7:
Who is interested on going there? Do you have funding? Any idea about
where can we find funding to bring some of you there?
Seems an interesting device, maybe we could receive someone if we ask as
---------- Forwarded Message ----------
Subject: Re: [OpenWrt-Devel] is anybody working on supporting Linksys
Date: Thursday 16 January 2014, 10:37:12
From: Peter Lawler <openwrt-devel(a)bleeter.id.au>
On 16/01/14 10:06, Peter Lawler wrote:
> Oh, bad me for replying to myself... but from the press release page:
Even worse, replying to my own reply
Further down that page is commentary about OpenWRT, DDWRT etc.
It also mentions they're planning to release devboards to developers.
It also gives a name, email address and phone number for a contact about
I'm not in the same TZ as the contact, by ~15 hours. Maybe someone on
this list who is a little closer could call up and ask what's what ;)
openwrt-devel mailing list
I compiled libre-mesh encountering only a small problem: subversion is
needed but missing in the dependencies list.
I was planning to flash libre-mesh on Ubiquiti PicoStation and Ubiquiti
Can I safely flash using
and openwrt-ar71xx-generic-ubnt-nano-m-squashfs-sysupgrade.bin or some
configuration is needed before compilation or after flashing?
Thanks and bye,
Ilario, Ninux Verona.