On Sun, Sep 25, 2016 at 02:26:24AM +0200, Jan-Tarek Butt wrote:
Hi,
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[0].
His Jan-Tarek,
Nice work so far! Is there some additional information regarding the hoodselector available somewhere? Ideally with some pretty flow chart(s) :-).
Next to the implementation specific issues you listed in [0], are there any known, conceptual limitations documented somewhere?
I'm having the feeling that conceptually a hoodselector might run into issues similar to the ones that prevented DFS (dynamic frequency selection) for 802.11s/IBSS so far. Especially when geocordinates are not reliablly available (e.g. one of the node owners configured bogus geocordinates, a router with geocordinates not in reliable range, timing issues?).
I would be very interested in hearing about your discussions concerning potential merging/converging issues and the solutions you came up with.
Regards, Linus