Hoodselector #997
Hoodselector #997
Conversation
|
I also think that a flow chart or a graph of the state machine in this package would be very nice to understand what's going on. Update: Maybe simple pseudo code would be also okay. |
|
I have not read the implementation of the hoodselector yet, but I already have some comments on the discussed algorithm/state machine:
|
| file:write(json.stringify(hood, { indent = true })) | ||
| file:close() | ||
| --part to create md5 hash of this file | ||
| for line in io.popen(string.format( "md5sum /tmp/.hoodhash")):lines() do |
There was a problem hiding this comment.
We have a builtin function to do md5 hashes:
There was a problem hiding this comment.
In the current version it is already solved by hash.c
rotanid
added
0. type: enhancement
|
Depending on the comment of @lemoer
If you take a look to the Sourcecode than the border is really thin and not thick. There is no Tri-State Possible. The Router can only be in one Area and not in Two Areas to the same Time All in all, there can not be (for the moment)
|
|
I`ve created a rough state diagrame from the hoodselector:
but notice the version here ist not the newest.
The diagrame for the newest is:
https://mw.ffnw.de/images/2/2b/Hoodselector.jpeg
vg
Tarek
|
|
So if you have radios, but no radio neighbors, then the router would not look for cable neighbors hood? |
|
On 02/18/17 15:27, Adorfer wrote:
So if you have radios, but no radio neighbors, then the router would not look for cable neighbors hood?
Oh, I´ll change it in the diagram.
Inside the code the hoodselector will check the cable neighbors if no radio neighbors founded.
vg
Tarek
|
|
@2tata
|
|
On 02/18/17 22:14, Adorfer wrote:
@2tata
In case a node has VPN and no geoposition, it will go into the default hood, even if it sees radio- or lan neighbors in local hoods?
Right, because a vpn router has a high priorety then others. A VPN router have a connection to internet an can get its position
for exsample wifi based location or geo IP location.
even switching of too many routers from one hood into an another from the VPN server view is not possebile.
vg
Tarek
|
|
I would suggest to avoid routers from different hoods on the same ethernet (even on different vlan/vxlan). |
|
On 02/19/17 02:03, Adorfer wrote:
I would suggest to avoid routers from different hoods on the same ethernet (even on different vlan/vxlan).
So i would always priorize any ethernet-neighbors's decision, even if there is other location "via wifiscanning" is available,
right that wars the plan but vxlan is at themoment not avalebile.
The developmend based on v2016.1.x
vg
Tarek
|
|
On 02/19/17 02:03, Adorfer wrote:
I would suggest to avoid routers from different hoods on the same ethernet (even on different vlan/vxlan).
So i would always priorize any ethernet-neighbors's decision, even if there is other location "via wifiscanning" is available,
The main plan is to avoid collisions by lan/wan with VXLAN but currently VXLAN wars not available. Actually there is a
alterative solution called molwm (mesh on lan wan management) that routers checking if there have mesh neighbours over
lan/wan from other hoods they will disable mesh on the collision interface and automatically enable it if the collision
solved. This Workaround will be replaced in future with VXLAN.
vg
Tarek
|
| key = hood_server.publickey, | ||
| remote = {'\"'..hood_server.host..'\"'..' port '..hood_server.port} | ||
| } | ||
| ) |
There was a problem hiding this comment.
Having such large config blocks in here makes maintenance had, since every change to the fastd uci configuration block needs to be mirrored here :(
There was a problem hiding this comment.
In my opinion it makes more sense to store the hoods.json besides the site.conf, so there is no need for an extra package and the package should be renamed to something like gluon-*.
Additional there is
- no manual configuration possible
- no change of the SSID when changing the hood
- no change of next-node IP and prefixes
| net = 'mesh_vpn', | ||
| group = group, | ||
| key = hood_server.publickey, | ||
| remote = {'\"'..hood_server.host..'\"'..' port '..hood_server.port} |
There was a problem hiding this comment.
It is only possible to add just one remote per peer, but we have three in our site.conf (dns, IPv4, IPv6)
| -- passes. Otherwise the method returns false. | ||
| local function wireless_reconfiguration_needed(radios, hood_bssid) | ||
| for index, radio in ipairs(radios) do | ||
| if ( uci:get('wireless', 'ibss_' .. radio, 'bssid') ~= hood_bssid ) then |
There was a problem hiding this comment.
This only refers to IBSS mesh networks, but there is also the 802.11s mesh.
| -- Reconfigure wireless | ||
| local function wireless_reconfigure(radios, hood_bssid) | ||
| for index, radio in ipairs(radios) do | ||
| if not ( uci:get('wireless', 'ibss_' .. radio, 'bssid') == hood_bssid ) then |
| "defaulthood": true, | ||
| "servers": [ | ||
| { | ||
| "host": "default02.entenhausen.de", |
There was a problem hiding this comment.
Why are you using a different structure for the fastd configuration than the site.conf?
| @@ -0,0 +1 @@ | |||
| */2 * * * * /usr/sbin/hoodselector | |||
There was a problem hiding this comment.
So the hood may change every two minutes? That seems to be rather often.
| end | ||
|
|
||
| -- Create md5 hash from currend hood | ||
| local function molwm_md5hash(hood) |
There was a problem hiding this comment.
What are the improvements in using the md5hash instead of the hoodname?
| local ifname = uci:get('wireless', 'ibss_' .. radio, 'ifname') | ||
| local ssid = uci:get('wireless', 'ibss_' .. radio, 'ssid') | ||
| if (ifname ~= nil and ssid ~= nil) then | ||
| local wireless_scan = string.format( "iw %s scan", ifname) |
There was a problem hiding this comment.
You may use something like:
local iwinfo = require "iwinfo"
local wifitype = iwinfo.type(radio)
local iw = iwinfo[wifitype]
if iw then
local tmplist = iw.scanlist(radio)
for _, net in ipairs(tmplist) do
...
where tmplist is some kind of lua array, so there is no need to parse the output of iw $ifname scan
| local function getHoodByGeo(jhood,geo) | ||
| for n, h in pairs(jhood) do | ||
| for n, box in pairs(h.boxes) do | ||
| if ( geo[1] >= box[1][1] and geo[1] < box[2][1] and geo[2] >= box[1][2] and geo[2] < box[2][2] ) then |
There was a problem hiding this comment.
This only allows some kind of rectangular shape, which seems not to be suitable for practical use.
| brclient_restart() | ||
| end | ||
|
|
||
| local function vpn_disable() |
There was a problem hiding this comment.
This script should not disable or enable the fastd autostart.
| continue; | ||
|
|
||
| struct json_object *ret = json_object_new_object(); | ||
| json_object_object_add(ret, "bssid", gluonutil_wrap_string(bssid)); |
There was a problem hiding this comment.
I may agree with adding some hoodname and/or md5hash, but I do not understand, why the bssid is needed.
|
Hi,
On 03/24/17 12:44, kb-light wrote:
kb-light commented on this pull request.
- no manual configuration possible
Right the hoodselector sould do it by it selfe.
- no change auf the SSID
The SSID should not change by switching a hood.
- no change of next-node IP and prefixes
This is a special v6 address to just get datas from directly local nodes via linklocal.
This address is fix.
In my opinion it makes more sense to store the hoods.json besides the site.conf, so there is no need for an extra package and the package should be renamed to something like `gluon-*`.
Right, I am working on it.
Today I had finished support for IEEE802.11s
At the moment I am working on l2tp support in the hoodselector
Next should be the hoodfile package.
cheers
Tarek
|
|
Sorry, I diddet saw the inlines.
> +local function vpn_reconfigure(hood_serverlist,local_serverlist)
+ -- remove all servers
+ for config_index, local_server in pairs(local_serverlist) do
+ uci:delete('fastd',config_index)
+ end
+
+ -- add servers from hoodfile
+ local group = 'mesh_vpn_backbone'
+ for i,hood_server in pairs(hood_serverlist) do
+ uci:section('fastd', 'peer', group .. '_peer_' .. hood_server.host:split('.')[1]:gsub("%-", "%_"),
+ {
+ enabled = 1,
+ net = 'mesh_vpn',
+ group = group,
+ key = hood_server.publickey,
+ remote = {'\"'..hood_server.host..'\"'..' port '..hood_server.port}
It is only possible to add just one remote per peer, but we have three in our site.conf (dns, IPv4, IPv6)
correkt... I have to check this. Please can you send me a link of your site.conf?
> + key = hood_server.publickey,
+ remote = {'\"'..hood_server.host..'\"'..' port '..hood_server.port}
+ }
+ )
+ end
+
+ uci:save('fastd')
+ uci:commit('fastd')
+ io.stderr:write('Fastd needed reconfiguration. Stopped and applied new settings.\n')
+end
+
+-- Checks if wireless needs a reconfiguration. Returns true if any of the checks
+-- passes. Otherwise the method returns false.
+local function wireless_reconfiguration_needed(radios, hood_bssid)
+ for index, radio in ipairs(radios) do
+ if ( uci:get('wireless', 'ibss_' .. radio, 'bssid') ~= hood_bssid ) then
This only refers to IBSS mesh networks, but there is also the 802.11s mesh.
In a new version this is already solved.
> +
+-- Checks if wireless needs a reconfiguration. Returns true if any of the checks
+-- passes. Otherwise the method returns false.
+local function wireless_reconfiguration_needed(radios, hood_bssid)
+ for index, radio in ipairs(radios) do
+ if ( uci:get('wireless', 'ibss_' .. radio, 'bssid') ~= hood_bssid ) then
+ return true
+ end
+ end
+ return false
+end
+
+-- Reconfigure wireless
+local function wireless_reconfigure(radios, hood_bssid)
+ for index, radio in ipairs(radios) do
+ if not ( uci:get('wireless', 'ibss_' .. radio, 'bssid') == hood_bssid ) then
Same es line 464
> @@ -0,0 +1,64 @@
+[
+ {
+ "name": "default",
+ "bssid": "02:CA:FF:AA:BA:BF",
+ "defaulthood": true,
+ "servers": [
+ {
+ "host": "default02.entenhausen.de",
Why are you using a different structure for the fastd configuration than the site.conf?
Because more informations wars not necessery.
> @@ -0,0 +1 @@
+*/2 * * * * /usr/sbin/hoodselector
So the hood may change every two minutes? That seems to be rather often.
> + if uci:get('network', 'mesh_wan') and not mesh_en then
+ mesh_on_wan_disable()
+ end
+ if uci:get('network', 'mesh_lan') and not mesh_en then
+ mesh_on_lan_disable()
+ end
+ if uci:get('network', 'mesh_wan') and mesh_en then
+ mesh_on_wan_enable()
+ end
+ if uci:get('network', 'mesh_lan') and mesh_en then
+ mesh_on_lan_enable()
+ end
+end
+
+-- Create md5 hash from currend hood
+local function molwm_md5hash(hood)
What are the improvements in using the md5hash instead of the hoodname?
There ist a special case inside the scan mode if the hood not known. Were a
hoodconf will aplay with changed neigbour bssid. This will change the hash.
> + end
+ )
+ return radios
+end
+
+-- Scans for wireless networks and returns a two dimensional array containing
+-- wireless mesh neigbour networks and their properties.
+-- The array is sorted descending by signal strength (strongest signal
+-- first, usually the local signal of the wireless chip of the router)
+local function wlan_list_sorted(radios)
+ local networks = {}
+ for index, radio in ipairs(radios) do
+ local ifname = uci:get('wireless', 'ibss_' .. radio, 'ifname')
+ local ssid = uci:get('wireless', 'ibss_' .. radio, 'ssid')
+ if (ifname ~= nil and ssid ~= nil) then
+ local wireless_scan = string.format( "iw %s scan", ifname)
You may use something like:
local iwinfo = require "iwinfo"
local wifitype = iwinfo.type(radio)
local iw = iwinfo[wifitype]
if iw then
local tmplist = iw.scanlist(radio)
for _, net in ipairs(tmplist) do
...
where `tmplist` is some kind of lua array, so there is no need to parse the output of `iw $ifname scan`
Oh, thanks that a good point :)
> +end
+
+
+-- Get Geoposition. Return nil for no position
+local function getGeolocation()
+ local ret = {}
+ table.insert(ret, tonumber(uci:get('gluon-node-info', uci:get_first('gluon-node-info', 'location'), 'latitude')))
+ table.insert(ret, tonumber(uci:get('gluon-node-info', uci:get_first('gluon-node-info', 'location'), 'longitude')))
+ return ret
+end
+
+-- Return hood from the hood file based on geo position or nil, no real hood could be determined
+local function getHoodByGeo(jhood,geo)
+ for n, h in pairs(jhood) do
+ for n, box in pairs(h.boxes) do
+ if ( geo[1] >= box[1][1] and geo[1] < box[2][1] and geo[2] >= box[1][2] and geo[2] < box[2][2] ) then
This only allows some kind of rectangular shape, which seems not to be suitable for practical use.
This is realy practical for use. See https://srv11.ffnw.de/ and enable hood layer. (cert is wrong sorry for that)
> + os.execute('ifconfig br-client up')
+ io.stderr:write('Interface br-client restarted.\n')
+end
+
+local function vpn_stop()
+ os.execute('/etc/init.d/fastd stop')
+ io.stderr:write('VPN stopped.\n')
+end
+
+local function vpn_start()
+ os.execute('/etc/init.d/fastd start')
+ io.stderr:write('VPN started.\n')
+ brclient_restart()
+end
+
+local function vpn_disable()
This script should not disable or enable the fastd autostart.
It shoult in a special case. To avoide damaging the network.
> +
+ struct uci_element *e;
+ uci_foreach_element(&p->sections, e) {
+ struct uci_section *s = uci_to_section(e);
+ if (strcmp(s->type, "wifi-iface"))
+ continue;
+
+ if (strncmp(e->name, "ibss_", 5))
+ continue;
+
+ const char *bssid = uci_lookup_option_string(ctx, s, "bssid");
+ if (!bssid)
+ continue;
+
+ struct json_object *ret = json_object_new_object();
+ json_object_object_add(ret, "bssid", gluonutil_wrap_string(bssid));
I may agree with adding some `hoodname` and/or `md5hash`, but I do not understand, why the `bssid` is needed.
The hoodselector in a newer version work with this bssid in mesh lan/wan constructed.
An new pull request will follow soon.
cheers
Tarek
|
|
@2tata does every hood has its own IP space? |
|
On 03/25/17 11:55, kb-light wrote:
@2tata does every hood has its own IP space?
Right. Encoded in the BSSID
cheers
Tarek
|
|
On 03/25/17 11:55, kb-light wrote:
@2tata does every hood has its own IP space?
You can read folliwing:
https://blog.freifunk.net/2016/05/23/monitoring-and-quality-assurance-open-wifi-networks-out-client-view/
https://blog.freifunk.net/2016/06/19/monitoring-and-quality-assurance-open-wifi-networks-out-client-view-midterm-evaluation/
https://blog.freifunk.net/2016/08/22/monitoring-and-quality-assurance-open-wifi-networks-out-client-view-final-evaluation/
cheers
Tarek
|
In case of discussions about the autoupdater it would be nice to have the option to set the hood manually. Additional there nodes where the owner does not want to set the geolocation, but the hood should be selected correctly. Even if there is no local mesh.
But each hood has it own IP space, so not changing the SSID may break roaming.
But changing the IP space, because of changing the hood, would break the next node feature, so this address should be changed to, to match the new IP space.
An example was added to gluon with adf3b91.
I do not meant to add the whole fastd section but adding the remotes as it is done within the site.conf, so hostname and port are just one string.
We have selected some shapes for our regions/hoods that are not even foursquar, see: http://umap.openstreetmap.fr/de/map/freifunk-hochstift-sites-karte_60146#10/51.7011/8.9243
Is stopping the fastd not enough in that case? |
|
Hi @2tata, Great work so far! And thanks for the flow chart, that definitely helps to get a quick understanding. Two technical question: "geo pos. exists", is it determined from the user geo position manually configured by the user? Why is that branch depending on a VPN connection? A few conceptual questions: Scenario A):
hoodselector.dia.its-not-a.txt Node A and B are in different hoods and are the only VPN uplinks for this local mesh cloud. Node C can reach A and B about equally well. Sometimes A is slightly "better", sometimes B. Q1/Q2/Q3 describe three geographical hoods with their borders as specified by the hoods.json. Questions: Can you describe what would usually happen for the hood selection for nodes in Q2? What could happen in the worst case? Scenario B): Just like scenario A), but node D sometimes gains and sometimes looses a VPN uplink. Questions: Same above. Scenario C):
hoodselector2.dia.its-not-a.txt Compared to scenario A), now E has the wifi connection to node A. Questions: Would anything change concerning the hood selection within Q2 compared to scenario A) or B)? What would happen if the topology switches between scenario A) and C) from time to time? Also, the roaming concerns @kb-light mentioned with using the same ESSID with different IP spaces is something I'd be worried about, too. At least along hood borders. Would love to hear some clarifications for that too. |
|
And one more question: Are there any recommendations on how to use this package together with wifi backbone setups? |
|
@T-X sorry I didnt saw the Mail.
Because A VPN router have a function like "gate to the rest on net" each hood has other VPN peers determinate by geopositions. Other Router without VPN conections trys to stay by a VPN router. If we just say on a mesh only router set hood by geo that would not work. Scenario A): Scenario B): Scenario C): In Freifunk Nordwest we defined the hoods that hood borders will not across a city. Few weeks ago I have already finished the IEEE802.11s support. If you are on the WCW2017 I will hold a presentation and we can discuss about that. |
1 similar comment
|
@T-X sorry I didnt saw the Mail.
Because A VPN router have a function like "gate to the rest on net" each hood has other VPN peers determinate by geopositions. Other Router without VPN conections trys to stay by a VPN router. If we just say on a mesh only router set hood by geo that would not work. Scenario A): Scenario B): Scenario C): In Freifunk Nordwest we defined the hoods that hood borders will not across a city. Few weeks ago I have already finished the IEEE802.11s support. If you are on the WCW2017 I will hold a presentation and we can discuss about that. |
|
|
|
@2tata Are there any simplifications in the mechanism since vxlan is supported? |
|
@2tata Do you think, you see a chance to drop your "hoodfiles" in favor of the domain configs proposed in #1216 ?
|
|
On 09/04/17 22:45, lemoer wrote:
@2tata Do you think, you see a chance to drop your "hoodfiles" in favor of the domain configs proposed in #1216 ?
- **disadvantage:** hoods could not be changed without rolling out a new firmware anymore.
That was my plan, to share the hoodfile with other routers because for thous configurations it is not necessary to roll out a new Firmware over the whole network.
- **advantage:** checking the domain config would be well integrated in the gluon framework and so there will be no more than one (code) location, where configs are verified.
Maybe we can split up the site.conf into a dynamic and a static part?
So the static part will be only change be Firmware upgrades and the
dynamic part can be replace on runtime in future?
But I am flexible and can also drop the hoodfile if it wished.
cheers,
Tarek
|
(copy&pasted from @2tata's mail thread)
This patch set contains the hoodselector and a hoodfile as exsample.
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 from the above mentioned hoodfile. 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, the hoodselector then 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 but with the same mesh SSID, the router chooses it’s hood based on the neighboured BSSID. Open issues can be found here