Hi Pau, Hi Gui, On Thu, May 26, 2016 at 12:44:36PM +0200, Pau wrote: By now I managed to get most things working on LEDE trunk, apart from some minor LuCI changes and a bug in batctl it works fine... It'd be really nice to have a good pointer I can hand over to a spanish-speaking person and ask for english or german translations. Without localization I can't really expect that people manage to create accounts and generate images... I found that and tryied using that image, however: I seems to be impossible to get lime-full including bmx7 to fit on a device with 4 megs of flash. My first thought was to do what I always to in such situations: strip the web-interface and get rid of Lua on the device to free space for whatever is needed. The alternative seems to be to have a minimal firmware without bmx7 but with batman-adv and the web-interface. How did you decide to go about flash-size constraint devices? Do device with as little as 4 megs even matter to you? That's a problem for *all* OpenWrt-based firmware projects. That's why with the new image building system introduced to OpenWrt lately it will be much easier to have a machine-generated list of supported targets/boards and auto-populated table-of-hardware. The idea in the LEDE group is to have a traffic-light-style status for each device: green: confirmed to work by a volunteer submitting data via a test-script on the device. yellow: compiles, but untested red: doesn't compile/image missing Once that data is available in machine-readable form, it should be much easier for people to figure out which image to use on their box... Even when doing the QA for each board, I still don't understand why renaming the image files (esp. the board-identifying part) is needed for that. I can see that, freezing sources is a necessity given you want to build something stable. I also agree that the OpenWrt release cycle as it happened until now wasn't exactly helpful, mostly due to the lack of maintainance releases... The truth is that many here hope to live without too many local customizations as they tend to be hard to maintain and fall apart after a while. Large subgraphs on our map are collective projects with some collective decission-making involved. So they can (and want to) maintain their own networks and are currently unable to do so (and thus depend on very few 'angels' from outside to do most of the work) because the process of flashing, configuring and debugging the firmware is/was quite ugly. Actually, it turns out most projects don't care at all about keeping all that legacy of customizations (even in terms of protocols and addressing) if they can just trade it for something which works and allows them to administer their network without depending on the will and resource of very few firmware geeks. I aiming for a single stateless firmware image to run on all devices of the same type. No configuration apart from map-agent-foo should be needed. There should be a local web-interface (eg. using anygw) allowing almost untrained individuals to at least figure out who to ask for help. LiMe does that job pretty well and it'd be great to deploy it here, if possible with the stock-built provided on the libre-mesh.org website and without any further custumization per default -- on a few nodes additional packages e.g. for legacy routing protocols used in other close-by communities can be added manually, but that's really something not needed every day. However, I'd rather want a .ipk package containing the profile for existing networks/communities instead of having power-users touch a compiler at all (or use 'chef'). I personally would be glad to drop OLSRv1 once and for good, switch to libremap and use BMX7 for the backbone. So why not just use libremesh in it's stock configuration to make things as easy as possible? To still communicate at least on batman-adv level, the needed customizations would be: * use 8021q vlan-type * use vid=12 for batman-adv (or vid=61 in some other places where people moved to gluon, for some reason I didn't ever understand the meshes are seperated on Ad-Hoc-VLANs, probably because gluon lacks gateway-mode -- but it could still be VLANs on-top of batman-adv, which probably just wasn't considered (?)). * use country=DE (I will not encourage people to used a patched regdb) * use channel 1, 6, 13, 40 or 44, with HT40 enabled, for Ad-Hoc, depending on the environment and available bands * use the appropriate BSSID for the channel selected * use batman-adv-autogw to set gw-mode appropriately That same would be true if instead of *building* OpenWrt from source, the ImageBuilder and SDK are downloaded and used to build only the LibreMesh-specific packages and then generate images. Even providing ImageBuilder and SDK at the source-freeze level you decided (instead of the 'official' OpenWrt release) would be a great improvement imho and allow for much shorter build cycles and thus more rapid development/testing. The advantage is also that instead of having still quite a lot of potential breakage entering from the specific build-host into parts of OpenWrt *you don't even care about, but still use* is mitigated by using a pre-compiled SDK/IB. It would also allow to collect debugging symbols and thus make reporting bugs back to OpenWrt or upstream projects much easier (eg. with a stackdump or symbols after a kernel-oops). make T=... V=99 It'd be great to have pre-baked images with a working on devices with 4 megs of flash. It'd be ok to have them speak only batman-adv and run bmx7 only on devices with larger flash (backbone). I tried the image http://downloads.libre-mesh.org/firmware/ar71xx/openwrt-ar71xx-generic-tl-w… and realized it lacks quite some things (or maybe I didn't get it) I didn't manage to use chef (tried via chrome's google translate). Compiling from source resulted in an image without bmx7 and also batman-adv-auto-gw-mode missing -- ie. not very useful, as anygw is distributing addresses even if there are batman-adv gateways around. I hope to fix that and then make the resulting minimal batman-adv-only images for devices with 4 megs available for people interested in that, while *not* touching anything else, ie. drop compatibility with our legacy OLSRv1 mesh (for those very tiny devies) and start with bmx7 backbone-nodes and/or some individual gateways supporting OLSRv1 manually. I'm also totally for a single unified BSSID and VLAN-scheme and would like to adopt the conventions libremesh started. Ideally I'd even automatize channel selection... (or have one image for all device in a certain environment which already contains those changes) Cheers Daniel