Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add pkg gluon-geolocator from google summer of code 2017 #1201
This package makes able to receive positions base on surrounding WIFIs.
the geolocator program takes surrounding BSSIDs and send this to the openwifi project.
Following site.conf parameters a definable for community's:
Here an example site.conf part:
This package is over a year tested in the Nordwest Freifunk network.
This is one of 4 other packages there should follow in the next few weeks.
This pkg contains only the geolocator. The admin interface comes in the 3 other above mentioned pkgs.
As well users have to be enable the service by setting auto_location  otherwise the geolocator will be disabled.
referenced this pull request
Aug 20, 2017
referenced this pull request
Dec 21, 2017
Btw, is the quality of the openwifi.su data high enough so that the geolocator package will return even marginally useful data? I just tested this with a node in Leipzig, and I got a location in Braunschweig (the scan returned 46 BSSIDs on 2.4GHz, so there should be sufficient data to avoid getting the location that wrong?)
Anyways, I've just pushed the first part of my rework (which has turned out to be mostly a rewrite...) as freifunk-gluon/packages@53a659a, a reusable Lua library for geolocation. In addition to code cleanup, I changed the following:
You need to add the mesh BSSIDs to the blacklist as i wrote above. The openwifi.su backend needs atleast one known WiFi network in the database. For places where nearly no wifi is known in the database, you can just use the openWLANmap wardriving App for Android . The wardriving App will may replace in the coming months because this is in the GSoC18 as a Project for Freifunk. I started work on a new backend witch will also use Mozilla Location service in addition to the own database. This was my last Google Summer of Code project last year. I just got the idea if I change the the request url to a siteconf variable local communitis without v6 can use my GSoC17 project as a MLS proxy . So I will make the request url variable.
I explicitly change it from a C-Lib into the geolocator corn to avoid airtime wasting by multiple access on scanning. For example before the geolocator, the hoodselector and an autolocator (witch place the location in the uci config) where using the C-Lib that means scanns twice for the same result. The geolocator includes the idea to update location position in an intervall where other programs can access. So maybe we should keep the lib out to force using the uci interface.
ubus was also my plan but I drop this idea while I was discussing with people from the Mozilla Location Service project and Zeeshan Ali who already develop a software calls gps-share to provide positions via ubus by using GPS HW in the background.
Okay, after blacklisting the FFHL IBSS cell ID I get 0 results now (why is the FFHL IBSS located in Braunschweig though...?). I think I will just change it to ignore all non-AP WLANs, there should be no need to blacklist anything by default then.
Did you even look at my commit? I built a small Lua library from the code of this PR, it has nothing to do with a C library.
I only use ubus to get the interface list from netifd, instead of getting them from /etc/config/wireless via UCI.
I have a few more ideas regarding this PR. WIll probably replace my Lua library again with one implementing the standard GLS API provided by Google and Mozilla (I assume I will implement it in C, to be able to HTTP POST). To use openwifi.su, they would need to provide a GLS endpoint (or a simple proxy would need to be written); I don't really want to support their non-standard API after all.
Furthermore, I'm unsure about what to do with the determined locations. Your PR currently writes it to the flash, which is not acceptable. I think it would be a nice solution to use a UCI state file in /var/state for it, so the results are only kept in RAM (a command to explicitly commit this state to flash can still be provided).
Because some ware has use the ffhl IBSS cell ID there or just setup a FFHL router and its Cell ID got catch by the war driving app.
Ah yes this is a better idea. The new war driving app, which is planed as a GSoC18 project, should also ignore non-AP WLANs and even mobile hotspots.
I think you miss understood me. I look at your commit and you created a lua lib witch can be called from other lua programs. Above I explained that each program witch use your lib will also call a wifi scan witch will waist airtime, in case if more than one program will request its position in an interval. This problem was happens before the geolocator exists by using a C-lib witch did a similar work like your lua lib on our FFNW routers. That is why I developed the geolocator and why I use the uci interface for providing actual coordinates. I think you lib is not a good way because of the airtime issue or do you think this is not relevant?
Ah pardon, it was late yesterday ;)
The problem by the GLS services by google was form me it is not opensource and I think you will need a API key
The key request was also a problem for GLS service by Mozilla
Both above projects did only provide HTTPS request witch means we have to put SSL on gluon. (The main reason why I didn´t use MLS)
Yes I was also not sure about that. Another Idea which I got was to write a position only for once into the flash and refresh this position only if a tolerance value is overreach. Holding a position only in the RAM is not really optimal on reboots for programs for example the hoodselector. Because that can mean in the worse case the hoodselector will change its hood 2 times after reboot. But at this point I am also not sure..
The library is just code refactoring. There will be only a single program using the library in Gluon.
Regarding the HTTPS issue: I'm not sure how to proceed here. The reasoning of Mozilla etc. not to support HTTP makes sense; for privacy reasons the scan data should not be sent over unencrypted channels.
I am also not sure if MLS provides v6 as you probably read in the IRC
regarding to the privacy reasons, but what about all the respondd datas from gluon there available over public v6 ?
But I dont like MLS that much... they keep all data closed and even for the service you need to ask them for a API key and you have to explain them why do you need it. I didint got a Key when I have told them I have build an MLS SSL Proxy... So I have not so good experience with there service.