The GSoC project to integrate GeoClue to GNOME and eventually send
regulatory hint information to the kernel [1] will not be completed
through GSoC. Since I am not sure if the student will be interested in
following up on this project idea outside the scope of GSoC I'm
looking for advice to better get an idea of what it is exactly we
should be looking forward to change to get information to the kernel
to enhance regulatory support using GeoClue. At the very least I'd
like to come to some conclusion as to where it is best to put software
to send information to the kernel to help distributions.
The current best alternative I've seen is to read the current timezone
information and extract the country from that. That is how John
implemented it for Fedora. This may be enough but GeoClue should
provide better accuracy. All we need in the kernel is to determine the
country you are on. The user can obviously set this themselves during
a distribution install, but it may make sense to just use GeoClue for
this. Under the assumption that using GeoClue is the way to go how
should we do this?
For the GSoC project I was initially suggesting for Network Manager to
get GeoClue integration and then have Network Manager send the
regulatory hint once a country was determined through either user
input or through GeoClue magic. After some discussions with Jouni
about this he convinced me this may not be the best place for this. So
if not Network Manager, where? Do we want a GNOME location aware panel
under System->Administration? Is it as simple as that? If not are
there any other suggestions?
If you fwd this to another list for discussion please do CC me.
[1] http://wireless.kernel.org/en/developers/GSoC/2009/GeoClue_regulatory
Luis
On Fri, Jul 17, 2009 at 9:33 AM, Bastien Nocera<[email protected]> wrote:
> On Thu, 2009-07-16 at 18:10 -0700, Luis R. Rodriguez wrote:
>> The GSoC project to integrate GeoClue to GNOME and eventually send
>> regulatory hint information to the kernel [1] will not be completed
>> through GSoC. Since I am not sure if the student will be interested in
>> following up on this project idea outside the scope of GSoC I'm
>> looking for advice to better get an idea of what it is exactly we
>> should be looking forward to change to get information to the kernel
>> to enhance regulatory support using GeoClue. At the very least I'd
>> like to come to some conclusion as to where it is best to put software
>> to send information to the kernel to help distributions.
>>
>> The current best alternative I've seen is to read the current timezone
>> information and extract the country from that. That is how John
>> implemented it for Fedora. This may be enough but GeoClue should
>> provide better accuracy. All we need in the kernel is to determine the
>> country you are on. The user can obviously set this themselves during
>> a distribution install, but it may make sense to just use GeoClue for
>> this. Under the assumption that using GeoClue is the way to go how
>> should we do this?
>>
>> For the GSoC project I was initially suggesting for Network Manager to
>> get GeoClue integration and then have Network Manager send the
>> regulatory hint once a country was determined through either user
>> input or through GeoClue magic. After some discussions with Jouni
>> about this he convinced me this may not be the best place for this. So
>> if not Network Manager, where? Do we want a GNOME location aware panel
>> under System->Administration? Is it as simple as that? If not are
>> there any other suggestions?
>
> Adding more preferences certainly isn't the solution.
>
> One of the problems you'd encounter would be trying to get information
> about which country you're in, which might sometimes require a network
> to get.
>
> You get a bit of a chicken/egg problem. How can I get online to get my
> location given that I can't get online because my wireless card's been
> restricted to channels outside my reach.
Agreed, but there is certain information even from wireless cards
which may feed GeoClue even before establishing a network connection,
for example a nearby country AP sending beacons with a country IE.
Another non-network related GeoClue feed could be a GPS device.
> How does John's code react when the timezone changes?
It just reads the country from timezone file, I've pasted the script
below inline in case you are curious.
> How do you get
> online to get the country when the network isn't available because of
> previous restrictions?
Cards that have no regulatory information programmed into them either
through the firmware or through an EEPROM get to world roam. This
means passive scanning on some channels, for example. It means you
cannot send probe requests out but instead just have to wait for
beacons on each channel. When a beacon is received though we do enable
active scanning -- that is we enable probe requests and even
beaconing.
Our world roaming capabilities may suffice for most of the world, the
only excemption is DFS channels on 5 GHz for which we do not allow to
even passively scan. For that you do need to set a regulatory domain.
Another advantage to having the country defined is you may be allowed
to TX at a higher power. This should improve performance.
Keep in mind that cards that have EEPROM regulatory information is
always trusted first, but cards that do not have any regulatory
information benefit completely from user input.
So in summary it is possible for you to connect to a wireless network
even without regulatory information -- when we world roam. The
exemption is when an AP is on a DFS channel. The next good thing is to
improve performance in case your regdomian does allow higher max EIRP.
> Do you need to change the regulatory hint in the
> kernel as soon as you know the new position?
No, and in some cases it not required at all -- in the case of intel
cards or Atheros cards where the regulatory domain is programmed into
the card. For these cards setting the regulatory domain just further
helps compliance in case say your card is for Japan and allows channel
13, and you move to the US and need to disable channel 13. Setting the
regulatory domain to "US" through userspace will disable channel 13.
With Intel or Atheros cards if you do it the other way around -- buy a
US card and move to the JP you won't get channel 13 enabled.
For cards that have no regulatory information the default is to world
roam. So for these cases (b43, b43legacy, rt2x00 drivers, etc) there
is a good benefit to getting some user input for regulatory
information.
> Is it saved and cached
> somewhere so you don't need to pound the hardware on each reboot?
No! And that's the point to this e-mail, the goal is getting userspace
to catch up with the new regulatory framework designed in the kernel
to help compliance. Seems to me like GeoClue integration on the
desktop would help.
Luis
I thought the reason for using GeoClue is to cater for frequent
travellers who can cross timezone (and not neccesarily reset their
laptop's computer/clock for it)? So it is orthogonal to one-off static
setup where the computer mostly stay in the same country/location. Is
there an iw/cfg80211 interface/field for regulatory info? AFAIK there
isn't in wext, but that's on its way out and probably not important...
On Fri, Jul 17, 2009 at 2:10 AM, Luis R. Rodriguez<[email protected]> wrote:
> The GSoC project to integrate GeoClue to GNOME and eventually send
> regulatory hint information to the kernel [1] will not be completed
> through GSoC. Since I am not sure if the student will be interested in
> following up on this project idea outside the scope of GSoC I'm
> looking for advice to better get an idea of what it is exactly we
> should be looking forward to change to get information to the kernel
> to enhance regulatory support using GeoClue. At the very least I'd
> like to come to some conclusion as to where it is best to put software
> to send information to the kernel to help distributions.
>
> The current best alternative I've seen is to read the current timezone
> information and extract the country from that. That is how John
> implemented it for Fedora. This may be enough but GeoClue should
> provide better accuracy. All we need in the kernel is to determine the
> country you are on. The user can obviously set this themselves during
> a distribution install, but it may make sense to just use GeoClue for
> this. Under the assumption that using GeoClue is the way to go how
> should we do this?
>
> For the GSoC project I was initially suggesting for Network Manager to
> get GeoClue integration and then have Network Manager send the
> regulatory hint once a country was determined through either user
> input or through GeoClue magic. After some discussions with Jouni
> about this he convinced me this may not be the best place for this. So
> if not Network Manager, where? Do we want a GNOME location aware panel
> under System->Administration? Is it as simple as that? If not are
> there any other suggestions?
>
> If you fwd this to another list for discussion please do CC me.
>
> [1] http://wireless.kernel.org/en/developers/GSoC/2009/GeoClue_regulatory
>
> ?Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
On Fri, Jul 17, 2009 at 9:52 AM, Luis R. Rodriguez<[email protected]> wrote:
> It just reads the country from timezone file, I've pasted the script
> below inline in case you are curious.
Oh and here is the script used by Fedora (thanks to John):
#!/bin/sh
REGDOMAIN=/etc/sysconfig/regdomain
CLOCK=/etc/sysconfig/clock
if [ -f $REGDOMAIN ]
then
# This should set COUNTRY
. $REGDOMAIN
iw reg set $COUNTRY
exit
fi
if [ -f $CLOCK ]
then
# This should set ZONE
. $CLOCK
else
echo "Timezone information not found! Unable to set regulatory domain."
exit
fi
if [ -z "$ZONE" ]
then
echo "Timezone information not set! Unable to set regulatory domain."
exit
fi
COOKED_ZONE=$(echo $ZONE | sed -e 's/ /_/')
COUNTRY=$(grep $COOKED_ZONE /usr/share/zoneinfo/zone.tab | awk '{ print $1 }')
if [ -z "$COUNTRY" ]
then
echo "Could not determine country! Unable to set regulatory domain."
exit
fi
iw reg set $COUNTRY
On Thu, 2009-07-16 at 18:10 -0700, Luis R. Rodriguez wrote:
> The GSoC project to integrate GeoClue to GNOME and eventually send
> regulatory hint information to the kernel [1] will not be completed
> through GSoC. Since I am not sure if the student will be interested in
> following up on this project idea outside the scope of GSoC I'm
> looking for advice to better get an idea of what it is exactly we
> should be looking forward to change to get information to the kernel
> to enhance regulatory support using GeoClue. At the very least I'd
> like to come to some conclusion as to where it is best to put software
> to send information to the kernel to help distributions.
>
> The current best alternative I've seen is to read the current timezone
> information and extract the country from that. That is how John
> implemented it for Fedora. This may be enough but GeoClue should
> provide better accuracy. All we need in the kernel is to determine the
> country you are on. The user can obviously set this themselves during
> a distribution install, but it may make sense to just use GeoClue for
> this. Under the assumption that using GeoClue is the way to go how
> should we do this?
>
> For the GSoC project I was initially suggesting for Network Manager to
> get GeoClue integration and then have Network Manager send the
> regulatory hint once a country was determined through either user
> input or through GeoClue magic. After some discussions with Jouni
> about this he convinced me this may not be the best place for this. So
> if not Network Manager, where? Do we want a GNOME location aware panel
> under System->Administration? Is it as simple as that? If not are
> there any other suggestions?
Adding more preferences certainly isn't the solution.
One of the problems you'd encounter would be trying to get information
about which country you're in, which might sometimes require a network
to get.
You get a bit of a chicken/egg problem. How can I get online to get my
location given that I can't get online because my wireless card's been
restricted to channels outside my reach.
How does John's code react when the timezone changes? How do you get
online to get the country when the network isn't available because of
previous restrictions? Do you need to change the regulatory hint in the
kernel as soon as you know the new position? Is it saved and cached
somewhere so you don't need to pound the hardware on each reboot?
Let us know...
Cheers
On Fri, Jul 17, 2009 at 4:17 AM, Hin-Tak Leung<[email protected]> wrote:
> I thought the reason for using GeoClue is to cater for frequent
> travellers who can cross timezone
No, you use it for whatever you want. For wireless we want it to get
the country so the user does not have to bother with setting the
regulatory domain themselves.
> (and not neccesarily reset their
> laptop's computer/clock for it)?
That seems to be just one use for GeoClue.
> So it is orthogonal to one-off static
> setup where the computer mostly stay in the same country/location.
Sure, a static computer still can use location information and I won't
get into the use cases for that outside the scope of wireless. As far
as distributions are concerned it would still be nice to provide the
country the user is in to the kernel even for statically placed
computers and not have the user set this.
The idea is to just automate informing the kernel of your country and
using the best resources possible to do this.
> Is
> there an iw/cfg80211 interface/field for regulatory info?
Yes. See iw documentation about this [1], wpa_supplicant also has
support for this as well.
[1] http://wireless.kernel.org/en/users/Documentation/iw#Updating_your_regulatory_domain
> AFAIK there isn't in wext,
No and there won't be.
> but that's on its way out and probably not important...
Wireless extensions is not going to be removed, we just stop advancing
it and now that we have a good replacement API (cfg80211) we push
driver developers to use it for new drivers to be merged.
Luis
On Fri, Jul 17, 2009 at 09:54:53AM -0700, Luis R. Rodriguez wrote:
> On Fri, Jul 17, 2009 at 9:52 AM, Luis R. Rodriguez<[email protected]> wrote:
>
> > It just reads the country from timezone file, I've pasted the script
> > below inline in case you are curious.
>
> Oh and here is the script used by Fedora (thanks to John):
This script is invoked by /lib/udev/rules.d/85-regulatory.rules
in Fedora. This only occurs when a wireless device is added to
the system. There is currently no awareness of timezone changes --
definitely a short-coming. We could use some desktop developers to
advise/help with that!
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
?Viva Honduras Libre!