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 all,
I know some of you are skeptic about presenting projects to CONFINE, but
I believe, from what I've been able to talk to different people involved
that we have a chance with libre-mesh.
I have already agreed with the head of the Networking department at the
Universidad Nacional de Córdoba (a reowned University in Argentina) to
present the proposal from their institution. I've also checked that
Argentina is one of the eligible countries, according to:
http://cordis.europa.eu/fp7/ict/programme/home_en.html
I've also confirmed that the closing date will (most likely) be extended.
So... I've started writing a proposal in this pad:
http://etherpad.guifi.net/libremesh-proposal
(only the abstract is written so far, the rest is just the template)
I'm working on this with Daniel Britos, from the UNC, but I've been
thinking that others on the list might have some time to help, specially
Isaac :)
I want to have a good head-start during the next few days and I plan to
finish it during the first days of our return to Argentina (although I
need to confirm the CONFINE closing date).
Ok... so that's the plan, anyone who wants to help is welcome.
Cheers,
Nico
Hi!
I have participied with ninux to google summer of code for two years as
mentor, this year i have the feeling ( not confirmed ) that ninux is not
mooving on for GSoC for some internal iussue.
With GSoC we can take ~5k$ for each students ( for example me and p4u )
participating and 500$ for each mentor participating ( for example nico end
gui ), the only draw back is that we need to prepare some burocratic stuff
What do you think, is guifi participating this year?
I think 10k$ would be a good sprint for libremesh project ( without google
noticing we can handle that money as we prefere... )
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quick example of how the BMX6 sms plugin can be used to implement a
very small distributed DNS system.
http://bmx6.net/projects/bmx6/wiki/Mdns
Maybe we could reuse it for libre-mesh in some moment.
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)
iQEcBAEBAgAGBQJSaQboAAoJEAX7rWpc+YnNYIYH/2LrjOWnVsGxIjUR5mG2ccON
vH3qcRUsMEdFVR1uryIyU8zWDZRapuYtFPxyLsBBht3xxXTXxBEIvLU4Hn1DuHF2
PWEotwvUFDyA+r5AO56WF3a2E6OLspovuSIlXVUc8m06jcpsUTPtU3Lkkmycs75B
BgMWyeY4CMt+xDmCA8j7Zc7UyhZY5tqGbDFDq0TL6lb9q2JaYHkwXsXohdE8ndRO
T2TQ5G0dLSKb+KvAhapZh81gDBXecGDDbo6YKZ4QnPcT2KM/FUYChqP74gRwJAQE
f+LrJc4RXWEh37t2obr+c/oFM0UkGOKGXHCV56kq+1aYlldPS+FU8rDta6Xv9lw=
=OkFJ
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Find here a scientific paper about a qMp network deployed here in
Barcelona. The title is: Experimental Evaluation of Wireless Mesh
Networks: A Case Study and Comparison
http://edss.isima.fr/workshop/wp-content/uploads/paper_22.pdf
PS: sorry for crossposting
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)
iQEcBAEBAgAGBQJSaB0CAAoJEAX7rWpc+YnNcoIH/jyF81DpEoDAHkpY5wbuI+nG
oha9DcQHUEFdVHZMe10b42qaWArMuAiRHcfJGumHKJitFfM5Tn0NjLPdXxJrwt3/
V32JQXHbPnvfjHwnmKbuXO9wGtVFBvBwbBTyHirdQiiNBw3+h9xxBkQSUatdubzN
HcM6pes139LdFT2bIyuiAcqKvNz6ggPhqo3vMDo/XvU9hpFJALbT4PT8M/NXcYXJ
0aQYd4dMqvUYr0SdaltCMikR+aUVhXVxbPNBFfyE9FxNtqrN7SffG8nqySQwe0cp
vkMdhNQcuDo15LGBfREv+4BteOPv1K62dYEBt3fksr8ZjjWbpKtExv9esD3pHcg=
=L+Ez
-----END PGP SIGNATURE-----
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/
Hello, this is a call for native English-speakers ;) We made a definition of project. We made it in Spanish and then we translated it to English, so the concept is good but maybe the expressions used on it are not much. So maybe you Isaac (or other native English-speakers) can take a look.
http://www.libre-mesh.org/
Spanish original is here:
http://es.wiki.guifi.net/wiki/Libre-mesh
Thanks.
-----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-----
just to note down what we talked yesterday:
1) on the wiki,
http://bmx6.net/projects/bmx6/wiki/Wiki#Blocked-Nodes
there's no mention at all that the module "ip6_tunnel" is needed,
probably useful to note on compile/install section?
2) there's also no documentation whatsoever about globalPrefix
only thing i could find is on the help:
--globalPrefix <NETWORK>/<PREFIX-LENGTH>
specify global prefix for interfaces
but from what i tried, if a globalPrefix is set for an interface (or
globally) and the interface doesn't have any ip on that prefix, then it
does not get an autoconfigured fd66:66:66 either, and the interface
stays disabled.
I don't know if that's on purpose, i expected that if the interface had
no address in that prefix, it would get activated anyway with the usual
fd66:66:66.
in any case maybe doc should be more verbose about how it works?
finally,
3) you asked for some links about tunnels:
tinc-vpn is the mesh vpn, that works perfectly and is a great idea, but
being userspace it kills cpu with high traffic
http://tinc-vpn.org/
tunneldigger was made by slovenian people, is a simple userspace daemon
that sets up L2TP tunnels (kernelspace) to a set of tunnel "servers"
https://wlan-si.net/en/blog/2012/10/29/tunneldigger-the-new-vpn-solution/
high traffic is not an issue, but it works in a hub-and-spoke model,
there's no mesh concept whatsoever
cheers!
gui
