[PATCH 0/2] iw: add GeoClue support

[PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

This series adds GeoClue support to iw.

A few items we should take into consideration for future
innovation and improvements.

 - The hostip provider should be extended to listen to signals for
   network connetions, and once one becomes availble we can enable
   asynchronous notifications back to the kernel.

 - Extend this to try first the GeoClue gypsy provider, gpsd.

 - Consider writing a GeoClue provider for https://wigle.net/
   which the supplicant can use to inform GeoClue of location.

 - Consider writing our own GeoClue provider based on timezones
   as a last resort.

 - Consider whether or not the kernel may want accuracy
   information as well to make more interesting decisions.

Luis R. Rodriguez (2):
  iw: make is_alpha2() available to other objects
  iw: add GeoClue support for automatically determining location

 COPYING  |    2 +-
 Makefile |    7 +++
 georeg.c |  172 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 iw.h     |    1 +
 reg.c    |    2 +-
 5 files changed, 182 insertions(+), 2 deletions(-)
 create mode 100644 georeg.c

[PATCH 1/2] iw: make is_alpha2() available to other objects

[Luis R. Rodriguez]

This will be used by a new GeoClue based regulatory hint command.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 iw.h  |    1 +
 reg.c |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/iw.h b/iw.h
index c21f093..771a190 100644
--- a/iw.h
+++ b/iw.h
@@ -137,6 +137,7 @@ void print_ssid_escaped(const uint8_t len, const uint8_t *data);
 int nl_get_multicast_id(struct nl_sock *sock, const char *family, const char *group);
 
 char *reg_initiator_to_string(__u8 initiator);
+bool is_alpha2(char *alpha2);
 
 const char *get_reason_str(uint16_t reason);
 const char *get_status_str(uint16_t status);
diff --git a/reg.c b/reg.c
index 7f82e08..bbdc2fc 100644
--- a/reg.c
+++ b/reg.c
@@ -28,7 +28,7 @@ static bool isalpha_upper(char letter)
 	return false;
 }
 
-static bool is_alpha2(char *alpha2)
+bool is_alpha2(char *alpha2)
 {
 	if (isalpha_upper(alpha2[0]) && isalpha_upper(alpha2[1]))
 		return true;
-- 
1.7.0.4

[PATCH 2/2] iw: add GeoClue support for automatically determining location

[Luis R. Rodriguez]

This adds GeoClue support to iw through a new command,
georeg. The command can be used to both query what GeoClue
knows about our location and also to send it to the kernel.

georeg support will only be compiled if you have geoclue
libraries available. The current GeoClue implementation uses
the hostip provider from GeoClue (http://hostip.info).

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 COPYING  |    2 +-
 Makefile |    7 +++
 georeg.c |  172 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 180 insertions(+), 1 deletions(-)
 create mode 100644 georeg.c

diff --git a/COPYING b/COPYING
index 73e19ac..3782eca 100644
--- a/COPYING
+++ b/COPYING
@@ -1,7 +1,7 @@
 Copyright (c) 2007, 2008	Johannes Berg
 Copyright (c) 2007		Andy Lutomirski
 Copyright (c) 2007		Mike Kershaw
-Copyright (c) 2008-2009		Luis R. Rodriguez
+Copyright (c) 2008-2010		Luis R. Rodriguez
 
 Permission to use, copy, modify, and/or distribute this software for any
 purpose with or without fee is hereby granted, provided that the above
diff --git a/Makefile b/Makefile
index bd6ca15..75e105a 100644
--- a/Makefile
+++ b/Makefile
@@ -24,6 +24,13 @@ ALL = iw
 
 NL1FOUND := $(shell $(PKG_CONFIG) --atleast-version=1 libnl-1 && echo Y)
 NL2FOUND := $(shell $(PKG_CONFIG) --atleast-version=2 libnl-2.0 && echo Y)
+GEO_FOUND := $(shell $(PKG_CONFIG) --exists geoclue && echo Y)
+
+ifeq ($(GEO_FOUND),Y)
+OBJS += georeg.o
+LIBS += $(shell $(PKG_CONFIG) --libs geoclue)
+CFLAGS += $(shell $(PKG_CONFIG) --cflags geoclue)
+endif
 
 ifeq ($(NL1FOUND),Y)
 NLLIBNAME = libnl-1
diff --git a/georeg.c b/georeg.c
new file mode 100644
index 0000000..65acf31
--- /dev/null
+++ b/georeg.c
@@ -0,0 +1,172 @@
+/*
+ * Copyright 2010 Luis R. Rodriguez <lrodriguez@atheros.com>
+ *
+ * If your Linux distribution supports GeoClue you can use this
+ * 'iw georeg set' to notify the kernel of your country based
+ * on your Operating System's geolocation hints it can obtain.
+ * Since the hostip provider does not currently provide asynchronous
+ * signals you should first check for network connectvity before
+ * using this.
+ *
+ * To test what GeoClue is using prior to sending to the kernel you
+ * can use 'iw georeg get'.
+ */
+
+#include <net/if.h>
+#include <errno.h>
+#include <string.h>
+#include <stdbool.h>
+
+#include <geoclue/geoclue-address.h>
+
+#include <netlink/genl/genl.h>
+#include <netlink/genl/family.h>
+#include <netlink/genl/ctrl.h>
+#include <netlink/msg.h>
+#include <netlink/attr.h>
+
+#include "nl80211.h"
+#include "iw.h"
+
+SECTION(georeg);
+
+/*
+ * This uses the hostip provider from GeoClue (http://hostip.info).
+ *
+ * TODO:
+ *
+ * - The hostip provider should be extended to listen to signals for
+ *   network connetions, and once one becomes availble we can enable
+ *   asynchronous notifications back to the kernel.
+ *
+ * - Extend this to try first the GeoClue gypsy provider, gpsd.
+ *
+ * - Consider writing a GeoClue provider for https://wigle.net/
+ *   which the supplicant can use to inform GeoClue of location.
+ *
+ * - Consider writing our own GeoClue provider based on timezones
+ *   as a last resort.
+ *
+ * - Consider whether or not the kernel may want accuracy
+ *   information as well to make more interesting decisions.
+ */
+static int get_geoclue_alpha2(char *alpha2)
+{
+	GeoclueAddress *address = NULL;
+	GHashTable *details = NULL;
+	int timestamp;
+	double acc_hor, acc_vert;
+	GError *error = NULL;
+	GeoclueAccuracy *accuracy = NULL;
+	GeoclueAccuracyLevel acc_level;
+	gchar *country;
+	int r = 0;
+
+	g_type_init();
+
+	address = geoclue_address_new("org.freedesktop.Geoclue.Providers.Hostip",
+				      "/org/freedesktop/Geoclue/Providers/Hostip");
+
+	if (!address)
+		return -EINVAL;
+
+        if (!geoclue_address_get_address(address, &timestamp,
+					 &details, &accuracy,
+					 &error)) {
+		g_object_unref(address);
+		return -EINVAL;
+	}
+
+	if (error) {
+		g_printerr("%s\n", error->message);
+		g_error_free(error);
+		g_object_unref(address);
+		return -EINVAL;
+	}
+
+	geoclue_accuracy_get_details(accuracy, &acc_level, &acc_hor, &acc_vert);
+
+	if (acc_level < GEOCLUE_ACCURACY_LEVEL_COUNTRY) {
+		fprintf(stderr, "Accuracy level is not country specific\n");
+		fprintf(stderr, "Hostip does not have a valid location available."
+			"\nVisit http://www.hostip.info/ to correct this");
+		r = -EINVAL;
+		goto out;
+	}
+
+	country = g_hash_table_lookup(details, GEOCLUE_ADDRESS_KEY_COUNTRYCODE);
+	if (!country) {
+		r = -EINVAL;
+		goto out;
+	}
+
+	/* At this point we know we are sure of the country */
+
+	alpha2[0] = country[0];
+	alpha2[1] = country[1];
+	alpha2[2] = '\0';
+
+out:
+	g_hash_table_destroy (details);
+	geoclue_accuracy_free(accuracy);
+	g_object_unref(address);
+
+	return r;
+}
+
+static int handle_geo_reg_set(struct nl80211_state *state,
+			      struct nl_cb *cb,
+			      struct nl_msg *msg,
+			      int argc, char **argv)
+{
+	char alpha2[3];
+	int r;
+
+	r = get_geoclue_alpha2(alpha2);
+	if (r) {
+		fprintf(stderr, "Could not get an alpha2 from GeoClue\n");
+		return -EINVAL;
+	}
+
+	if (!is_alpha2(alpha2)) {
+		fprintf(stderr, "not a valid ISO/IEC 3166-1 alpha2\n");
+		return -EINVAL;
+	}
+
+	printf("GeoClue sent: %c%c\n", alpha2[0], alpha2[1]);
+
+	NLA_PUT_STRING(msg, NL80211_ATTR_REG_ALPHA2, alpha2);
+
+	return 0;
+ nla_put_failure:
+	return -ENOBUFS;
+}
+COMMAND(georeg, set, NULL, NL80211_CMD_SET_REG, 0, CIB_NONE, handle_geo_reg_set,
+        "Use GeoClue to send your location information to the kernel.");
+
+static int handle_geo_reg_get(struct nl80211_state *state,
+			      struct nl_cb *cb,
+			      struct nl_msg *msg,
+			      int argc, char **argv)
+{
+	char alpha2[3];
+	int r;
+
+	r = get_geoclue_alpha2(alpha2);
+	if (r) {
+		fprintf(stderr, "Could not get an alpha2 from GeoClue\n");
+		return -EINVAL;
+	}
+
+	if (!is_alpha2(alpha2)) {
+		fprintf(stderr, "not a valid ISO/IEC 3166-1 alpha2\n");
+		return -EINVAL;
+	}
+
+	fprintf(stdout, "GeoClue: %c%c - Via http://hostip.info\n",
+		alpha2[0], alpha2[1]);
+
+	return 0;
+}
+COMMAND(georeg, get, NULL, 0, 0, CIB_NONE, handle_geo_reg_get,
+        "Use GeoClue to get your location information prior to sending it to the kernel.");
-- 
1.7.0.4

Re: [PATCH 0/2] iw: add GeoClue support

[Johannes Berg]

On Fri, 2010-08-20 at 20:29 -0400, Luis R. Rodriguez wrote:
> This series adds GeoClue support to iw.

Quite frankly, I don't see the point?

What use is a command line tool that has to talk to a whole bunch of
daemons etc.? I could see using say NM to connect it all, or maybe put
it into geoclue directly, but a command line to trigger it all seems
like a wrong approach?

johannes

Re: [PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

On Mon, Aug 23, 2010 at 7:11 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2010-08-20 at 20:29 -0400, Luis R. Rodriguez wrote:
>> This series adds GeoClue support to iw.
>
> Quite frankly, I don't see the point?

To help us move forward to automate location awareness information
into the kernel. I don't think we can unify all possible solutions for
the different distributions out there so best is to make available
whatever utilities we can and allow the distribution implementors to
embrace whatever they want.

I'll explain some more below.

> What use is a command line tool that has to talk to a whole bunch of
> daemons etc.?

The current implementation doesn't talk to deamons. The hostip
provider within GeoClue and it will just trigger a URL get. If
desktops start implementing a master server though then the query
would simply be a cached response.

> I could see using say NM to connect it all,

GeoClue has some initial connectivity support now. It allows your
connectivity managers to provide back things like status of your
connection, your AP's MAC address, router MAC address, and a list of
APs. The last one can be used by Plazes and Skyhook for example.
GeoClue now supports this connection interface with Network Manager
and as of recently for Connman. Technically Connman and Network
Manager then can seed GeoClue with bits of info for providers. For
example I can forsee a GeoClue http://wigle.net provider implemented
where the provider can make use of the existing connection manager
services to query APs and eventually provide clients its location.

So clients are the ones querying GeoClue, and its up to them to
implement support. Network Manager and Connman can add support for
GeoClue by doing a similar query but then the question arises if all
distributions will also be providing a master provider. The GeoClue
master provider caches queries based on all supported and available
providers so that clients do not have to wait for a provider to do its
work on an independent query. If not master provider is installed on a
system, each GeoClue client will have to poke at the respective
provider to do its own work. In the case of the hostip provider a
simple URL query is made and parsed (http://api.hostip.info). For
other providers like gypsy Dbus will be used to get gypsy to do its
thing and give back information. I should also note GeoClue depends on
Glib and Dbus so there are also size considerations embedded
distributions must make if they are not supporting Glib and/or Dbus.

For distributions then the question of the master provider and
overhead library support remains. The iw patch I provide simply
provides an example of how to do this in userspace applications and I
would like to expand on it to use other providers first like Gpysy and
Gpsd until the desktop catches up. This may mean we end up handling
this in wpa_supplicant -- not sure, this would be a good time to
review this or we can also review this at the upcoming summit. For
embedded distributions like openwrt it also provides a sample of what
can be equivalently done, I doubt Glib support will be integrated.

> or maybe put it into geoclue directly,

GeoClue provides clients an API to query geolocation information. Its
up to the different distributions to decide if they want to implement
support for the master provider, which providers they want to handle.
Client software then just queries GeoClue, what we need then is
different userspace clients being capable of querying this information
if GeoClue is supported to send it off to the kernel.

> but a command line to trigger it all seems
> like a wrong approach?

Its an option which can be made available to distributions, right now
we have no other except a set of bash scripts to for example query
timezone and things like that. Piggy backing this on top of iw lets
distributions eventually replace those scripts with a simple iw call.
That should also get distributions to consider implementing the master
GeoClue provider.

The last mile IMHO, will be to figure out how the different desktops /
connection managers like Network Manager and Connman, and embedded
systems ultimately use some of this or use alternatives.

 Luis

Re: [PATCH 0/2] iw: add GeoClue support

[Bastien Nocera]

On Mon, 2010-08-23 at 08:44 -0700, Luis R. Rodriguez wrote:
> 
> > What use is a command line tool that has to talk to a whole bunch of
> > daemons etc.?
> 
> The current implementation doesn't talk to deamons. The hostip
> provider within GeoClue and it will just trigger a URL get. If
> desktops start implementing a master server though then the query
> would simply be a cached response. 

Note that this error carries on in the mail. There is a master provider
for Geoclue that can make use of whatever providers are available, but
it's not in too good a shape.

I'd rather somebody started fixing the Geoclue master provider rather
than relying on a particular service, especially when the D-Bus API for
the providers themselves is something we don't want to support in the
longer term.

Cheers

Re: [PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

On Mon, Aug 23, 2010 at 09:05:07AM -0700, Bastien Nocera wrote:
> On Mon, 2010-08-23 at 08:44 -0700, Luis R. Rodriguez wrote:
> > 
> > > What use is a command line tool that has to talk to a whole bunch of
> > > daemons etc.?
> > 
> > The current implementation doesn't talk to deamons. The hostip
> > provider within GeoClue and it will just trigger a URL get. If
> > desktops start implementing a master server though then the query
> > would simply be a cached response. 
> 
> Note that this error carries on in the mail. There is a master provider
> for Geoclue that can make use of whatever providers are available, but
> it's not in too good a shape.

I see, can you elaborate on that a little?

> I'd rather somebody started fixing the Geoclue master provider rather
> than relying on a particular service, especially when the D-Bus API for
> the providers themselves is something we don't want to support in the
> longer term.

Would the master provider not use Dbus for gypsy, for example?

  Luis

Re: [PATCH 0/2] iw: add GeoClue support

[Bastien Nocera]

On Mon, 2010-08-23 at 10:46 -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 23, 2010 at 09:05:07AM -0700, Bastien Nocera wrote:
> > On Mon, 2010-08-23 at 08:44 -0700, Luis R. Rodriguez wrote:
> > > 
> > > > What use is a command line tool that has to talk to a whole bunch of
> > > > daemons etc.?
> > > 
> > > The current implementation doesn't talk to deamons. The hostip
> > > provider within GeoClue and it will just trigger a URL get. If
> > > desktops start implementing a master server though then the query
> > > would simply be a cached response. 
> > 
> > Note that this error carries on in the mail. There is a master provider
> > for Geoclue that can make use of whatever providers are available, but
> > it's not in too good a shape.
> 
> I see, can you elaborate on that a little?

See the bugzillas filed against Geoclue, most of them are due to bugs in
the Geoclue master provider.

> > I'd rather somebody started fixing the Geoclue master provider rather
> > than relying on a particular service, especially when the D-Bus API for
> > the providers themselves is something we don't want to support in the
> > longer term.
> 
> Would the master provider not use Dbus for gypsy, for example?

No, I'm talking about what's exported by the providers. I don't really
care if they talk to other parts of the system using D-Bus though. I'm
talking about link 2) here.

[App] <-1-> [Geoclue master] <-2-> [Gypsy provider] <-3-> [Gypsy daemon]

Re: [PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

On Mon, Aug 23, 2010 at 02:05:56PM -0700, Bastien Nocera wrote:
> On Mon, 2010-08-23 at 10:46 -0700, Luis R. Rodriguez wrote:
> > On Mon, Aug 23, 2010 at 09:05:07AM -0700, Bastien Nocera wrote:
> > > On Mon, 2010-08-23 at 08:44 -0700, Luis R. Rodriguez wrote:
> > > > 
> > > > > What use is a command line tool that has to talk to a whole bunch of
> > > > > daemons etc.?
> > > > 
> > > > The current implementation doesn't talk to deamons. The hostip
> > > > provider within GeoClue and it will just trigger a URL get. If
> > > > desktops start implementing a master server though then the query
> > > > would simply be a cached response. 
> > > 
> > > Note that this error carries on in the mail. There is a master provider
> > > for Geoclue that can make use of whatever providers are available, but
> > > it's not in too good a shape.
> > 
> > I see, can you elaborate on that a little?
> 
> See the bugzillas filed against Geoclue, most of them are due to bugs in
> the Geoclue master provider.
> 
> > > I'd rather somebody started fixing the Geoclue master provider rather
> > > than relying on a particular service, especially when the D-Bus API for
> > > the providers themselves is something we don't want to support in the
> > > longer term.
> > 
> > Would the master provider not use Dbus for gypsy, for example?
> 
> No, I'm talking about what's exported by the providers. I don't really
> care if they talk to other parts of the system using D-Bus though. I'm
> talking about link 2) here.
> 
> [App] <-1-> [Geoclue master] <-2-> [Gypsy provider] <-3-> [Gypsy daemon]

Sorry I do not follow yet. Is the idea that you would prefer if
client applications would never talk to providers directly and instead
always used the master provider?

 Luis

Re: [PATCH 0/2] iw: add GeoClue support

[Bastien Nocera]

On Mon, 2010-08-23 at 15:11 -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 23, 2010 at 02:05:56PM -0700, Bastien Nocera wrote:
<snip>
> > No, I'm talking about what's exported by the providers. I don't really
> > care if they talk to other parts of the system using D-Bus though. I'm
> > talking about link 2) here.
> > 
> > [App] <-1-> [Geoclue master] <-2-> [Gypsy provider] <-3-> [Gypsy daemon]
> 
> Sorry I do not follow yet. Is the idea that you would prefer if
> client applications would never talk to providers directly and instead
> always used the master provider?

Exactly, and it's mentioned in the bugzilla, and was discussed on the
mailing-list as well.

Re: [PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

On Mon, Aug 23, 2010 at 03:15:07PM -0700, Bastien Nocera wrote:
> On Mon, 2010-08-23 at 15:11 -0700, Luis R. Rodriguez wrote:
> > On Mon, Aug 23, 2010 at 02:05:56PM -0700, Bastien Nocera wrote:
> <snip>
> > > No, I'm talking about what's exported by the providers. I don't really
> > > care if they talk to other parts of the system using D-Bus though. I'm
> > > talking about link 2) here.
> > > 
> > > [App] <-1-> [Geoclue master] <-2-> [Gypsy provider] <-3-> [Gypsy daemon]
> > 
> > Sorry I do not follow yet. Is the idea that you would prefer if
> > client applications would never talk to providers directly and instead
> > always used the master provider?
> 
> Exactly, and it's mentioned in the bugzilla

Thanks for the heads up, I haven't been grep'ing through the bugzilla.

> and was discussed on the mailing-list as well.

And am new there :)

This makes sense -- are there plans on removing all these exported
library routines so that the only exposed thing is the master
provider calls?

Based on your comments it seems changing the iw patch to just
use the master provider would go more in line with current
development focus.

  Luis

Re: [PATCH 0/2] iw: add GeoClue support

[Bastien Nocera]

On Mon, 2010-08-23 at 15:22 -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 23, 2010 at 03:15:07PM -0700, Bastien Nocera wrote:
> > On Mon, 2010-08-23 at 15:11 -0700, Luis R. Rodriguez wrote:
> > > On Mon, Aug 23, 2010 at 02:05:56PM -0700, Bastien Nocera wrote:
> > <snip>
> > > > No, I'm talking about what's exported by the providers. I don't really
> > > > care if they talk to other parts of the system using D-Bus though. I'm
> > > > talking about link 2) here.
> > > > 
> > > > [App] <-1-> [Geoclue master] <-2-> [Gypsy provider] <-3-> [Gypsy daemon]
> > > 
> > > Sorry I do not follow yet. Is the idea that you would prefer if
> > > client applications would never talk to providers directly and instead
> > > always used the master provider?
> > 
> > Exactly, and it's mentioned in the bugzilla
> 
> Thanks for the heads up, I haven't been grep'ing through the bugzilla.
> 
> > and was discussed on the mailing-list as well.
> 
> And am new there :)
> 
> This makes sense -- are there plans on removing all these exported
> library routines so that the only exposed thing is the master
> provider calls?
> 
> Based on your comments it seems changing the iw patch to just
> use the master provider would go more in line with current
> development focus.

Right. And file bugs if you have specific uses that don't work as
expected with the master provider.