[Battlemesh] Open Tasks

Sun Feb 22 00:44:19 UTC 2015

Hey Daniel,

thanks a lot for helping out - I hope there will be some battlemesh veterans 
teaming up with you! I'll comment on a few things. :)

On Friday 20 February 2015 16:58:13 Daniel Golle wrote:
> 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 :)

I definitely agree, that would be great! we may even have professional help on 
the food organization this year, not sure if she can make it to help out at 
the event - @Musti, if possible, you may want to connect up these two :)

> 
> 
> Some random thoughts which came up since last year:
> [...]
>  * 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.

Actually I wonder if that is more of a myth. Most communities use either the 
compat version 14 (releases from mid 2011- end 2013) or compat version 15 
(since 2014), which was designed with future backwards compatibility in mind.
I also don't think we should use anything < version 15 for either management 
or test networks, so I don't really see the problem.

>    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.

Hm, really? Couldn't we just kexec or unload/reload kernel modules? As 
mentioned above, testing <v15 makes no sense anyway.

>    It also makes it harder to have non-embedded targets join the mgmt
>    net than in case of protocols running in userspace.

Non-embedded targets usually join the network just as "clients" with no 
routing protocol at all - at least that's the  idea in batman-adv. As far as I 
know, we only had routing protocols running on routers in the last years. But 
even if we want Laptops/Servers to join, I don't think its a big problem. 
Since we have compatibility layers in batman-adv, all we require are machines 
with Linux kernel > 2.6.29 ...

>    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.

I wonder if changing from batman-adv (which is already in all the test 
scripts) to OLSRv1/AHCP will be more reliable ... I didn't hear that test 
management stability/reliability was a problem last year, but this is more a 
question for the people who actually performed the test (i.e. not me).
> 
>  * 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.

That sounds like a good idea. :)

> 
> 
> 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?)

Again, my info might incomplete and/or outdated - there is a wiki page for 
Battlemeshv6:

http://battlemesh.org/BattleMeshV6/Firmware
b
There are also a few links to github repos. IMHO, it would be great to 
document for this year again, so feel free to start a wiki page on the v8 
page.

> 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 ;)
> 

Again, thanks a lot for volunteering!

Cheers,
    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20150222/258b8a92/attachment.pgp>