[lime-dev] Temba ERA Re: FirstBootWizard Description for Hackathon in Quintana

Nicolas Pace nico at libre.ws
Mon Sep 10 12:09:56 UTC 2018

Hi Pedro,

El 10/09/18 a las 13:35, guifipedro escribió:
> I got inspired by chef.libremesh.org and more closely to work of
> yanosz that presented in previous battlemesh [1] to do a firmware
> based on (erb) templates called temba [2]. Right now serves the
> purpose to substitute qMp in Barcelona but it can be greatly adapted
> to ANY purpose.

I thought u have been using LibreMesh...
what inspired you to start a new distribution instead of using LibreMesh?
What did you tried to do that you couldn't and you ended up creating yet
another version?
maybe we can get to integrate that so we mantain a single codebase

> If you want to understand how it works it is probably better that you
> try original idea [1] (70 lines of code), and think that is even more
> flexible/complex. For example, it contains a form ror app so users can
> generate its own firmware.

Part of LibreMesh approach is for users not necessarily create firmwares
(because it is a very advanced thing to do).
chef and lime-sdk try to tackle that topic by facilitating both sdk
manipulation and building without those.

> The strong idea about this is to get an openwrt firmware ready to go
> and capable of doing mesh.

That is exactly what LibreMesh does (and more!) :)

> So if the firmware is well done, the user
> don't need to enter the antena to do any configuration. 

It is actually much more complex than that.
Different devices have different features (amount of radios, antennas,
etc), and also network config changes depending on the context (who they
need to connect to or role of the node (AP, mesh, both))

> Also, as the
> final configuration is the initial configuration, you can use the
> "first boot" and is robust to electrical discharges. In case user
> enters the antenna things got changed effectively
> That's it, I'm sharing it here if you guys find something useful for your design


> [1] https://github.com/yanosz/mesh_testbed_generator/
> [2] https://gitlab.com/guifi-exo/temba
> On Mon, Sep 10, 2018 at 1:22 PM Nicolas Pace <nico at libre.ws> wrote:
>> Hi!
>> As there is going to be a hackathon in Quintana in the upcoming weeks, I
>> was invited to share the progress of the FirstBootWizard (FBW) project.
>> https://github.com/libremesh/FirstBootWizard/
>> The question it tries to reply is:
>> * How is a new network setted up? What is the first boot experience when
>> a LibreMesh node is turned on?
>> * How do a LibreMesh node joins an existing network?
>> The approach is for nodes (routers) to share their network config with
>> their peer nodes, so they can decide on whether they want to join their
>> network.
>> There are a lot of complexities about this:
>> * hardware differences: original node had a set of radios, antennas and
>> wired interfaces, and mine has a different one,
>> * physical conditions: which radio and which antenna of that radio
>> fetched the config from my peer node?, and what if the radios were
>> configured specifically based on the context of that node? (location,
>> neighbours, etc).
>> * logical roles: one node can be an batman's alfred's coordinator, a
>> gateway with manual configurations, or even have static ip addresses or
>> centralized services running on them...
>> * customization: how do we split config between node config and network
>> config in a way that allows for customization and yet maintainability
>> These are the boundaries that we defined for the first iterations:
>> * We will design for the LibreRouter context first: as it is close to
>> getting released, and this is part of the first experience, needs to be
>> available asap, so we will narrow the focus to implement first the
>> features required for it, then generalize (in this case, triple radios
>> for example).
>> * We will priorize the cases of:
>>   1. One new node in an existing network: because that is the most
>> common case,
>>   2. First node of a network: because this is the inception moment, that
>> will also happen a lot.
>> Some other cases that were not taken into consideration but are part of
>> the process:
>>   3. different frequencies for different radios: the LR has two 5ghz,
>> and it is desired that both have different radios so there is no
>> self-inflicted noise. So, the configs will reflect that and need to
>> consider this situation.
>>   4. Border node of a network: it may happen that a node is put in to
>> communicate to networks with each other
>>   5. TVWS case: The 2.4ghz radio being used with the TVWS Frequency
>> shifter (basically, a device that turns a 2.4ghz radio into a 600Mhz
>> one, capable of non-line-of-sight links). No special considerations yet
>> in my mind, but still to be considered.
>>   6. Extra packages needed: the lime config doesn't include the
>> potential extra packages that might have been installed on a firmware,
>>   7. Attended upgrades server: this is key, as if there is one in your
>> network, you might do that before anything else (as it will have the
>> extra packages installed for example).
>> What has been done already (you can find it in the github repo:
>> https://github.com/libremesh/FirstBootWizard/ ):
>>   * serve-lime-config shares the lime-default with the network over
>> http, so anyone can fetch it. It is a symlink for the lime-defaults file
>> to a publicly accesible folder shared by uhttpd.
>>   * first-boot-wizard-daemon: a daemon that while in setup state
>> (defined by the presence of the /var/lock/first_run file) keeps
>> searching for nodes and fetching their config.
>>     The basic behaviour is:
>>     * no network config found around, keeps searching
>>     * one network config found around, applies its config and reboots
>> removing first_run file
>>     * many networks config found around, don't do anything, and keeps
>> them so the user can choose
>>     It also includes a ubus service to ask for the network config files
>> found around, so the user can choose which to join, or trigger it in a
>> latter moment if we want to reset the config to 'network defaults', and
>> also the ability to create a new network. These are the foundations to
>> add support in the lime-app.
>> Caveats:
>>   * are there anything within the lime-default file that we don't want
>> to be sharing openly within the adhoc/11s network?
>>   *  what is the UX we will provide is a password is needed?
>> Hope this is enough info to work on it! Will be around if any questions
>> appear, through here, Riot, Telegram, etc.
>> good luck!
>> _______________________________________________
>> lime-dev mailing list
>> lime-dev at lists.libremesh.org
>> https://lists.libremesh.org/mailman/listinfo/lime-dev
> _______________________________________________
> lime-dev mailing list
> lime-dev at lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-dev

More information about the lime-dev mailing list