Most of the discussion regarding this issue has been done on this pull
request:
https://github.com/libremesh/lime-packages/pull/71
I copy the last Daniel's statement from the lime-dev thread with subject
"[lime-dev] downloads.libremesh.org being unavailable" to keep
discussion from this point.
> Do we have a consensus with regarding minPrefixLen, maxPrefixLen and
> using whether watchping should add/remove a route to 2000::/3 or ::/0?
> To me it looked like we concluded to make the naming consistent with
> the rest of lime ('publicv6') and use 2000::/3.
Yes, if there are not voices against it my vote is to use 2000::/3
instead of ::/0 for the Internet announcement.
But as commented on the pull-request limr-proto-bmx6 and lime-proto-bmx7
must be modified according this change ([1]).
Also this must be implemented to avoid problems with RFC6877:
>so we should probably have several watchping sections testing for
>them. Ie. pinging a well-known IPv6-mapped IPv4 address and setting up
>explicit tunIn for them.
> But the prefix length
> was still an ongoing debate and I'm also less flexible there, simply
> because I cannot test things with maxPrefixLen >= 64 because all
> ARPAnet gateways I have access to only got a single /64 and hence
> should not delegate anything shorter than a /72 (ie. max 255 clouds
> using that gateway). Thus it's impossible for me to actually test any
> setup which involves shorter prefixes.
In any case we need a DHCPv6 server which allows the delegation of
prefixes smaller than /64. Current dnsmasq does not but we might patch
it. Using odhcpd means that we have to implement also the
dnsmasq-share-leases stuff into it. @Gui is our dnsmasq guy, let's see
what we says.
> Also note that the counterpart, the needed changes on the client-side
> to make bmx6/7 automatically choose the right prefix and address is
> still missing afaik and I don't have time to implement that right now.
We might try to involve @axn to this.
> Anyway. Let me know what to do, I'll do it, so we can move on :)
Great.
[1]
https://github.com/libremesh/lime-packages/blob/develop/packages/lime-proto…
--
./p4u
Thanks for the feedback.
On 21.03.2017 03:00, Gui Iribarren wrote:
> Hey Axel,
> we're having a flood of these messages in logread,
> around 10 per minute, which is quite annoying
>
> Tue Mar 21 01:55:52 2017 daemon.err bmx6[5530]: INFO
> create_ogm_aggregation(): IID jump 2 from 432 to 539
Ack, that is annoying. But not harmful. Its probably because you have
many nodes changing their description frequently.
How many nodes does your network have more or less?
And does it appear only as "IID jump 2..." or also as "IID jump 3 and
more...?
>
> they are being logged regardless of dbgMuteTimeout=10000
> or dbgMuteTimeout=1 or whatever setting
>
> how exactly does --dbgMuteTimeout work?
It mutes messages that are logged with dbgf_mute() function after having
appeared twice for the amount of ms you specified with --dbgMuteTimeout.
The log message you complain about was not logged with the dbgf_mute()
function and was therefore always logged.
>
> and how can we prevent those messages from showing up in the logs?
You could only change the code, or update to the latest bmx6
master-branch version. It contains below patch :-)
https://github.com/axn/bmx6/commit/4016a1980d900309771e432d1f7c741d6c48d477
cheers too
/axel
>
> cheers!!
>
I have been thinking about the unexpected behavior made evident by
modifications in the branch reproducible_config
Look at line 5 of this paste for an example of misbehavior
http://pastebin.com/deGbPvmB
I have been investigating for what can be causing it and discovered we are
accessing configurations that are not declared in our default file, so I have
added a couple of them that were obviously missing and added some code to
avoid insurgence of this again in the future
So please test 568ffd9b80a8aec053ae3ff16c6f5ff1647d17bd and feedback ;)
Cheers!
This commit enable bmx6 sms plugin by default do we need to depend on some
package to have it in our images, or bmx6 does ship all plugins by default?
Cheers!
From long time ago LibreMesh supports 802.11s as link layer protocol for
the WiFi/mesh connections (with deactivated HWMP, the routing layer).
Traditionally we have been using Ad-Hoc (IBSS) for linking the nodes but
it is old and broken on most of the current WiFi drivers.
802.11s has some advantages like:
* easy setup (just mode=mesh)
* several 802.11s virtual devices supported in a single WiFi interface
* supports encryption
* it has power saving support, so better for mobile devices
* better and more driver support
So as already discussed on some other mailing thread, I propose to use
it by default instead of IBSS on the next LibreMesh release.
Of course it will break the compatibility with older releases. But IMHO
it is better now than in the future, in any case we will probably have
to do it soon or later. In addition anyone who want can use IBSS
instead, can use Chef or lime-build to generate an image firmware. It is
as easy as adding "list proto adhoc" into /etc/config/lime-defaults.
Please, speak up. Silent will be considered acceptance :)
Cheers.
--
./p4u
---------- Forwarded message ----------
From: Andreas Bräu <ab(a)andi95.de>
Date: 2017-03-06 16:49 GMT+01:00
Subject: [Battlemesh] GSoC Mentors Mailinglist
To: battlemesh(a)ml.ninux.org
Hi there,
I recently published a blog post for GSoC 2017 at
https://blog.freifunk.net/2017/03/05/gsoc-2017-and-freifunk-students-wanted/
Hopefully this answers some questions to interested students, feel free
to share :)
Our next step is to invite you as possible mentors to the GSoC Dashboard
and to our mentors mailing list.
Can you please send me your email address you wish to be registered there?
After having you on the mailing list it will be easier to distribute
information, instead of writing to a bunch of different mailing lists :)
We also need it to discuss proposals later on.
The org admins you can contact via gsoc-org-admins(a)freifunk.net
Best regards,
Andi
_______________________________________________
Battlemesh mailing list
Battlemesh(a)ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh
Hi!
Good to see that lime is still alive after all.
I thought about some things which need to be taken care of and would
like to get some feedback and opinions:
* wouldn't it be great to finally use LEDE's SDK + ImageBuilder
instead of lime-build (which is hard to maintain)?
LEDE does rolling-release for packages and promissed regular
maintainace cycle for their releases. 17.01 just came out, 17.01.0
is already in the pipe, 17.01.1 will come in May/June, and so on.
suggestion: drop lime-build in favour of using the lime-packages
feed with the SDK to provide packages to be used with the
ImageBuilder.
If there is any real reason to fork LEDE and/or use custom builds,
please speak up, I'll be your advocate on board of the LEDE team
to resolve those issues.
* lime-config currently re-writes UCI configuration. ie. if I mess
up /etc/config/network, running lime-config will not necessarily
fix it. There are also situations which make re-running lime-config
impossible as that would break the config completely. To resolve
that mess I suggest to refrain from re-writing UCI configuration and
rather generate it from scratch every time by using the new
/bin/config_generate script.
If anything is missing in that new board-config aka. uci-defaults
approach, then we should add it and discuss with upstream, ie. make
sure that all board-specific details needed to generate the entire
configuration are covered.
Hence I'd like to re-write lime-config from scratch. And maybe use
Shell instead of Lua. I know, this may sound terrible, but I'm sure
it'd be a great step towards reusability of the code for other
projects (which may not use all the rest of LiMe, maybe not even
use Lua at all) and also make the lime firmware more robust and
cover more use-cases (such as re-configuring images on the go
rather than using CHEF or imagine changing things in the field
using some remote mass-management tools, I'm thinking of OpenWISP)
* speaking about CHEF: what's happening on that scene? I find CHEF
very complicated, but I'm not a web guy :( I saw it finally found
someone willing to maintain it. Is there a roadmap or something?
And how can people contribute documentation, localization and all
that? And will it move to github?
* hardware support: I think we should support more hardware targets,
not just ar71xx, x86 and mt7621 (I do appreciate that mt7621 made
it to the current release!). I'm working a lot on MT7620 lately,
there are a terrible lot of devices out there and though this
chip (or driver...) does not allow combining Ad-Hoc + AP, it
apparently does allow combining 802.11s + AP!
suggested additional hardware platforms, in random order, high-
priotity is marked with an '!': !mvebu, !ramips/rt305x,
ramips/rt3883, !ramips/mt7620, !ramips/mt7628, !ramips/mt7688,
!ipq806x, !lantiq/xrx200, !lantiq/xway, octeon, !x86/generic,
x86/geode, !x86/64, arm64, armvirt, sunxi, mediatek,
brcm2708/bcm2708, brcm2708/bcm2709, brcm2708/bcm2710
(ie. all up-to-date platforms with good support in LEDE)
I don't know enough about the bcm53xx, brcm47xx and brcm63xx
targets to tell if any of those could be useful, but most likely
they can, especially those with brcmsmac or brcmfmac wifi.
For all others, especially those marked to be high-priority in
the list above, I'm more than willing to help and contribute
whatever is needed to get going.
* speaking about 802.11s: should we switch to use the 802.11s MAC
by default? Ad-Hoc/IBSS has many known problems and nobody among
the people hacking the drivers seems to really care about it as
it's broken by design...
Cheers
Daniel
Hi!
All download and snapshot build sites are down:
chef.altermundi.net doesn't offer downloads without registering first
builds.libremesh.org and downloads.libremesh.org both point to some
parking site rather than allowing to download anything.
lime-build fails due to chaoscalmer not building due to unavailable
openwrt.org resources.
It's kinda hard to promote the use of libremesh in this situation.
How can we improve this situation?
Cheers
Daniel
Hi from Barcelona Hacklab.
In order to mount new nodes with Libremesh in places where exist
networks with qMp and Libremesh we tested with two Nanostation M5 with
same revision of BMX6:
BMX6-0.1-alpha comPatibility=16
revision=2a87b770d3f9c254e3927dc159e2f425f2e0e83a
this is the default BMX6 in each stable release (Libremesh stable and
qMp Clereance 3.2.1)
For replicate the issue:
Working on same test channel (48) with same VLAN (default qMp 12) we got
good link and we can see BMX6 routes from each other, but we can't ping
each other.
Any ideas?
Thanks!
