[RFC] Add pkg gluon-hoodselector from google summer of code 2016

[2tata]

This MR is now just for tracking!

This patch contains the hoodselector and a domain.conf as an example.

The hoodselector is a software that creates decentralized, semi automated ISO OSI layer 2 network segmentation for batman-adv layer 2 routing networks. This program reads the geobased sub-networks called hoods(gluon domains) from the above mentioned domain configurations. The decision of choosing the right hood is made on following points: first, the hoodselector checks, if the router has a VPN connection. If it has, then its checks, if a geoposition was set on the router. Knowing the position of the router the hoodselector can find the right hood, because each hood is defined with geocoordinates. If the Router doesn't have a VPN connection e.g. as a mesh only router, the hoodselector triggers a WIFI scan and searches for neighboured mesh routers in other hoods. If there is an other router with a different BSSID/mesh ID but with the same mesh SSID, the router chooses it’s hood based on the neighboured BSSID. Ah deeper explanaton can be found here:
Monitoring and quality assurance of open wifi networks out of client view

Monitoring and quality assurance of open wifi networks out of client view (midterm evaluation)

Monitoring and quality assurance of open wifi networks out of client view (final evaluation)

In the Nordwest Freifunk Community we already had deployed the hood networks since august 2016
Our current active hoods can be seen on the Lutscher Lupe

This MR reference to #789 and replace #997

desired state diagram:

established state diagram:

• '''check_site.lua''' validate default domain to do not have shapes.

• '''check_site.lua''' validate non default domain to have rectangular shapes.

• '''check_site.lua''' validate non default domain to have polygon shapes.

• migrate VPN MODE to use site/domain configurations.

• migrate GATEWAY MODE to use site/domain configurations.

• migrate SCAN MODE for known hoods to use site/domain configurations.

• SCAN MODE: discuss how to handle unknown hoods?
  - try getting hood informations via respondd over unknown mehs ID?

• migrate RADIO LESS MODE to use site/domain configurations.

• migrate DEFAULT HOOD MODE to use site/domain configurations.

X Use iwinfo lua lib instead of external call ISSUE and MR

[lemoer]

@2tata Nice, that the work is going on here. Did you have a look at #1216 yet? I think, its nearly ready to merge.

What it does? It merges (selected) domain and site config into one config accessible via api. Same schema for settings is used in domain and in site configs. But since not all config settings make sense in a domain specific way, some are only allowed in site config. Some other values are only allowed in domain config. And the rest is allowed in both. This is implemented by extending the check_site_lib.lua. The existing ways to access the site (via site.lua or libgluonutil) now return a merged config from domain and site. Selecting a domain is handled via uci value gluon.system.domain for now.

What would be to do, to integrate hoodselector here:

• For now, we evaluate most parts of the config in /lib/gluon/upgrade/* scripts, which modify (persistent) uci variables. I think some work is done in netifd files, which directly read the site (without uci/flash writes). But this is the minor part.
• It would be very nice here, if we could change the district without persisting values to flash. Maybe you have an idea here?
• If the last step is done, the hoodselector could be a package, which changes just the actual domain via api.

What do you think?

[2tata]

On 09/19/17 01:44, lemoer wrote: @2tata Nice, that the work is going on here. Did you have a look at #1216 yet? I think, its nearly ready to merge.

Yes I did.

What would be to do, to integrate hoodselector here: - For now, we evaluate most parts of the config in /lib/gluon/upgrade/* scripts, which modify (persistent) uci variables. I think some work is done in netifd files, which directly read the site (without uci/flash writes). But this is the minor part. - It would be very nice here, if we could change the district without persisting values to flash. Maybe you have an idea here?

We had a discussion about that: should the hoodselector write conf persistent on flash. Our decision was: Yes, because we would avoid scenarios where thousands of routers trying to connect to the default hood, after rebooting. The hoodselector write only on the flash if the hood/domain has changes.

- If the last step is done, the hoodselector could be a package, which changes just the actual domain via api. What do you think?

The hoodselector do nearly the same what do have explained above. In case if #1216 get merges it should be quit easy to change the hoodselector to use the domain specific configs instead of the hood.json. currently I am working on finalising the state machine whitch means "hoodselector will never leave neigbour hood if a mesh router connect to them." and also on "Non rectangle polygones using Point in polygon test after Jordan". cheers Tarek

[2tata]

@NeoRaider : If that like you expect? I am not sure if I have all processes listed, which needs to be restarted.

[CodeFetch]

@2tata As Gluon has multi-domain support now, why are we still talking about hoods? Is there a difference?

[2tata]

hoods are equal to domains just a name

[CodeFetch]

@2tata It would be nice if the domain-selector would work independent from the method to determine the correct domain. That means split it in a package gluon-domain-selector-core and e.g. gluon-domain-selector-geo-polygons. This way kpanic23 could provide a package gluon-domain-selector-geo-webapi with similar functionality.
I don't like the idea of only having fixed borders for the domains, because it is frustrating having setup a node which has two connections to other nodes in different domains one with good signal strength and one with bad and unfortunately the coordinates say the node is in the domain of the node to which it has a bad connection. There needs to be a function in the gluon-domain-selector-core package to prioritize the methods. E.g. first use gluon-domain-selector-choose-neighbours which is a package that checks if there are wifi neighbours around and if that is the case it uses a simple formula to derive the domain which gives the best connectivity in average or even simpler just choose the domain of the node to which it has the best wifi connection. If that fails, because there are no neighbours around or the connection threshold is too low or whatever, use gluon-domain-selector-choose-geo which tries to derive the domain from one of the gluon-domain-selector-geo-* packages depending on which one is installed and provides the gluon-domain-selector-geo meta-package. If that fails e.g. because it does not know any coordinates, use gluon-domain-selector-choose-default which is a package that simply chooses the default domain.
I just think the complexity of the gluon-hoodselector is too high to not separate it into different packages.

EDIT: Maybe I didn't make it clear enough. These were just examples of how to increase modularity and understandability. Many smaller packages are much easier to review and will likely be merged faster.