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!
On one node we are announcing a tunIn for internet and anotherone that have a
corresponding tunOut is tring to reach internet, but there is some problem,
packets never reach the other nodes and sniffing on interfaces never goes out
from the originating node, and on dmesg i have found some of this messages
[ 8829.860000] ip6_tunnel: bmxOut_9f4872: Path to destination invalid or
inactive!
That seems related ecause appears only on the node that is trying to go out,
is it a well known problem or it is necessary a deeper debug ?
Hi, people from Linksys answered me.
As I sent a very informal mail they are interested to know more about (one of) our organization(s). I think they are interested concretely in which way we technically improve by software routers. I think is much better that someone of you that are working or was working in drivers code, dynamic routing daemons code or abstraction layers code (I think before Libre-mesh) send mail to them. Or write your experience and we can send it with a formal e-mail (maybe @libre-mesh.org or @qmp.cat or @bmx6.net or whatever).
Here more or less quick idea of that: http://pad.marsupi.org/WRT1900ac
Finally we can send e-mail to "Karen sohl" <Karen.sohl at belkin.com>
----- Mensaje original -----
> De: "al" <al(a)blogmail.cc>
> Para: "libre-mesh developement" <dev(a)lists.libre-mesh.org>
> Enviados: Martes, 18 de Febrero 2014 15:07:32
> Asunto: Re: [lime-dev] Fwd: Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
>
> One month and no answer.
>
> I sent it again. But... maybe best forget it for now.
>
> I think Compex WPJ344 has more support:
> http://wiki.openwrt.org/toh/compex/wpj344
> https://wikidevi.com/wiki/Compex_WPJ344_%28WPJ344LV%29
>
> ----- Mensaje original -----
> > Enviados: Viernes, 17 de Enero 2014 13:06:36
> > Asunto: Re: [lime-dev] Fwd: Re: [OpenWrt-Devel] is anybody working
> > on supporting Linksys WRT1900ac ?
> >
> > On Thursday 16 January 2014 00:42:00 al wrote:
> > > I sent an email to contact in post.
> >
> > Great!
> >
>
The past week I was in Garraf at La Responsable together with Al to work on
libre-mesh, here I'll do a little report of the work done:
First of all my attention was dedicated to complete stabilize and merge into
develop, wireless mode modularization (branch features/modes-modularization),
wireless modes supported were implemented directly in wireless core file and
didn't support adding of new wireless level configuration modules, so if
someone would for example implement support for 802.11s ¹ in libre-mesh had to
edit core wireless configuration files, while now he can just implement a mode
module, writing very little number of line of code and without the risc of
breaking the libre-mesh core.
Then guided by testing and features requests emerged talking with Al about
emerging communities needs, we decided moving on the following:
First I had to change some default values that was giving trouble for example
the channel 60 is DFS then radios had some difficult waking up we moved to
channel 48 as default that doesn't give such troubles.
Then because we had some cheap device around we tried to flash them with libre-
mesh but the image was too big, so andother pass of modularization was needed,
this time I have splitted protocols support in defferents packages, so for
example cheap battery nodes can ship just batman-adv or just bmx6 according to
user needs, also debug tools were removed form lime-system depends and
splitted to lime-debug tools, so we can install them just when needed and when
them fits.
This new rounds of modularizations evidenced some bad abits in the code like
using a global uci cursor and stuff like that, all things that were fixed before
merge in develop ( more detalis on features/onadiet branch )
The new possibility of having a hybrid mesh of nodes having L2+L3 or L2 only
support suggested the needs of having bmx6 take advantage also of L2 only
piece of mesh so in the branch features/bmx6_over_batman the autoconfiguration
module doing this was implemented and then merged into develop
The rest of time was used to debug why bmx6 wasn't working as expected that
resulted in the discovery that older bmx6 version are working as expected
while newer manifest a bug already reported on this mailing list, plus enjoing
life :)
While waiting fore the dealyed aircraft i was thinking to some odd output of
ps command missing dnsmasq then now i have tested and DHCPv4 is not working
thanks to libre-mesh new modular nature debug of this part will be easier and
hopefully done in following days!
Thanks to La Responsable for ospitality and fun time together!!
[¹] http://en.wikipedia.org/wiki/IEEE_802.11s
---------- Forwarded Message ----------
Subject: Re: [Freifunk-Mentors] GSoC 2014 - Wanna do it?
Date: Saturday 15 February 2014, 17:48:21
From: Mitar <mmitar(a)gmail.com>
To: freifunk-mentors(a)googlegroups.com
Hi!
I added table to each of our ideas. Others, please do the same for your ideas.
Mitar
On Sat, Feb 15, 2014 at 5:17 PM, Mitar <mmitar(a)gmail.com> wrote:
> Hi!
>
> So I think that TODO does not server anybody, but it just makes our
> list of ideas looking less serious.
>
>
> Mitar
>
> On Sat, Feb 15, 2014 at 5:14 PM, Mitar <mmitar(a)gmail.com> wrote:
>> Hi!
>>
>> No, there is no way somebody could take shine away from nodewatcher. ;-)
>>
>> But last time they were checking ideas immediately after the deadline.
>> So I do not see the reason to have TODO in there. They can always add
>> it later, the whole section.
>>
>>
>> Mitar
>>
>> On Sat, Feb 15, 2014 at 4:59 PM, Gioacchino Mazzurco
>> <gmazzurco89(a)gmail.com> wrote:
>>> On Saturday 15 February 2014 16:37:34 Mitar wrote:
>>>> LibreMap is TODO. Can this be filled in or removed?
>>>
>>> Hopefully LibreMap guys will fill it soon, anyway don't think it's a
problem if
>>> it stay as TODO some day more, anyway i'll forward your email to remember
to
>>> the about the idea on the wiki ;)
>>>
>>> [ JOKE ] Mitar do you worry LibreMap taking some shine instead of
Nodewatcher
>>> ? :p [ / JOKE ]
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
"Freifunk Free Community Networks Mentors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
email to freifunk-mentors+unsubscribe(a)googlegroups.com.
>>> Visit this group at http://groups.google.com/group/freifunk-mentors.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>
>
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
--
http://mitar.tnode.com/https://twitter.com/mitar_m
--
You received this message because you are subscribed to the Google Groups
"Freifunk Free Community Networks Mentors" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to freifunk-mentors+unsubscribe(a)googlegroups.com.
Visit this group at http://groups.google.com/group/freifunk-mentors.
For more options, visit https://groups.google.com/groups/opt_out.
-----------------------------------------
Hi!
After some tests here in Garraf we discovered that reghack is not properly
working anymore... we are unable to use channel 14 in 2.4 band and we got a
lot of trouble wen trying to use DFS channels on 5 band...
If there is no rapid solution i belive it is the case to open a ticket ( when
the server will be up again)
Se you soon!
As we talked with Guido we are taking an article [0] as inspiration as
branching strategy, here i would comment something about it
[0] Says:
> Feature branches typically exist in developer repos only, not in origin.
I think this is not a good idea in our situation, we are a bunch of developer
around the world and some time we don't know well on what the other are
working, keeping those branch in origin and WELL UPDATED would help in
understanding what is happening, to avoid work duplication and consequent hard
to impossible to resolve merge conflict.
[0] Says:
> Finished features may be merged into the develop branch definitely add them
> to the upcoming release:
...
> $ git merge --no-ff myfeature
...
> $ git branch -d myfeature
> Deleted branch myfeature (was 05e9557).
> $ git push origin develop
>
> The --no-ff flag causes the merge to always create a new commit object, even
> if the merge could be performed with a fast-forward. This avoids losing
> information about the historical existence of a feature branch and groups
> together all commits that together added the feature.
I think it is better do not delete the feature branch by default, and
eventually delete just if necessary, so to keep better tracking of edit
history and isolate easily eventual regressions, and i think the same about
release and htofix branches, so generally i wouldn't delete branch if not
necessary
[0] http://nvie.com/posts/a-successful-git-branching-model/
