New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hoodselector #997

Closed
wants to merge 7 commits into
base: master
from

Conversation

Projects
None yet
9 participants
@jplitza
Member

jplitza commented Dec 29, 2016

(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

@lemoer

This comment has been minimized.

Show comment
Hide comment
@lemoer

lemoer Dec 31, 2016

Contributor

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.

Contributor

lemoer commented Dec 31, 2016

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.

@lemoer

This comment has been minimized.

Show comment
Hide comment
@lemoer

lemoer Dec 31, 2016

Contributor

I have not read the implementation of the hoodselector yet, but I already have some comments on the discussed algorithm/state machine:

  1. You are using rectangles for the "geo decision". This will only work for your actual split-task in ffnw. Other communities will need much more differentiated geo decisions, since they e.g. want to split at rivers.

  2. I think it would be very useful, if the algorithm would rely on the "scan decision" if the geo position of the router is at the border of a hood. Now the question comes up, how thick this border should be. I think we can handle this question by the following idea:

    • I think (by now) you assert, that the geo hoods are defined geometrically disjunct.
    • Drop this assertion.
    • Use the following algorithm:
      1. If geo position set:
          a. If multiple hoods match geo:
              1. use the "wifi scan decision":
                  a. sucessful: join the resulting hood
                  b. no neighbours: use one of the geo matches
          b. If one hood match geo: use this hood
          c. Else: Use the default hood
       2. Else: use the "scan decision"
      
    • The result of this algorithm would be, that the above described borders are defined by the overlap of hoods.
      • If one do not want to have this "border scan"-behavior, he could simply define the hoods geomatrically disjunct.
    • This idea would also remove the need for validating whether the hoods are defined geomatrically disjunct, which I think is needed by now.
  3. A manual overwrite in the config mode would be nice to have.

Contributor

lemoer commented Dec 31, 2016

I have not read the implementation of the hoodselector yet, but I already have some comments on the discussed algorithm/state machine:

  1. You are using rectangles for the "geo decision". This will only work for your actual split-task in ffnw. Other communities will need much more differentiated geo decisions, since they e.g. want to split at rivers.

  2. I think it would be very useful, if the algorithm would rely on the "scan decision" if the geo position of the router is at the border of a hood. Now the question comes up, how thick this border should be. I think we can handle this question by the following idea:

    • I think (by now) you assert, that the geo hoods are defined geometrically disjunct.
    • Drop this assertion.
    • Use the following algorithm:
      1. If geo position set:
          a. If multiple hoods match geo:
              1. use the "wifi scan decision":
                  a. sucessful: join the resulting hood
                  b. no neighbours: use one of the geo matches
          b. If one hood match geo: use this hood
          c. Else: Use the default hood
       2. Else: use the "scan decision"
      
    • The result of this algorithm would be, that the above described borders are defined by the overlap of hoods.
      • If one do not want to have this "border scan"-behavior, he could simply define the hoods geomatrically disjunct.
    • This idea would also remove the need for validating whether the hoods are defined geomatrically disjunct, which I think is needed by now.
  3. A manual overwrite in the config mode would be nice to have.

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

This comment has been minimized.

@lemoer
@lemoer

lemoer Dec 31, 2016

Contributor

This comment has been minimized.

@2tata

2tata Feb 16, 2017

Contributor

In the current version it is already solved by hash.c

@2tata

2tata Feb 16, 2017

Contributor

In the current version it is already solved by hash.c

@PowerPan

This comment has been minimized.

Show comment
Hide comment
@PowerPan

PowerPan Feb 16, 2017

Contributor

Depending on the comment of @lemoer

I think it would be very useful, if the algorithm would rely on the "scan decision" if the geo position of the router is at the border of a hood. Now the question comes up, how thick this border should be. I think we can handle this question by the following idea:

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

https://git.ffnw.de/ffnw-firmware/packages/blob/master/hoodselector/luasrc/usr/sbin/hoodselector#L428-438

-- Return hood from the hood file based on geo position or nil, no real hood could be determined
local function getHoodByGeo(jhood,geo)
  for _, h in pairs(jhood) do
    for _, box in pairs(h.boxes) do
      if ( geo.lat >= box[1][1] and geo.lat < box[2][1] and geo.lon >= box[1][2] and geo.lon < box[2][2] ) then
        return h
      end
    end
  end
  return nil
end

All in all, there can not be (for the moment)

If multiple hoods match geo

Contributor

PowerPan commented Feb 16, 2017

Depending on the comment of @lemoer

I think it would be very useful, if the algorithm would rely on the "scan decision" if the geo position of the router is at the border of a hood. Now the question comes up, how thick this border should be. I think we can handle this question by the following idea:

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

https://git.ffnw.de/ffnw-firmware/packages/blob/master/hoodselector/luasrc/usr/sbin/hoodselector#L428-438

-- Return hood from the hood file based on geo position or nil, no real hood could be determined
local function getHoodByGeo(jhood,geo)
  for _, h in pairs(jhood) do
    for _, box in pairs(h.boxes) do
      if ( geo.lat >= box[1][1] and geo.lat < box[2][1] and geo.lon >= box[1][2] and geo.lon < box[2][2] ) then
        return h
      end
    end
  end
  return nil
end

All in all, there can not be (for the moment)

If multiple hoods match geo

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Feb 18, 2017

Contributor
Contributor

2tata commented Feb 18, 2017

@Adorfer

This comment has been minimized.

Show comment
Hide comment
@Adorfer

Adorfer Feb 18, 2017

Contributor

So if you have radios, but no radio neighbors, then the router would not look for cable neighbors hood?

Contributor

Adorfer commented Feb 18, 2017

So if you have radios, but no radio neighbors, then the router would not look for cable neighbors hood?

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Feb 18, 2017

Contributor
Contributor

2tata commented Feb 18, 2017

@Adorfer

This comment has been minimized.

Show comment
Hide comment
@Adorfer

Adorfer Feb 18, 2017

Contributor

@2tata
onther 2 points:

grafik

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

  2. if a nodes sees lan neigbours in hood A and wifineighbors in a ("very remote"/low TQ) hood B, it will go to hood B, eventhough, lan neighbors are available in A?

Contributor

Adorfer commented Feb 18, 2017

@2tata
onther 2 points:

grafik

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

  2. if a nodes sees lan neigbours in hood A and wifineighbors in a ("very remote"/low TQ) hood B, it will go to hood B, eventhough, lan neighbors are available in A?

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Feb 18, 2017

Contributor
Contributor

2tata commented Feb 18, 2017

@Adorfer

This comment has been minimized.

Show comment
Hide comment
@Adorfer

Adorfer Feb 19, 2017

Contributor

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,

Contributor

Adorfer commented Feb 19, 2017

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,

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Feb 19, 2017

Contributor
Contributor

2tata commented Feb 19, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Feb 19, 2017

Contributor
Contributor

2tata commented Feb 19, 2017

key = hood_server.publickey,
remote = {'\"'..hood_server.host..'\"'..' port '..hood_server.port}
}
)

This comment has been minimized.

@mweinelt

mweinelt Mar 23, 2017

Contributor

Having such large config blocks in here makes maintenance had, since every change to the fastd uci configuration block needs to be mirrored here :(

@mweinelt

mweinelt Mar 23, 2017

Contributor

Having such large config blocks in here makes maintenance had, since every change to the fastd uci configuration block needs to be mirrored here :(

@kb-light

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}

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

It is only possible to add just one remote per peer, but we have three in our site.conf (dns, IPv4, IPv6)

@kb-light

kb-light Mar 24, 2017

Contributor

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

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

This only refers to IBSS mesh networks, but there is also the 802.11s mesh.

@kb-light

kb-light Mar 24, 2017

Contributor

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

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

Same es line 464

@kb-light

kb-light Mar 24, 2017

Contributor

Same es line 464

"defaulthood": true,
"servers": [
{
"host": "default02.entenhausen.de",

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

Why are you using a different structure for the fastd configuration than the site.conf?

@kb-light

kb-light Mar 24, 2017

Contributor

Why are you using a different structure for the fastd configuration than the site.conf?

@@ -0,0 +1 @@
*/2 * * * * /usr/sbin/hoodselector

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

So the hood may change every two minutes? That seems to be rather often.

@kb-light

kb-light Mar 24, 2017

Contributor

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)

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

What are the improvements in using the md5hash instead of the hoodname?

@kb-light

kb-light Mar 24, 2017

Contributor

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)

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

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

@kb-light

kb-light Mar 24, 2017

Contributor

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

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

This only allows some kind of rectangular shape, which seems not to be suitable for practical use.

@kb-light

kb-light Mar 24, 2017

Contributor

This only allows some kind of rectangular shape, which seems not to be suitable for practical use.

brclient_restart()
end
local function vpn_disable()

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

This script should not disable or enable the fastd autostart.

@kb-light

kb-light Mar 24, 2017

Contributor

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

This comment has been minimized.

@kb-light

kb-light Mar 24, 2017

Contributor

I may agree with adding some hoodname and/or md5hash, but I do not understand, why the bssid is needed.

@kb-light

kb-light Mar 24, 2017

Contributor

I may agree with adding some hoodname and/or md5hash, but I do not understand, why the bssid is needed.

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Mar 24, 2017

Contributor
Contributor

2tata commented Mar 24, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Mar 24, 2017

Contributor
Contributor

2tata commented Mar 24, 2017

@kb-light

This comment has been minimized.

Show comment
Hide comment
@kb-light

kb-light Mar 25, 2017

Contributor

@2tata does every hood has its own IP space?

Contributor

kb-light commented Mar 25, 2017

@2tata does every hood has its own IP space?

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Mar 25, 2017

Contributor
Contributor

2tata commented Mar 25, 2017

@kb-light

This comment has been minimized.

Show comment
Hide comment
@kb-light

kb-light Mar 25, 2017

Contributor

Right the hoodselector sould do it by it selfe.

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.

The SSID should not change by switching a hood.

But each hood has it own IP space, so not changing the SSID may break roaming.

This is a special v6 address to just get datas from directly local nodes via linklocal. This address is fix.

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.

correkt... I have to check this. Please can you send me a link of your site.conf?

An example was added to gluon with adf3b91.

Because more informations wars not necessery.

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.

This is realy practical for use. See https://srv11.ffnw.de/ and enable hood layer. (cert is wrong sorry for that)

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

It should in a special case. To avoid damaging the network.

Is stopping the fastd not enough in that case?

Contributor

kb-light commented Mar 25, 2017

Right the hoodselector sould do it by it selfe.

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.

The SSID should not change by switching a hood.

But each hood has it own IP space, so not changing the SSID may break roaming.

This is a special v6 address to just get datas from directly local nodes via linklocal. This address is fix.

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.

correkt... I have to check this. Please can you send me a link of your site.conf?

An example was added to gluon with adf3b91.

Because more informations wars not necessery.

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.

This is realy practical for use. See https://srv11.ffnw.de/ and enable hood layer. (cert is wrong sorry for that)

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

It should in a special case. To avoid damaging the network.

Is stopping the fastd not enough in that case?

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Mar 30, 2017

Contributor

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

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

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.

Contributor

T-X commented Mar 30, 2017

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

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

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.

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Mar 30, 2017

Contributor

And one more question: Are there any recommendations on how to use this package together with wifi backbone setups?

Contributor

T-X commented Mar 30, 2017

And one more question: Are there any recommendations on how to use this package together with wifi backbone setups?

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata May 9, 2017

Contributor

@T-X sorry I didnt saw the Mail.

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?

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):
The mesh Only Routers try surrounded BSSIDs sort by signal quallity if a Mesh Only Router find batman gateways the the Mesh only will stay there.

Scenario B):
The If the VPN connection ist lost the routers will handle same like Senario A) and C). If the VPN connection comes up all routers except , C and the between E,C and D will stay in the other hoods.
D and the routers behind D goes back into Q2

Scenario C):
Same like A) chosing one of the router depending on Link quality and stay there.

In Freifunk Nordwest we defined the hoods that hood borders will not across a city.
On that point we need more work. The hoodselector automated many scenarios but needs in some cases still work.

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.

Contributor

2tata commented May 9, 2017

@T-X sorry I didnt saw the Mail.

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?

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):
The mesh Only Routers try surrounded BSSIDs sort by signal quallity if a Mesh Only Router find batman gateways the the Mesh only will stay there.

Scenario B):
The If the VPN connection ist lost the routers will handle same like Senario A) and C). If the VPN connection comes up all routers except , C and the between E,C and D will stay in the other hoods.
D and the routers behind D goes back into Q2

Scenario C):
Same like A) chosing one of the router depending on Link quality and stay there.

In Freifunk Nordwest we defined the hoods that hood borders will not across a city.
On that point we need more work. The hoodselector automated many scenarios but needs in some cases still work.

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

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata May 9, 2017

Contributor

@T-X sorry I didnt saw the Mail.

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?

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):
The mesh Only Routers try surrounded BSSIDs sort by signal quallity if a Mesh Only Router find batman gateways the the Mesh only will stay there.

Scenario B):
The If the VPN connection ist lost the routers will handle same like Senario A) and C). If the VPN connection comes up all routers except , C and the between E,C and D will stay in the other hoods.
D and the routers behind D goes back into Q2

Scenario C):
Same like A) chosing one of the router depending on Link quality and stay there.

In Freifunk Nordwest we defined the hoods that hood borders will not across a city.
On that point we need more work. The hoodselector automated many scenarios but needs in some cases still work.

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.

Contributor

2tata commented May 9, 2017

@T-X sorry I didnt saw the Mail.

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?

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):
The mesh Only Routers try surrounded BSSIDs sort by signal quallity if a Mesh Only Router find batman gateways the the Mesh only will stay there.

Scenario B):
The If the VPN connection ist lost the routers will handle same like Senario A) and C). If the VPN connection comes up all routers except , C and the between E,C and D will stay in the other hoods.
D and the routers behind D goes back into Q2

Scenario C):
Same like A) chosing one of the router depending on Link quality and stay there.

In Freifunk Nordwest we defined the hoods that hood borders will not across a city.
On that point we need more work. The hoodselector automated many scenarios but needs in some cases still work.

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

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata May 9, 2017

Contributor

hoodselector
Here is a new state diagram.
Some known issues can be found here:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues?label_name%5B%5D=hoodselector

Contributor

2tata commented May 9, 2017

hoodselector
Here is a new state diagram.
Some known issues can be found here:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues?label_name%5B%5D=hoodselector

@lemoer

This comment has been minimized.

Show comment
Hide comment
@lemoer

lemoer Aug 25, 2017

Contributor

@2tata Are there any simplifications in the mechanism since vxlan is supported?

Contributor

lemoer commented Aug 25, 2017

@2tata Are there any simplifications in the mechanism since vxlan is supported?

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Sep 4, 2017

Contributor
Contributor

2tata commented Sep 4, 2017

@lemoer

This comment has been minimized.

Show comment
Hide comment
@lemoer

lemoer Sep 4, 2017

Contributor

@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.
  • 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.
Contributor

lemoer commented Sep 4, 2017

@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.
  • 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.
@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Sep 7, 2017

Contributor
Contributor

2tata commented Sep 7, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Sep 18, 2017

Contributor

This MR can be close.
@lemoer, @Adorfer, @mweinelt, @kb-light, @T-X: Please take a look at #1226. If you have some comments still open here please take them to the new merge request. :)

Contributor

2tata commented Sep 18, 2017

This MR can be close.
@lemoer, @Adorfer, @mweinelt, @kb-light, @T-X: Please take a look at #1226. If you have some comments still open here please take them to the new merge request. :)

@rotanid rotanid closed this Sep 18, 2017

@rotanid rotanid deleted the hoodselector branch Jan 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment