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

Add pkg gluon-geolocator from google summer of code 2017 #1201

Open
wants to merge 35 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@2tata
Contributor

2tata commented Aug 4, 2017

This package makes able to receive positions base on surrounding WIFIs.

the geolocator program takes surrounding BSSIDs and send this to the openwifi project.
As an answer the router will get a position base on the above sent BSSIDs. This will be done
in a defined interval, which can be set by site.conf or by configMode.

Following site.conf parameters a definable for community's:

  • autolocation enable flag. Can be 1 or 0 means enabled or disabled. Default is disabled.
  • interval in minutes, means how often should the geolocator refresh its position. Default is every 12 hours.

Here an example site.conf part:

geolocator = {
                autolocation = true,
                interval = 1000,
             },

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.
2 of the other packages are responsible for the configuration over the configMode.
https://blog.freifunk.net/2017/07/26/geolocator-software-defined-gps-second-evaluation/

@rubo77

This comment has been minimized.

Show comment
Hide comment
@rubo77

rubo77 Aug 6, 2017

Contributor

Is it possible for the user to select, that he/she doesn't want to be discovered?

Can you add some screenshots of the admin interface?

Contributor

rubo77 commented Aug 6, 2017

Is it possible for the user to select, that he/she doesn't want to be discovered?

Can you add some screenshots of the admin interface?

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Aug 6, 2017

Contributor

This pkg contains only the geolocator. The admin interface comes in the 3 other above mentioned pkgs.
Users can set share_location [0] to discover there positions.

As well users have to be enable the service by setting auto_location [1] otherwise the geolocator will be disabled.

[0] https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-node-info/files/etc/config/gluon-node-info
[1] https://github.com/freifunk-gluon/gluon/pull/1201/files#diff-ca9821c5dfe71d5edd884409cceef57bR30

Contributor

2tata commented Aug 6, 2017

This pkg contains only the geolocator. The admin interface comes in the 3 other above mentioned pkgs.
Users can set share_location [0] to discover there positions.

As well users have to be enable the service by setting auto_location [1] otherwise the geolocator will be disabled.

[0] https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-node-info/files/etc/config/gluon-node-info
[1] https://github.com/freifunk-gluon/gluon/pull/1201/files#diff-ca9821c5dfe71d5edd884409cceef57bR30

Show outdated Hide outdated package/gluon-geolocator/check_site.lua
Show outdated Hide outdated package/gluon-geolocator/files/lib/gluon/geolocator/geolocator.sh
Show outdated Hide outdated package/gluon-geolocator/files/usr/lib/micron.d/geolocator
@@ -0,0 +1,33 @@
#!/usr/bin/lua
local site = require 'gluon.site'

This comment has been minimized.

@NeoRaider

NeoRaider Aug 12, 2017

Member

You switched to the new gluon.site library, but didn't adjust the rest of the code accordingly... see other comments below.

@NeoRaider

NeoRaider Aug 12, 2017

Member

You switched to the new gluon.site library, but didn't adjust the rest of the code accordingly... see other comments below.

This comment has been minimized.

@2tata

2tata Aug 16, 2017

Contributor

done in 1acc557

@2tata

2tata Aug 16, 2017

Contributor

done in 1acc557

Show outdated Hide outdated package/gluon-geolocator/luasrc/lib/gluon/upgrade/540-geolocator-settings
Show outdated Hide outdated package/gluon-geolocator/luasrc/lib/gluon/upgrade/540-geolocator-settings
Show outdated Hide outdated package/gluon-geolocator/luasrc/lib/gluon/upgrade/540-geolocator-settings
Show outdated Hide outdated package/gluon-geolocator/check_site.lua
@rubo77

This comment has been minimized.

Show comment
Hide comment
@rubo77

rubo77 Aug 21, 2017

Contributor

Why is the text below the dropdown with such a big padding?

Contributor

rubo77 commented Aug 21, 2017

Why is the text below the dropdown with such a big padding?

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Aug 22, 2017

Contributor
Contributor

2tata commented Aug 22, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Sep 3, 2017

Contributor

@NeoRaider now every requested changes should be done. :-)

Contributor

2tata commented Sep 3, 2017

@NeoRaider now every requested changes should be done. :-)

@2tata 2tata referenced this pull request Sep 4, 2017

Closed

Hoodselector #997

@rotanid rotanid requested a review from NeoRaider Feb 15, 2018

@rotanid

This comment has been minimized.

Show comment
Hide comment
@rotanid

rotanid Feb 15, 2018

Member

status update from dev meeting:

  • needs rebase for check_site
  • awaiting review
Member

rotanid commented Feb 15, 2018

status update from dev meeting:

  • needs rebase for check_site
  • awaiting review
@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Feb 26, 2018

Member

I have started some code cleanup, unfortunately I can't test it at the moment, as http://openwifi.su/api/v1/bssids/... only returns "502 Bad Gateway"...

Edit: It's back online, I'll try to get this finished today.

Member

NeoRaider commented Feb 26, 2018

I have started some code cleanup, unfortunately I can't test it at the moment, as http://openwifi.su/api/v1/bssids/... only returns "502 Bad Gateway"...

Edit: It's back online, I'll try to get this finished today.

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Feb 27, 2018

Member

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:

  • use ubus to get the interface list from netifd instead of using UCI (nicer interface, and we don't depend on the optional ifname UCI option)
  • only query one interface per radio
Member

NeoRaider commented Feb 27, 2018

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:

  • use ubus to get the interface list from netifd instead of using UCI (nicer interface, and we don't depend on the optional ifname UCI option)
  • only query one interface per radio
@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Feb 28, 2018

Contributor

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

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 [0]. 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 [1]. So I will make the request url variable.

[0] http://openwifi.su/owlmapatandroid.php?lang=en
[1] https://github.com/openwifi-su/sgps-core

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

I changed the following:

use ubus to get the interface list from netifd instead of using UCI (nicer interface, and we don't depend on the optional ifname UCI option)

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.

Contributor

2tata commented Feb 28, 2018

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

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 [0]. 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 [1]. So I will make the request url variable.

[0] http://openwifi.su/owlmapatandroid.php?lang=en
[1] https://github.com/openwifi-su/sgps-core

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

I changed the following:

use ubus to get the interface list from netifd instead of using UCI (nicer interface, and we don't depend on the optional ifname UCI option)

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.

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Feb 28, 2018

Member

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

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.

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.

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.

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.

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.

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

Member

NeoRaider commented Feb 28, 2018

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

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.

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.

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.

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.

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.

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

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Mar 1, 2018

Contributor

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

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.

Okay, after blacklisting the FFHL IBSS cell ID I get 0 results now (why is the FFHL IBSS located in Braunschweig though...?).

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.

I think I will just change it to ignore all non-AP WLANs, there should be no need to blacklist anything by default then.

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

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

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.

I only use ubus to get the interface list from netifd, instead of getting them from /etc/config/wireless via UCI.

Ah pardon, it was late yesterday ;)

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.

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)

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

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

Contributor

2tata commented Mar 1, 2018

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

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.

Okay, after blacklisting the FFHL IBSS cell ID I get 0 results now (why is the FFHL IBSS located in Braunschweig though...?).

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.

I think I will just change it to ignore all non-AP WLANs, there should be no need to blacklist anything by default then.

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

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

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.

I only use ubus to get the interface list from netifd, instead of getting them from /etc/config/wireless via UCI.

Ah pardon, it was late yesterday ;)

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.

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)

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

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

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Mar 1, 2018

Member

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?

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.

Member

NeoRaider commented Mar 1, 2018

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?

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.

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Mar 1, 2018

Contributor

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?

The library is just code refactoring. There will be only a single program using the library in Gluon.

Ah ok.

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 ?

like:
http://[fd74:fdaa:9dc4:6800:12fe:edff:fe7b:2836]/cgi-bin/interfaces
http://[2a03:2260:1001:6800:12fe:edff:fe7b:2836]/cgi-bin/nodeinfo
etc. ?

Contributor

2tata commented Mar 1, 2018

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?

The library is just code refactoring. There will be only a single program using the library in Gluon.

Ah ok.

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 ?

like:
http://[fd74:fdaa:9dc4:6800:12fe:edff:fe7b:2836]/cgi-bin/interfaces
http://[2a03:2260:1001:6800:12fe:edff:fe7b:2836]/cgi-bin/nodeinfo
etc. ?

2tata added some commits Aug 4, 2017

gluon-geolocator: change lua require
540-geolocator-settings: change lua require 'gluon.site_config' to 'gluon.site'
gluon-geolocator: clean up cron file
 * rm unneded semicolon
 * remove the sh
gluon-geolocator: use taps and chang val type in check_site.lua
 * set geolocator.autolocation as need_boolean
 * replace spaces with taps
gluon-geolocator: refactoring and spellcheck
 * rm irrelevant else states
 * fix print message for time stamp file
gluon-geolocator: fix intervall in 540-geolocator-settings
 * change intervall value from seconds to minutes
gluon-geolocator: update to master package configuration
* drop bssid blacklist
* only allow Master mode scanned wifis for osition request.
@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Jul 16, 2018

Contributor

@NeoRaider I have change the geolocator to only request with Master mode driven scanned devices.
And I applyed your ubus request. Still the question how to handle the flash writing issue..

Contributor

2tata commented Jul 16, 2018

@NeoRaider I have change the geolocator to only request with Master mode driven scanned devices.
And I applyed your ubus request. Still the question how to handle the flash writing issue..

@rubo77

This comment has been minimized.

Show comment
Hide comment
@rubo77

rubo77 Jul 16, 2018

Contributor

You could Set-up a Proxy service somewhere that accepts HTTP requests and Redirects them to https requests to the Mozilla Service.

The requests to that self created service should use some other kind of encryption though.

Contributor

rubo77 commented Jul 16, 2018

You could Set-up a Proxy service somewhere that accepts HTTP requests and Redirects them to https requests to the Mozilla Service.

The requests to that self created service should use some other kind of encryption though.

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Jul 16, 2018

Contributor

@rubo77 MLS has no v6

Contributor

2tata commented Jul 16, 2018

@rubo77 MLS has no v6

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Jul 17, 2018

Contributor

https://github.com/openwifi-su/sgps-core
An another project of my is already an MLS proxy. But without security.

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.

Contributor

2tata commented Jul 17, 2018

https://github.com/openwifi-su/sgps-core
An another project of my is already an MLS proxy. But without security.

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.

@rotanid rotanid added the needs rebase label Sep 2, 2018

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