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 3 new pkgs for gluon-config-mode-geo-location from google summer of code 2017 #1211

Open
wants to merge 24 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@2tata
Contributor

2tata commented Aug 20, 2017

This MR integrates 3 other packages into gluon-config-mode-geo-location for difference features in configMode. Community's are able to select features by adding packages to the site.mk. If a Community would like to stay by the old geo-location web-interface just leave gluon-config-mode-geo-location in the site.mk. All other following packages will include the manual setting of geo-location from gluon-config-mode-geo-location. Each of the packages will be generated on compile time.

  • gluon-config-mode-geo-location-with-geloc includes the gluon-geolocator options into the dropdown menu, so it will makes able that a router can refresh automatically its geo-position base on given surrounding wifis.

  • gluon-config-mode-geo-location-with-map loads a js inline map on client site to pick a nodes position if the PC that does the configuration, has an internet connection. If the PC which do the configuration is not connected to the internet and just have a connection to a gluon router in configMode. It will look like the actual configMode without map.

  • The pkg gluon-config-mode-geo-location-with-geloc-map simply add both features above.
    See Pictures below.

If the gluon-geolocator enabled by default via site conf the selected drop down item will be "automatic (geolocator)".

site.conf Parameters:

  • olurl set individual osm layer url. Default is http://dev.openlayers.org/OpenLayers.js
  • map_lon set longitude for default map center. Default is 0.0
  • map_lat set latitude for default map center. Default is 0.0

Example site.conf:

config_mode = {
                geo_location = {
                        map_lon = 52.951947558,
                        map_lat = 7.844238281,
                        olurl = 'http://osm.ffnw.de/.static/ol/OpenLayers.js'
                        show_altitude = true,
                },
        },

More detailed information can be found on the blog post from the last evaluation:
https://blog.freifunk.net/2017/07/26/geolocator-software-defined-gps-second-evaluation/

This merge request depends on #1201
This merge request includes #58

screenshot_2017-08-20_14-22-33
screenshot_2017-08-20_14-23-09
screenshot_2017-08-20_14-23-32
screenshot_2017-08-20_14-23-56

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

Closed

Hoodselector #997

@rotanid rotanid added the enhancement label Sep 7, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Sep 9, 2017

Contributor

Now the hole packages should generated on compile time.
Currently the package will not build and I don't get any error logs. It will simply deselect before building... I don't know why.

So I am still on debugging. :)

Contributor

2tata commented Sep 9, 2017

Now the hole packages should generated on compile time.
Currently the package will not build and I don't get any error logs. It will simply deselect before building... I don't know why.

So I am still on debugging. :)

@2tata 2tata changed the title from [WIP] Add 3 new pkgs for gluon-config-mode-geo-location from google summer of code 2017 to Add 3 new pkgs for gluon-config-mode-geo-location from google summer of code 2017 Sep 12, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Sep 12, 2017

Contributor

Now this MR is done by my site. Waiting for reviews :-)

Contributor

2tata commented Sep 12, 2017

Now this MR is done by my site. Waiting for reviews :-)

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Dec 3, 2017

Contributor

Hi @2tata, great work again! Looking forward to this feature.

A few suggestions: I think the package naming is a little confusing. From a user/admin perspective I would have expected that simply installing gluon-config-mode-geo-location-with-geloc and gluon-config-mode-geo-location-with-map should do the same as gluon-config-mode-geo-location-with-geloc-map. Could we get rid of the latter? Also gluon-config-mode-geo-location-with-geloc is a confusing name. "geloc" does not seem to describe what this might add. What do you think about naming things like: gluon-config-mode-location-auto and gluon-config-mode-location-map?

I think "Interval in minutes" can be removed, too. I think you as the author can set an interval you think makes sense for a static setup, our default case. Maybe make it configurable via UCI though.

I've also been wondering about which mode should be the suggested/default one. Maybe controversial, but I think as we are developing a public network and wifi beacons are public anyway, maybe make the auto mode the default (if the according package is installed)?

We might also want to discuss whether geo location should be disabled or auto in case of "setup_mode = { skip = true, }" in the site.conf. I would opt for auto, because I think it would be a desirable goal to make the config mode optional not just for developers but also for users in general. That is it would be nice if after flashing a node would just work for everybody.

Contributor

T-X commented Dec 3, 2017

Hi @2tata, great work again! Looking forward to this feature.

A few suggestions: I think the package naming is a little confusing. From a user/admin perspective I would have expected that simply installing gluon-config-mode-geo-location-with-geloc and gluon-config-mode-geo-location-with-map should do the same as gluon-config-mode-geo-location-with-geloc-map. Could we get rid of the latter? Also gluon-config-mode-geo-location-with-geloc is a confusing name. "geloc" does not seem to describe what this might add. What do you think about naming things like: gluon-config-mode-location-auto and gluon-config-mode-location-map?

I think "Interval in minutes" can be removed, too. I think you as the author can set an interval you think makes sense for a static setup, our default case. Maybe make it configurable via UCI though.

I've also been wondering about which mode should be the suggested/default one. Maybe controversial, but I think as we are developing a public network and wifi beacons are public anyway, maybe make the auto mode the default (if the according package is installed)?

We might also want to discuss whether geo location should be disabled or auto in case of "setup_mode = { skip = true, }" in the site.conf. I would opt for auto, because I think it would be a desirable goal to make the config mode optional not just for developers but also for users in general. That is it would be nice if after flashing a node would just work for everybody.

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Dec 3, 2017

Contributor

"gluon-config-mode-geo-location-with-map loads a js inline map to pick a nodes position if the PC that does the configuration, has an internet connection."

The tricky thing is that right now, a PC gets a default route from the node and an 192.168.1.x address. However, at the moment the default route is not usable, afaik. Maybe we could change the firewall settings in Gluon to allow forwarding between the LAN and WAN ports during config-mode?

Contributor

T-X commented Dec 3, 2017

"gluon-config-mode-geo-location-with-map loads a js inline map to pick a nodes position if the PC that does the configuration, has an internet connection."

The tricky thing is that right now, a PC gets a default route from the node and an 192.168.1.x address. However, at the moment the default route is not usable, afaik. Maybe we could change the firewall settings in Gluon to allow forwarding between the LAN and WAN ports during config-mode?

@Adorfer

This comment has been minimized.

Show comment
Hide comment
@Adorfer

Adorfer Dec 3, 2017

Contributor

what happens if there is no default route announced by the dnsmasq dhcp from gluon-setup?
will a (typical) windows/mac then still use the default route coming from Wifi?

Alternativly: Make the config-mode spin ONLY on IPv6 (on an fd-prefix), without announcing a route (off course).
Then this would not disturb the existing V6/v4-Routes of the client-PC during setup.

Contributor

Adorfer commented Dec 3, 2017

what happens if there is no default route announced by the dnsmasq dhcp from gluon-setup?
will a (typical) windows/mac then still use the default route coming from Wifi?

Alternativly: Make the config-mode spin ONLY on IPv6 (on an fd-prefix), without announcing a route (off course).
Then this would not disturb the existing V6/v4-Routes of the client-PC during setup.

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Dec 3, 2017

Contributor
Contributor

2tata commented Dec 3, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Dec 3, 2017

Contributor
Contributor

2tata commented Dec 3, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Dec 3, 2017

Contributor
Contributor

2tata commented Dec 3, 2017

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Dec 4, 2017

Contributor

Because If you have a highly mobile routers like an mr3020 on your bicycle, you can change the Interval easily to 1 min or something else.

I think such mobility is unfortunately not supported yet. You'd have to change originator values, too, which is currently only supported via site.conf or UCI, too.

Let's keep it simple for a start, I'd say. Just set it to 10min. or 15min. maybe?

Contributor

T-X commented Dec 4, 2017

Because If you have a highly mobile routers like an mr3020 on your bicycle, you can change the Interval easily to 1 min or something else.

I think such mobility is unfortunately not supported yet. You'd have to change originator values, too, which is currently only supported via site.conf or UCI, too.

Let's keep it simple for a start, I'd say. Just set it to 10min. or 15min. maybe?

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Dec 4, 2017

Contributor

Regarding packages, maybe I'm misunderstanding something, too. What is the use of the option "Geo-Location: Automatic & Static". Why/when would I need both?

Contributor

T-X commented Dec 4, 2017

Regarding packages, maybe I'm misunderstanding something, too. What is the use of the option "Geo-Location: Automatic & Static". Why/when would I need both?

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Dec 4, 2017

Contributor

@Adorfer:

what happens if there is no default route announced by the dnsmasq dhcp from gluon-setup?

I'm not aware of an option to achieve this with IPv4 DHCP. Afaik, you automatically, always get a default route for the IP+subnet you received.

Alternativly: Make the config-mode spin ONLY on IPv6 (on an fd-prefix), without announcing a route (off course).

While only announcing a prefix, but without a default route is possible for IPv6 router advertisements by setting the router lifetime to 0, I see two issues:

A) People won't want to enter IPv6 addresses into their browser to reach the config mode. They are used to use 192.168.1.1 or 192.168.2.1 to configure their router.

B) I'm afraid many OSes by default will deconfigure and ignore the interface if they do not receive an IPv4 address plus default route on it.

Contributor

T-X commented Dec 4, 2017

@Adorfer:

what happens if there is no default route announced by the dnsmasq dhcp from gluon-setup?

I'm not aware of an option to achieve this with IPv4 DHCP. Afaik, you automatically, always get a default route for the IP+subnet you received.

Alternativly: Make the config-mode spin ONLY on IPv6 (on an fd-prefix), without announcing a route (off course).

While only announcing a prefix, but without a default route is possible for IPv6 router advertisements by setting the router lifetime to 0, I see two issues:

A) People won't want to enter IPv6 addresses into their browser to reach the config mode. They are used to use 192.168.1.1 or 192.168.2.1 to configure their router.

B) I'm afraid many OSes by default will deconfigure and ignore the interface if they do not receive an IPv4 address plus default route on it.

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Dec 4, 2017

Contributor
Contributor

2tata commented Dec 4, 2017

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Dec 4, 2017

Contributor
Contributor

2tata commented Dec 4, 2017

@Adorfer

This comment has been minimized.

Show comment
Hide comment
@Adorfer

Adorfer Dec 4, 2017

Contributor

A) People won't want to enter IPv6 addresses into their browser to reach the config mode. They are used to use 192.168.1.1 or 192.168.2.1 to configure their router.

B) I'm afraid many OSes by default will deconfigure and ignore the interface if they do not receive an IPv4 address plus default route on it.

b) Interfaces with ULA-prefixes should be exempt from "non-usage" due to missing ipv4. But perhaps some kind of broken OS are affect from that. Do we have examples?

a) we could make the adress real easy like http://[fd00::fd00]
or even put up an rdnss and resolv a "config.freifunk" to that ipv6. (off course... risky game, i don't like personally.)

Contributor

Adorfer commented Dec 4, 2017

A) People won't want to enter IPv6 addresses into their browser to reach the config mode. They are used to use 192.168.1.1 or 192.168.2.1 to configure their router.

B) I'm afraid many OSes by default will deconfigure and ignore the interface if they do not receive an IPv4 address plus default route on it.

b) Interfaces with ULA-prefixes should be exempt from "non-usage" due to missing ipv4. But perhaps some kind of broken OS are affect from that. Do we have examples?

a) we could make the adress real easy like http://[fd00::fd00]
or even put up an rdnss and resolv a "config.freifunk" to that ipv6. (off course... risky game, i don't like personally.)

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Dec 5, 2017

Contributor

Ok, I think I learned something new about DHCP yesterday :-). I checked with a laptop connected to a Gluon router in config mode and indeed I only get an IPv4 address and an according route for the subnet - but no default route.

Comparing a DHCP handshake from a home router with the one in config mode via Wireshark it seems that the missing DHCP router option during config-mode prevents a default route being installed.

So looks like we are good, no firewall changes needed :-). I tested with a Ubuntu and its Network-Manager and at least there using wifi+cable works just as we need it to (don't have any Windows or Mac to test here). Sorry for the confusion.

Contributor

T-X commented Dec 5, 2017

Ok, I think I learned something new about DHCP yesterday :-). I checked with a laptop connected to a Gluon router in config mode and indeed I only get an IPv4 address and an according route for the subnet - but no default route.

Comparing a DHCP handshake from a home router with the one in config mode via Wireshark it seems that the missing DHCP router option during config-mode prevents a default route being installed.

So looks like we are good, no firewall changes needed :-). I tested with a Ubuntu and its Network-Manager and at least there using wifi+cable works just as we need it to (don't have any Windows or Mac to test here). Sorry for the confusion.

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Jul 16, 2018

Contributor

I think I will split off the dependence of gluon-geolocator to speed up the integration process.

Contributor

2tata commented Jul 16, 2018

I think I will split off the dependence of gluon-geolocator to speed up the integration process.

@rotanid

This comment has been minimized.

Show comment
Hide comment
@rotanid

rotanid Jul 25, 2018

Member

wouldn't it make more sense to close this PR now and continue discussions in the individual package's PR's ?
if not everything from this PR has a new PR yet, it still doesn't make sense to keep a PR that was originally containing much more....

Member

rotanid commented Jul 25, 2018

wouldn't it make more sense to close this PR now and continue discussions in the individual package's PR's ?
if not everything from this PR has a new PR yet, it still doesn't make sense to keep a PR that was originally containing much more....

@2tata

This comment has been minimized.

Show comment
Hide comment
@2tata

2tata Jul 25, 2018

Contributor
Contributor

2tata commented Jul 25, 2018

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