Hey axel!
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
these conclusions:
* 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==1500==B---1400---C===1500===D
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
again.)
* use the current bmxIn "catchall" tunnels only for sending special bmx6
control packets, that ask for a symmetric tunnel.
i.e.
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
be terrible)
back in April, i remember we discussed the idea of symmetric tunnels,
and you brought up this "control connection" idea which i'm simply
redescribing here.
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?
Cheers!!
gui
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:
http://pad.marsupi.org/manual-de-libre-mesh-para-guiferos
I have written the post for the GSoC 2014 on a pad
http://pad.eigenlab.org/p/gsoc2014_blog_post1
As politics often permeate what I say I ask yours reviews to see if something
should be said in a more "politically correct" way before publication
Moreover I am not a native english speaker so correction are welcome too :)
If you choose to edit the pad please choose a color with good contrast in
repect to the one i choosed so i can spot esly differences
Thanks everyone :)
Hi
I heard an presentation last year in berlin about libre mesh. I was amazed about the idea to use clounds and a l3 routing protocol. I talked a bit later with Pau about a netsplit problem where one cloud is split up. Then alfred isn't synchonizing, so that the dhcp can't know wich ip is already in use. Is the problem resolved or further discussed?
Tim
(Freifunk Franken)
The Heartbleed bug allows anyone on the Internet to read the memory of
the systems protected by the vulnerable versions of the OpenSSL
software. This compromises the secret keys used to identify the service
providers and to encrypt the traffic, the names and passwords of the
users and the actual content. This allows attackers to eavesdrop on
communications, steal data directly from the services and users and to
impersonate services and users.
http://filippo.io/Heartbleed/#libre-mesh.org
/axel
PS: lists.libre-mesh.org seems ok
http://filippo.io/Heartbleed/#libre-mesh.org
The Heartbleed bug allows anyone on the Internet to read the memory of
the systems protected by the vulnerable versions of the OpenSSL
software. This compromises the secret keys used to identify the service
providers and to encrypt the traffic, the names and passwords of the
users and the actual content. This allows attackers to eavesdrop on
communications, steal data directly from the services and users and to
impersonate services and users.
/axel
PS: lists.libre-mesh.org seems ok
Hi Lime Folks.
Who is going to the BattleMesh?
It would be nice to make a talk about libremesh, the basics and the
current status. I would be part of the team presenting, but it would be
nice to have someone else with me.
Volunteers?
--
./p4u
Hi all!
Following the instructions [1] on your site I obtain a clean OpenWrt image, no LiMe packages inside, no bmx6, no batctl on the flashed antenna.
I noticed the presence of a broken link:
ls -l lime-build/
lrwxrwxrwx 1 ilario ilario 25 mar 15 15:00 files -> build/lime-packages/files
maybe this is the cause?
Running an old stile compilation worked [2].
[1] git clone https://github.com/libre-mesh/lime-build.git
cd lime-build
make T=ar71xx J=4
[2] cd lime-build/build/trunk
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig (and select LiMe packages)
make
[21:03:30] <g10h4ck> guii nicoechaniz how are you ?
[21:03:46] <g10h4ck> did you find the piece for server mounting ?
[21:06:16] <guii> nope :( it's carnival/holidays until wednesday
[21:06:31] <guii> ah, wait
[21:06:39] <guii> i think you didn't get the news:
[21:06:55] <guii> the server PSU / motherboard / CPU died
You need to add this feed too to have libremap-agent
src-git libremap https://github.com/libremap/libremap-agent-openwrt.git
On Thursday 03 April 2014 13:14:33 you wrote:
> ilario@ilario-fisso:~/software/lime-build-bis/build/trunk$ ./scripts/feeds
> install -a Installing all packages from feed packages.
> Installing all packages from feed lime_packages.
> Installing package 'lime-map-agent'
> WARNING: No feed for package 'libremap-agent' found, maybe it's already part
> of the standard packages? WARNING: No feed for package
> 'luci-lib-libremap-location' found, maybe it's already part of the standard
> packages? WARNING: No feed for package 'luci-lib-libremap-system' found,
> maybe it's already part of the standard packages? Installing all packages
> from feed luci.
> Installing all packages from feed routing.
