Add 3 new pkgs for gluon-config-mode-geo-location from google summer of code 2017

[2tata]

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

[2tata]

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]

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

[T-X]

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]

"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]

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]

Hi T-X,

On 12/03/17 02:13, T-X wrote: "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?

When I wrote this MR I didn't got any problems by loading the inline map in my browser using the wifi internet connection of my laptop while the gluon router was on my ETH port. I am not sure if gluon had announced a default root at that moment. I have to check that on a newer build. For example. If my Laptop not connected to the internet and just have a connection to a gluon router in configMode. Seen and it will look like the actual configMode (without map). cheers Tarek

…

-- # Home tarek@ring0.de # Freifunk Nordwest <tarek@ffnw.de> # GnuPG: # Ich nehme verschlüsselte Mails entgegen. # Fingerprint: 57C0 5D95 DBB0 8A60 159D D114 D41F 2089 1E7A 91C2 # Download Key: http://pgp.mit.edu/pks/lookup?op=get&search=0x1E7A91C2 # Anleitung zur Mailverschlüsselung: http://bit.ly/1e3g2yF

[2tata]

Hi T-X,

On 12/03/17 02:01, T-X wrote: Hi @2tata, great work again! Looking forward to this feature.

Thanks :)

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?

I think that is not possible, because of the dependency cycle. The pkg gluon-config-mode-geo-location-with-geloc is in conflict with gluon-config-mode-geo-location-with-map and gluon-config-mode-geo-location-with-geloc-map and gluon-config-mode-geo-location. gluon-config-mode-geo-location-with-map is in conflict with gluon-config-mode-geo-location-with-geloc and gluon-config-mode-geo-location-with-geloc-map and gluon-config-mode-geo-location. and so on. If a gluon build selected gluon-config-mode-geo-location-with-map on compilation time, but later one a user/administrator would like to try installing gluon-config-mode-geo-location-with-geloc-map via opkg. It should hold the user/admin besause of a pkg conflict.

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 chose geloc as a short for geolocator (which is the another pkg see MR #1201). I am not sure about *-auto, but for me the name doesn't matter. If more people would like to have *-auto instead of geloc, than I can change it.

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?

I would like to give the user the option. 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. Comunitys are able to set their own default value via site.conf. You are also able to set if you what the autolocation mode enabled by default or not. see: https://github.com/freifunk-gluon/gluon/pull/1201/files#diff-c9f94706e139ee245326e9750b23d4c6

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.

The configMode is not necessary for the geolocator. The best is if you see the configMode just as one interface for users their not familiar with shell. As I told above, default modes can be configured via site.conf and everything is also configurable via uci. cheers Tarek

[2tata]

Hi Adorfer,

On 12/03/17 04:11, Adorfer wrote: what happens if there is no default route announced 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, without announcing a route (off course). Then this would not disturb the existing V6/v4-Routes of the client-PC during setup.

The JS inline will be loaded by the Clients Browser and use the browser more or less as a proxy. Means the JS use the clients internet connection via Wifi to load the map and formward the lat/long values localy to the gluon Router. This map can be use for the status page as well. cheers Tarek

[T-X]

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]

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]

@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]

On 12/04/17 07:07, T-X wrote: > 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?

In our community we would like to give the users this options. If this option disturbs you so much. I can implement a disable option like the altitude flag? cheers Tarek

[2tata]

On 12/04/17 07:13, T-X wrote: 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?

This, is to set a fix Position for the router which will not change by the autolocation service. But the autolocation service will run for the defined interval. To send the surrounding WiFis of the router to the openwifi project this helps the project to find unknown WiFis and bind coordinates on them depending on known WiFis. cheers Tarek

[Adorfer]

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]

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]

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

[rotanid]

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]

On 07/25/18 03:02, Andreas Ziegler wrote: 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....

hm, yes maybe. I was not closing this MR for tracing reason. Same like the hoodselector MR.

[rubo77]

in ffnw I found this settings in site.mk:

GLUON_FEATURES += \
	geolocator \
	hoodselector

GLUON_SITE_PACKAGES += \
	-gluon-config-mode-geo-location \
	gluon-config-mode-geo-location-with-geloc-map \

and those gluon patches: https://github.com/Freifunk-Cuxhaven/site-ffcux-nw/tree/master/gluon_patches

What about this PR now? since OSM is in the standard packages (gluon-config-mode-geo-location-osm and gluon-config-mode-geo-location), is this still working?

[rotanid]

heyho! something similar to "gluon-config-mode-geo-location-with-map" was already implemented.
please open separate PRs (if there arent any yet) for other features, but try to keep PRs as small as possible.
therefore i'm closing this after consulting with @mweinelt

EDIT: the already integrated part is called geo-location-osm

[2tata]

Yes, I had split up the map from this PR. I'll do a new PR with the rest of changes.