10 Sep
2018
10 Sep
'18
11:22 a.m.
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!
10 Sep
10 Sep
11:35 a.m.
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.
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.
The strong idea about this is to get an openwrt firmware ready to go
and capable of doing mesh. So if the firmware is well done, the user
don't need to enter the antena to do any configuration. 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(a)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(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
12:09 p.m.
New subject: Temba ERA Re: FirstBootWizard Description for Hackathon in Quintana
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
alltogether.
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
Thanks,
[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(a)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(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
12:44 p.m.
New subject: Temba ERA Re: FirstBootWizard Description for Hackathon in Quintana
I tried libremesh but I didn't like. It was very strange the way new
options are added. When I discussed this problem with some of the
libremesh developers they did not see complexity so it was clearly a
different point of view about the problem. I discussed with some users
and they also find this problematic. I think we suffered too much the
problems of the configuration mess with qMp. In the end, the most
valuable thing of qMp was the good integration of bmx6 with openwrt.
Yanosz's work on https://github.com/yanosz/mesh_testbed_generator/
showed what was missing to build your firmware in an easy manner.
Building firmwares and images is complicated in general, but the build
system for openwrt it's the exception: it's great. I enjoyed so much
having the opportunity to select specific version of software I want
to build with the firmware.
I was thinking that another approach should work and I found the opportunity.
Our users are not hackers, 99% buy the same device and 99% have the
same configuration pattern. The idea is that there are people
responsible of the community firmware decide the design of the network
and the supported devices. What needs to be templated, what not and
what are the parameters for user. Temba regular node just need 3
parameters: node name, wifi channel and IPv4 (because our
compatibility with classic guifi.net webpage / but IP planning is very
useful in my opinion!).
It just "works for us", and we are sharing our work to others if that
is useful. Not pretending anything.
With this "kind of hack" I feel a lot of control of what I'm doing:
clear way fof changing configuration options, of changing parts of the
firmware (its software versions), changing to new release... It is so
simple (once you get all the pieces and relations) that you don't want
to simplicity (and inherently destroy required complexity).
The project is new, young and growing. At some point perhaps I
discover that this template idea is a mess. We will see.
I also feel I am more close to openwrt community.
I'm not worried about maintaining temba. It is too simple, just a
templating thing with some things to consider.
From the temba point of view: your project (libremesh)
is still very
important because generates important configuration options we use/we
copy.
Libremesh, temba, and other community network firmware, are different
approaches to the same problem.
3:48 p.m.
New subject: Temba ERA Re: FirstBootWizard Description for Hackathon in Quintana
El 10/09/18 a las 14:44, guifipedro escribió:
I tried libremesh but I didn't like. It was very
strange the way new
options are added.
You mean:
* options to the lime config package?
* the module system for adding new features to the system?
* new packages to lime-sdk?
* any other?
When I discussed this problem with some of the
libremesh developers they did not see complexity so it was clearly a
different point of view about the problem.
I discussed with some users and they also find this
problematic.
If you are not the only one having the issue... then the issue must be
raised to the bigger community, not to one dev. I encourage you to share
your point of view of what can be improved over here... or better, send
a pull request :) (you can start by writing an RFC of it!)
Yanosz's work on
https://github.com/yanosz/mesh_testbed_generator/
showed what was missing to build your firmware in an easy manner.
Have you tried chef.libremesh.org ?
the way libremesh deals with having different configs for different
devices is abstracting and detecting the hardware differences, and
ultimately having different configs for different types of devices
within the mesh... not necesary for diferences within the hardware of them.
I was thinking that another approach should work and I
found the opportunity.
Do you have a list of the things that the current system was not
achieving that you were expecting? that would help the conversation :)
The idea is that there are people
responsible of the community firmware decide the design of the network
and the supported devices. What needs to be templated, what not and
what are the parameters for user.
that is basically how lime is working right now.
using firstbootwizard, many of the usecases will be dealt with at boot
time and not at firmware building time (cause that will not exist, as it
will come from factory with librerouter (and possibly many others).
[snip]
The project is new, young and growing. At some point
perhaps I
discover that this template idea is a mess. We will see.
Templating is a good approach when you write the config only at build time.
using uci on the other hand helps be compatible with potential other
configs happen at the same time.
I also feel I am more close to openwrt community.
If that is the purpose, I would definitely try the uci approach, as it
is much closer to the openwrt community!
From the temba point of view: your project (libremesh)
is still very
important because generates important configuration options we use/we
copy.
Libremesh, temba, and other community network firmware, are different
approaches to the same problem.
LibreMesh tries to include us all... that is one of the missions.
Hope you share your inputs.
Regards,
8 Oct
8 Oct
10:10 a.m.
New subject: Temba ERA Re: FirstBootWizard Description for Hackathon in Quintana
For example, we had this problem (missing an option). In fact me and
another guy after resolution we felt that this was not for us, that we
wanted to work directly with config files from openwrt
https://github.com/libremesh/lime-packages/issues/339
Libremesh does zero effort reading openwrt configuration (but
really, I see no effort to have this features. Is like, I have enough
with one universe, I don't need to think in parallel universes). Lime
proposed "solution" is to use lime config. But using lime config
implies having to do consensus (and touching strange parts of code I
don't get) on what options are used for the community / in general.
But in the end, we are designing "good configuration files" for
devices compatible for our routing protocols. At the moment what I
think is: this is too much complexity. I know openwrt works the same
way with code written in C. Templates architectures, devices, etc.
Libremesh does the same but with lua code? I have enough with openwrt
complexity. And most importantly, I want users interact sharing their
config files. So I prefer a blind approach: "this options works,
include it, or I include myself".
You are saying that is not justifiable because libremesh does the
same. I did an effort to understand libremesh, did you try to
understand temba? I don't have so much documentation but essentially:
erb templates on config files per device (some files are shared)
evaluated from inherited yaml files with two interfaces: rake and
rubyonrails form.
Do you understand now how different are the firmwares and that they
are trying to solve the problem with very different approach?
11:49 a.m.
New subject: Temba ERA Re: FirstBootWizard Description for Hackathon in Quintana
On Monday, 8 October 2018 12:10:25 CEST guifipedro wrote:
At the moment what I
think is: this is too much complexity. I know openwrt works the same
way with code written in C. Templates architectures, devices, etc.
Libremesh does the same but with lua code? I have enough with openwrt
complexity. And most importantly, I want users interact sharing their
config files. So I prefer a blind approach: "this options works,
include it, or I include myself".
You are saying that is not justifiable because libremesh does the
same. I did an effort to understand libremesh, did you try to
understand temba? I don't have so much documentation but essentially:
erb templates on config files per device (some files are shared)
evaluated from inherited yaml files with two interfaces: rake and
rubyonrails form.
Are you joking?
You are arguing that libremesh is too complex because it is written in Lua
(one of the most minimal and simple languages out there) and then you propose
to solve this complexity by providing yet another one man firmware with no
documentation + erb templates + yaml + rake + ruby on rails ?
I think this is too much even for Kolmogorov...
Also from what you written you seems to describe openwrt options like as if
they where just bricks of different colors which has almost no interactions
between each others, so one need just pick another if per doesn't like the
color of this, and thinks will works out of the box just with a different sum
of colors...
While I am quite confident to say it is quite common experience that the
options have very complex interactions so most of them need to be set in a
coherent way according with the others and tested with much care, and this one
of the big source of complexity not just of libremesh, but of any other
solution to similar problem.
Do you understand now how different are the firmwares
and that they
are trying to solve the problem with very different approach?
I think that Temba and libremesh are completely different beasts.
I have no problem with you trying different approaches and actually I think it
is good for you to write your own tools, but I think the problem you are
trying to solve is obviously different from the one libremesh targets, and it
is out of scope on lime-* mailing list, especially on an hijacked thread.
Cheers!
Gio
2048
days inactive
2076
days old
6 comments
3 participants
participants (3)
-
Gio -
guifipedro -
Nicolas Pace