Hi devs,
here in LiMeCat2016q3 we're preparing a release:
16.07 or CommunityChaos.
I invite you to checkout the pad if you want to drop comments before the
end of the meeting:
https://pad.eigenlab.org/p/LiMeCat2016q3
Anyway after the meeting the discussion will continue on this list :)
Bye!
Ilario
--
Ilario Gelmetti
iochesonome(a)gmail.com
igelmetti(a)iciq.es
ilario.gelmetti(a)estudiants.urv.cat
Hi!
We are currently trying to use the Libre-Mesh.org firmware with
batman-adv enabled on wired Ethernet interfaces alongside with a VLAN
which is a member of the bridge the batX interface also resides in.
------------------------------
E |VLAN---batadv---bat0
T +--------------+ BRIDGE
H |VLAN------------eth0.xx
------------------------------
We do want such a setup to have the best of both worlds: the
performance of a plain bridge but yet benefit from batman-adv topology
information, alfred and all that. As many cheap Ethernet switches do
not support frames larger than 1500 bytes, increasing the MTU is not an
option and thus frames inside batman-adv end up fragmented which hurts
performance if encapsulating all traffic via batman-adv.
I remember there was a discussion during battlemesh about a race-
condition which can confuse BLA and thus batman-adv is still disabled
on wired Ethernet interfaces in Libre-Mesh by default.
So here I am asking you about the current state of affairs regarding
this issue.
We are discussing it on
https://github.com/libre-mesh/lime-packages/issues/56
and it would be great to hear a more detailed summary because I only
remember the rough details and also haven't been watching if anything
was fixed or improved since we all met in Porto.
Cheers
Daniel
It is ok for me
On Saturday 06 August 2016 16:59:20 Ilario Gelmetti wrote:
> -------- Forwarded Message --------
> Subject: Github notifications on dev mailing list
> Date: Thu, 28 Jul 2016 16:49:34 +0200
> From: Ilario <iochesonome(a)gmail.com>
> To: libre-mesh developement <dev(a)lists.libre-mesh.org>
> CC: Nicolás Echániz <nicoechaniz(a)altermundi.net>
>
>
>
> Hi devs!
> Recently there's a lot of interesting discussion [e.g. 50,56] going on
> on Github/libre-mesh bypassing completely this mailing list.
> I think we should mirror Github issues, comments on issues and similar
> stuff here.
> There's an easy solution [1] which doesn't require any software running
> on our side, but requires a mailing list administrator (Nico) to set up it.
> Shall we do this?
> Ciao!
> Ilario
>
> [50] https://github.com/libre-mesh/lime-packages/issues/50
> [56] https://github.com/libre-mesh/lime-packages/issues/56
> [1]
> https://github.com/w3c/webpayments/wiki/Synchronizing-Github-Issues-with-W3C
> -Mailing-Lists
2016-07-13 15:39 GMT+02:00 p4u <pau(a)dabax.net>:
> Good point is that now we have many more targets (routers) available.
> I've even tested different architectures such as x86 (which works fine)
> and RAMIPS (which does not work fine in Ad-Hoc but it does in 802.11s
> mode).
>
So, from my understanding there are architectures where trying to set both
ad-hoc and ap modes is not going to work, or it would be better to set
802.11s and ap instead (as Pau told for ramips), right?
In my opinion (ap + ad-hoc | just ap | ap + 802.11s) selection could be
made by lime-build depending of the selected target architecture.
lime-build could do this setting different lime-defaults depending on the
target (not implemented yet).
Otherwise I suspect that we should move some files [1] from lime-system to
new packages lime-mode-adhoc and lime-mode-ieee80211s (and stop using
lime-full), then specifying the wanted packages in the targets files [2].
Byyye,
Ilario
[1] at least these
https://github.com/libre-mesh/lime-packages/tree/develop/packages/lime-syst…
[2] https://github.com/libre-mesh/lime-build/tree/develop/targets
In these last two days appeared two different things called "mini" in
libre-mesh:
* ar71xx-mini target in lime-build [1] for routers with < 4MB of flash
memory (really useful!!)
* lime-mini package in lime-packages [2] which equals to the classic
lime-full without lime-debug
I think that having two different meanings for the "mini" concept is
confusing, Pau could you rename one of the two?
Like "lime-mini" => "lime-basic" or "ar71xx-mini" => "ar71xx-4mb".
Thanks,
Ilario
[1]
https://github.com/libre-mesh/lime-build/commit/d8a0a8ecd913f18fb0af920aa83…
[2]
https://github.com/libre-mesh/lime-packages/commit/36ff885ec54e3bffd9980d11…
I've been testing current lime-packages develop branch with OpenWrt
15.05 Chaos Calmer. My testbed is a 20-30 mesh network with real users
in a non easy scenario. It seems to work fine so I created a new branch
in lime-packages and also in lime-build named testing/16.07.
I will do more testing next days but would be nice to have more
feedback. So if you want to compile it yourself clone: "lime-build" and:
git checkout 16.07
make T=ar71xx J=4 P=generic
Or use new profile "ar71xx-mini" made for small 4MB devices.
Do we have some special features we want to have in the next release or
the current develop works?
PS: I took the liberty to do so to try pushing a bit this release.
Hi.
I had to cherry-pick some small commits from Develop to release 15.09 to
be able to use the lime-freifunk package in the stable release of LiMe.
I know it is not the way we agreed (once the release is done, only
bugfixes can be backported). But we really need this here in freifunk.
They are working with develop and the experience is too much random. We
need some stable firmware.
If the team does not agree, I'll do "git reset" to go back again.
Cheers, hope you understand.
Hi!
I have been reviewing the branch olsr_integration started by Pau. I have
changed a few stuff for more consistence, in particular we already had the
convention that vlanid=0 mean no vlan and createVlanInterface already take
care of this (still testing it on a real device is TODO)
moreover the way it was implemented named args worked only in specific
interface configuration while now it works also in the general network section
I also removed the extraArgs param because args is already a table
(associative array) so it already support string index (we were already doing
something similar for interface flags)
All modifications should works but are not tested on a real device as i don't
have one under my hands right now, so i haven't merged it
Still it is not clear to me how bmx and olsr can run at same time without
causing strange behaviors in general cases, but it is not a problem for me ;)
While i perfectly see the usefulnes of supporting more routing protocols also
without using vlan
Thanks for the idea of moving also protocols to named arguments and to start
coding it!
Cheers!
Micha, another freifunker who is testing libremesh at the moment is very
confused about having bmx7 packages when using bmx6 (in developer brunch).
bmx6 is used at the moment, because bmx7 was very unstable in daniels
first setup (also to much packages for 4mb routers)
while daniel was patching that adhoc, micha made some commits, and is
still on testing:
https://git.netzspielplatz.de/ffj-LiMe/lime-packages/commits/develop
whats your opinion about that problem?
ufo
--
---
Freifunk Leipzig http://leipzig.freifunk.net