support freifunk gluon about chef HOT 7 CLOSED

see gluon ticket about imagebuilder
freifunk-gluon/gluon#649

from chef.

@NeoRaider interested?

from chef.

for visualisation/statistics of mesh-nodes they are using respondd. we might want to include that?
my tries, i was failing with that, but many links, see https://plan.leipzig.freifunk.net/issues/397

from chef.

Chef does not make sense for Freifunk usage at the moment. Gluon is a general framework for building OpenWrt/LEDE based mesh firmware. Freifunk is decentralised. Thus every community (e.g. City/District) builds their own custom firmware with their own patches and packages along with running their own supernode infrastructure to offer e.g. VPN services to avoid legal troubles. They build the firmware and offer it to people. Gluon is just the base for most of the community builds. E.g. Freifunk Berlin uses a completely different build system.

A step we could take that makes at least to me more sense at the moment is to merge lime-sdk with Gluon. Currently we are working on modularising meshing protocol packages for also supporting layer 3 meshing protocols like Babel and it would be manageable to integrate the lime-packages in the future.

@FreifunkUFO As I understand you, you want Gluon to adapt the style of lime-sdk as it is more conform to the OpenWrt SDK, but the problem we have with Gluon is that OpenWrt SDK is not mighty enough (as far as I know). Gluon often uses backports from another LEDE/OpenWrt version which we manage with our build scripts as patch files. We would need to maintain an own OpenWrt/LEDE fork to allow that otherwise. Gluon also needs to have a different kernel module configuration to save flash space. It thus builds it's own kernel packages for using it as an opkg repo.

Maybe I'm not informed correctly about the capabilities of OpenWrt SDK, but from my current perspective either we would need to alter the OpenWrt SDK to make Gluon able to use it or just abandon relying on the SDK and use Gluon's build environment for lime, too.

Nonetheless merging Gluon and lime-sdk seems like a worthwhile goal as we are working on the same thing in the end.

from chef.

@CodeFetch i have to correct you: freifunk and libremesh are almost the same. (zero-config community mesh networks)

this ticket is about finding a preset/config to make gluon-compatible libremesh-nodes,
f.i. to set up a libremesh-node within a gluon-network, which could have a dhcp-server onboard.
or f.i. to have gluon-nodes within a libremesh-network to expand the mesh (only by batman-adv).

p.s. yes: unfortunately gluon has no sdk, gluon-communities have several wifi-settings (different bssids and more) and mostly are forced to compile their firmware by themselves. but these are other problems..

from chef.

@FreifunkUFO Gluon is the SDK (although a minimal one). A community-independent Gluon firmware that could be built with chef will likely never happen as that is against the decentralization idea of Freifunk and in general Gluon is a framework for building mesh firmware, not a firmware by itself. Gluon communities are not forced to build their firmware on their own, but they want to build their firmware on their own. The goal of Gluon is not to create compatible firmware, but customizable. I'd really love to see a merge of Gluon and lime, but I assume it will happen the other way round: by building packages for making LibreMesh compatible Gluon firmwares.
As I already said Gluon patches OpenWrt in a way that is not possible with the OpenWrt SDK alone.
So if you want to use lime SDK, you have to patch the OpenWrt SDK first or simply use the Gluon build environment.

Gluon is currently working on Babel support which will not be compatible with batman-adv, but it will be easily possible to support BMX and adapt the LibreMesh packages afterwards.

from chef.

Please open ASU specific issues here: https://github.com/aparcar/asu/
Please open interface specific issues here: https://gitlab.com/openwrt/web/firmware-selector-openwrt-org

Chef is no longer developed.

from chef.