lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimrtWQKycuAcZ3SjDaOqJ6Z-pPNauRfh+2aZ=ge@mail.gmail.com>
Date:	Mon, 23 Aug 2010 08:44:49 -0700
From:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-wireless@...r.kernel.org, geoclue@...ts.freedesktop.org,
	David.Quan@...eros.com, kevin@...eros.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] iw: add GeoClue support

On Mon, Aug 23, 2010 at 7:11 AM, Johannes Berg
<johannes@...solutions.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ