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
The resume is he have no time to do it now, but if we send to him patches for
netifd he will merge them.
He suggest start working on latest netifd used by openwrt trunk
<G10h4ck> Hi!
<nbd> hi
<G10h4ck> I am gioacchino from libre-mesh
<G10h4ck> before anything
<G10h4ck> many thanks for implementing mac-vlan in uci
<G10h4ck> now we need something very similar for 802.1ad vlan
<G10h4ck> this would help us and more people affected by tplink shitty bridges
<G10h4ck> because we have tested and 802.1ad vlan packets are not dropped by
the switch, while it drop 802.1q
<G10h4ck> in this page also it is reported something
http://wiki.openwrt.org/doc/networking/network.interfaces
<nbd> right, this would need to be implemented in netifd
<nbd> the code has to be changed to use netlink instead of ioctl to configure
vlan devices
<G10h4ck> i imagining something very similar to what you done with mac-vlan,
am i wrong ?
<nbd> it's a bit similar
<nbd> but involves more rework of the existing code
<G10h4ck> are you planning to do this soon ?
<nbd> i don't have time to work on this at the moment
<G10h4ck> ok
<G10h4ck> how is going work with ath9k ?
<G10h4ck> i remember at last WCW you talked to me about a feature that would
increase speed, and cannot be easly implemented by proprietary driver because
they work a lot at firware level
<G10h4ck> while a good amount of memory was needed to implement that ( i
remember the precondition but not the feature :P )
<nbd> it's mostly a latency improvement
<nbd> still working on it, but much of the infrastructure for it is done
<G10h4ck> many thanks :D
<nbd> you're welcome
<G10h4ck> nbd if we do a patch for netifd, there is to have the patch
integrated soon ?
<G10h4ck> because some time some patch need eons to be integrated :P
<G10h4ck> and from what branch do you suggest to start working on this ?
<nbd> if you send a patch against netifd, i will review it and merge it when
it's okay
<G10h4ck> ok
<nbd> you should work on it with the latest git version of netifd
<nbd> used in openwrt trunk
<nbd> brb
<G10h4ck> thanks, see you soon!
Hey Axel,
here i am, haunting your dreams again with tricky questions... ;)
[i'm trying to get all interfaces of a node have public ipv6 addresses,
instead of the fd66:66:66:: autogenerated ones.
but ipAutoPrefix is not flexible enough, and assigning addresses
manually (outside of bmx6) and then using bmx6 globalPrefix would be a
hassle. the ideal would be to leverage bmx6 ipAutoPrefix feature, but
with a smaller prefix (/64)]
ipAutoPrefix currently needs to be a /56, so that two bytes can be set
to the interface index, and form a /64.
Why does each interface *need* to have a /64?
could it be simply a /128? (or something smaller than a /64, at least)
(outside of ULA space, it's relatively uncommon to have a /56 available
for each node; a /60 would be more realistic, and /64 would be ideal)
currently scheme AFAIU:
XXXX:XXXX:XXXX:00II:MMMM:MMff:feMM:MMMM/64
Xs = ipAutoPrefix nibbles
II = interface index
Ms = mac nibbles
maybe this could work the same:
XXXX:XXXX:XXXX:XXXX:00II:MMMM:MMMM:MMMM/80
this way, ipAutoPrefix can be a /64,
interface id is still there
and while the EUI-64 format is dropped, i don't think that's a problem?
i understand each interface should have it's own distinct network, as it
is now. so, to maintain that, the size is a /80 (yay!)
but maybe it could turn directly into a /128, like i asked before?
again, i'm not sure how these addresses are used / why they are needed,
so feel free to say simply "no, that wouldn't work at all" or "that'd
break backwards compatibility"
have a nice weekend, as always!
gui
----- Mensaje original -----
> De: "Asier Garaialde - GipuzkoaShare" <agaraialde(a)gipuzkoashare.net>
> Para: guifi-euskalherria(a)llistes.guifi.net
> Enviados: Martes, 5 de Noviembre 2013 10:15:17
> Asunto: Re: [guifi-euskalherria] [guifi-users] Próximas actividades
> de Guifi.net
> Kaixo Al,
> Me gustó mucho la charla que disteis sobre LibreMesh
Muchas gracias, les he traspasado tu feedback a los charlistas :)
> y quiero empezar
> a hacer unas pruebas. El firm de LibreMesh esta ya suficientemente
> 'maduro' como para hacer pruebas en semi-producción o todavía está
> para utilizar únicamente en entornos de testeo? Me lanzo a probar
> con LibreMesh o todavia es conveniente usar qMp?
> Pues eso...
> Me hubiese gustado quedarme para charlar con vostros mas
> tranquilamente pero por rollos del curro, el sabado por la tarde
> tuve que salir escopeteado...
> Aio!
Óbviamente el firm de Libre-mesh no está suficientemente maduro, pero las otras redes en las que ha venido trabajando el equipo de Libre-mesh sí que tiene el conocimiento necesario para ayudaros en crear una red en producción para una comunidad. Dinos qué necesitas (número de nodos, qué zona, si es entorno rural/ciudad, qué recursos teneis,...) y te podemos ayudar a buscar la mejor solución. Lo que salga de ahí en un futuro tendrá la posibilidad de hacer un upgrade a la primera versión recomendada para uso autónomo de Libre-mesh.
Hello. After libre-mesh speech in Hackmeeting 2013 - Sestao, a local person from Euskal Herria send to Libre-mesh crew congratulations and ask about to start to use it in his zone (see below).
I'm gonna answer asking about if is rural area or city (for interferences in 2,4GHz, but I think he lives in rural area) and explain him possibility to have roaming. I think we can help him with a pre-tested binary for his zone, explain that we are in pre-beta release, but qMp project and Altermesh project are in production in several communities.
He has tech knowledge.
----- Mensaje reenviado -----
De: "Asier Garaialde - GipuzkoaShare" <agaraialde(a)gipuzkoashare.net>
Para: guifi-euskalherria(a)llistes.guifi.net
Enviados: Martes, 5 de Noviembre 2013 10:15:17
Asunto: Re: [guifi-euskalherria] [guifi-users] Próximas actividades de Guifi.net
Kaixo Al,
Me gustó mucho la charla que disteis sobre LibreMesh y quiero empezar a hacer unas pruebas. El firm de LibreMesh esta ya suficientemente 'maduro' como para hacer pruebas en semi-producción o todavía está para utilizar únicamente en entornos de testeo? Me lanzo a probar con LibreMesh o todavia es conveniente usar qMp?
Pues eso...
Me hubiese gustado quedarme para charlar con vostros mas tranquilamente pero por rollos del curro, el sabado por la tarde tuve que salir escopeteado...
Aio!
