[Battlemesh] Open Tasks

[Daniel Golle]

Hi everyone!


On Fri, Feb 20, 2015 at 03:40:28PM +0100, Simon Wunderlich wrote:
>  * Firmware preparation - We can probably use the WBMv7 firmware, but this 
> would need to be checked and prepared as well - are all the nice new features 
> of all the protocols in? Any bugs squashed? Should it be tested BEFORE the 
> event?

I'm happy to help on the OpenWrt side of things. (And also in the
kitchen -- community generated food would be a great improvement :)


Some random thoughts which came up since last year:

 * What about building a base-firmware connecting to the mangement
   mesh, download test-images and use kexec to run them?
   In that way, enhancements and changes to in-kernel stuff (wifi
   drivers, in-kernel routing stuff like batman-adv and 11s, ...) could
   more easily be tested and also recover from failures painlessly, as
   it also makes it easy to test potentially dangerous stuff, as even
   if the system oops'es, after a reboot, things will be good again, as
   the in-flash system doesn't need to be changed.
   There has been work going into kexec recently and it kinda works
   on ar71xx-based systems (and other MIPS-based targets should not
   be too hard to add after OpenWrt r44429).
   If there is interest, I can test things on various ar71xx-based
   boards. I believe this to be sufficient as most testing hardware
   accumulated over the years is ar71xx-based anyway. All needed is to
   extract the board=... parameter from /proc/cmdline and reuse it for
   the to-be loaded kexec kernel+initramfs -- and hope that all drivers
   are fine with the state of things they'll find, which might be
   different from the bootloader-initialzed-state after a hard or soft
   reboot... The extra-ram needed for the initramfs (instead of flashed
   squashfs) shouldn't be a show-stopper, from what I can tell by now.

 * Can we use a more portable routing protocol for the management
   network?
   batman-adv just happends to be the only protocol built-into
   the kernel and having several incompatible versions flying around.
   That doesn't make it the ideal choice, as one can only run one
   version of the kernel module at once, practically limiting testing
   to the version also used for the management environment.
   It also makes it harder to have non-embedded targets join the mgmt
   net than in case of protocols running in userspace.
   Also in case kexec seems too far out, this could at least allow
   to load different variants of the the batman-adv kernel module.
   I'd suggest some low-footprint layer-3 protocol, OLSRv1 would be
   a good choice imho, as most people are familiar with it and it
   doesn't have too crazy dependencies. As that depends on having
   IPv4 addressing configured, I further suggest using AHCP or even
   more simple hacks like using the last 24 bits of the MAC address
   to enumerate devices in the 10.0.0.0/8 network...
   However, I'd be happy with anything which still allows painlessly
   hacking on batman-adv without risking to break access to the mgmt
   net.

 * Besides testing different routing protocols on top of the IBSS/
   Ad-Hoc 802.11 MAC, I suggest to also consider using the 802.11s
   MAC (not necessarily including the built-in routing protocol,
   it can easily be disabled and replaced by other things).
   I currently do that to use batman-adv, OLSR and babels in different
   VLANs on to of an 802.11s VIF with mesh_ttl=1 and mesh_forwarding=0
   set. And that kinda works ;)
   P2P-GO might also be an option, but I didn't get into it yet, as
   the 802.11s MAC seems more promissing? (anyone?)
   Running 802.11s VIF simultanously with an IBSS/Ad-Hoc VIF seems
   possible at least on ath9k.


Independently of these suggestions, I'd be happy to allocate resources
to help preparing what ever is needed for the firmware.
Should we create a ToDo list and/or architecture document in the wiki?
(or does that already exist and I'm just not aware of it?)
I'm still quite new to the battlemesh community, so it'd be nice if
some of you could advise me on what you believe is desireable to be
done in terms of firmware features (or kitchen-related ;)


Cheers


Daniel