* Re: rfkill hard state after booting
From: Johannes Berg @ 2009-09-24 17:29 UTC (permalink / raw)
To: Alan Jenkins
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABB8C5E.6070402@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On Thu, 2009-09-24 at 16:12 +0100, Alan Jenkins wrote:
> > Although maybe it should just call sony_nc_rfkill_update() after
> > registering all of them?
> That means the initial "add" uevents etc. will contain wrong values (and
> then be updated immediately after). Do we care about that? It's
> unlikely to matter in practice for platform devices which only get
> loaded at boot-time, but perhaps it would set a bad example.
Ah, good point. I was just a little concerned about the logic
difference, but I don't really understand the _update() logic.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* 2.6.31-git wireless broken
From: Hugh Dickins @ 2009-09-24 17:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
I've noticed for a while that wireless is broken in linux-next, on both
the machines I use it on (a Fujitsu Siemens laptop using iwl3945 and an
Acer Aspire One using ath5k: both running openSUSE 11.1, with WPA):
I hoped to find it fixed later, but no, Linus's git is broken now.
Only found time to bisect it a couple of days ago (on the Aspire One:
guess the other would show the same, but that's no more than a guess).
It arrived at the commit below as the culprit, which from your own
words doesn't seem like a very hopeful place to land :-(
That commit does give me a "WARNING: at net/mac80211/mlme.c:1904",
followed by "WARNING: at net/mac80211/mlme.c:2308" every few seconds;
and those do get fixed later on (don't appear with latest git).
But I think there's another problem that comes in later, because
at this commit iwconfig does show my ESSID, whereas with later
git it just says "ESSID:off/any" (I have not bisected when that
change comes in).
I expect you'll need a lot more info from me: please do ask
(but bear in mind that I'm wireless and network ignorant).
Thanks,
Hugh
77fdaa12cea26c204cc12c312fe40bc0f3dcdfd8 is first bad commit
commit 77fdaa12cea26c204cc12c312fe40bc0f3dcdfd8
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Tue Jul 7 03:45:17 2009 +0200
mac80211: rework MLME for multiple authentications
Sit tight. This shakes up the world as you know
it. Let go of your spaghetti tongs, they will no
longer be required, the horrible statemachine in
net/mac80211/mlme.c is no more...
With the cfg80211 SME mac80211 now has much less
to keep track of, but, on the other hand, for FT
it needs to be able to keep track of at least one
authentication being in progress while associated.
So convert from a single state machine to having
small ones for all the different things we need to
do. For real FT it will still need work wrt. PS,
but this should be a good step.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
:040000 040000 437301807c7c27495cee7692f293dac1ca56ed78 02520ec555c0873050318af669dade9e066f479d M net
^ permalink raw reply
* Re: [PATCH 3/3 V2] i2400m-sdio: select IWMC3200TOP in Kconfig
From: Inaky Perez-Gonzalez @ 2009-09-24 17:25 UTC (permalink / raw)
To: Winkler, Tomas
Cc: davem@davemloft.net, linville@tuxdriver.com,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, Zhu, Yi, Kao, Cindy H, Cohen, Guy,
Rindjunsky, Ron
In-Reply-To: <1253779256-17058-1-git-send-email-tomas.winkler@intel.com>
On Thu, 2009-09-24 at 02:00 -0600, Winkler, Tomas wrote:
> i2400m-sdio requires iwmc3200top for its operation
>
> create separate config option to separate 3200 specifics
> from eventual further wimax sdio HW.
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
I'll merge this into the WiMAX tree.
--
-- Inaky
^ permalink raw reply
* Re: rfkill hard state after booting
From: Norbert Preining @ 2009-09-24 16:19 UTC (permalink / raw)
To: Alan Jenkins
Cc: Johannes Berg, linux-wireless, Mattia Dongili, Almer S. Tigelaar,
Matthias Welwarsky
In-Reply-To: <4ABB89B2.8070302@tuffmail.co.uk>
On Do, 24 Sep 2009, Alan Jenkins wrote:
> + sony_call_snc_handle(0x124, 0x200, &result);
> + hwblock = !(result & 0x1);
> + rfkill_set_hw_state(rfk, hwblock);
> +
I confirm that the (full) patch fixed that problem. Thanks!
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at> Vienna University of Technology
Debian Developer <preining@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
GOLANT (adj.)
Blank, sly and faintly embarrassed. Pertaining to the expression seen
on the face of someone who has clearly forgotten your name.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: rfkill hard state after booting
From: Alan Jenkins @ 2009-09-24 15:12 UTC (permalink / raw)
To: Johannes Berg
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <1253804713.3868.168.camel@johannes.local>
Johannes Berg wrote:
> On Thu, 2009-09-24 at 16:01 +0100, Alan Jenkins wrote:
>
>
>> I think it's pretty clear it's in the sony code. It doesn't call
>> set_hw_state() during init. I.e. (completely untested):
>>
>
> Agree, looking at the code this seems reasonable.
>
> Although maybe it should just call sony_nc_rfkill_update() after
> registering all of them?
>
> johannes
>
That means the initial "add" uevents etc. will contain wrong values (and
then be updated immediately after). Do we care about that? It's
unlikely to matter in practice for platform devices which only get
loaded at boot-time, but perhaps it would set a bad example.
Regards
Alan
^ permalink raw reply
* Re: rfkill hard state after booting
From: Alan Jenkins @ 2009-09-24 15:01 UTC (permalink / raw)
To: Johannes Berg
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <1253801252.3868.108.camel@johannes.local>
Johannes Berg wrote:
> On Thu, 2009-09-24 at 15:02 +0200, Norbert Preining wrote:
>
>
>> I recently (on a flight) I found out that when I boot with the hard-switch
>> activated, so turning off all wireless activity on my laptop, the state
>> is not correctly announced in /dev/rfkill (reading it with rfkill command,
>> or my own gnome applet). All the devices seem to be in normal state but
>> one.
>>
>
> Very strange.
>
>
>> Here some outputs:
>> $ cd /sys/class/rfkill
>> $ ls
>> rfkill0@ rfkill1@ rfkill2@ rfkill3@ rfkill4@ rfkill5@
>> $ cat rfkill?/name
>> sony-wifi
>> sony-bluetooth
>> sony-wwan
>> hso-0
>> hci0
>> phy0
>> $
>>
>> and the three sony-* are the ones for actually turning on/off the devices,
>> but they showed all soft 0 hard 0 at initial startup. Only phy0 (AFAIR)
>> had hard 1.
>>
>
> Makes sense. I mean, that phy0 was hard blocked.
>
>
>> After turning off and on again the hard-switch the events were right.
>>
>
> I can't decide where this bug is. I suspect it's in the sony code.
> Anyone feel responsible for that code?
>
> johannes
>
I think it's pretty clear it's in the sony code. It doesn't call
set_hw_state() during init. I.e. (completely untested):
diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
index dafaa4a..a234a9d 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
struct rfkill *rfk;
enum rfkill_type type;
const char *name;
+ int result;
+ bool hwblock;
switch (nc_type) {
case SONY_WIFI:
@@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
if (!rfk)
return -ENOMEM;
+ sony_call_snc_handle(0x124, 0x200, &result);
+ hwblock = !(result & 0x1);
+ rfkill_set_hw_state(rfk, hwblock);
+
err = rfkill_register(rfk);
if (err) {
rfkill_destroy(rfk);
^ permalink raw reply related
* Re: rfkill hard state after booting
From: Johannes Berg @ 2009-09-24 15:05 UTC (permalink / raw)
To: Alan Jenkins
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABB89B2.8070302@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
On Thu, 2009-09-24 at 16:01 +0100, Alan Jenkins wrote:
> I think it's pretty clear it's in the sony code. It doesn't call
> set_hw_state() during init. I.e. (completely untested):
Agree, looking at the code this seems reasonable.
Although maybe it should just call sony_nc_rfkill_update() after
registering all of them?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: rfkill hard state after booting
From: Johannes Berg @ 2009-09-24 14:07 UTC (permalink / raw)
To: Norbert Preining
Cc: linux-wireless, Alan Jenkins, Mattia Dongili, Almer S. Tigelaar,
Matthias Welwarsky
In-Reply-To: <20090924130231.GU21590@gamma.logic.tuwien.ac.at>
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]
On Thu, 2009-09-24 at 15:02 +0200, Norbert Preining wrote:
> I recently (on a flight) I found out that when I boot with the hard-switch
> activated, so turning off all wireless activity on my laptop, the state
> is not correctly announced in /dev/rfkill (reading it with rfkill command,
> or my own gnome applet). All the devices seem to be in normal state but
> one.
Very strange.
> Here some outputs:
> $ cd /sys/class/rfkill
> $ ls
> rfkill0@ rfkill1@ rfkill2@ rfkill3@ rfkill4@ rfkill5@
> $ cat rfkill?/name
> sony-wifi
> sony-bluetooth
> sony-wwan
> hso-0
> hci0
> phy0
> $
>
> and the three sony-* are the ones for actually turning on/off the devices,
> but they showed all soft 0 hard 0 at initial startup. Only phy0 (AFAIR)
> had hard 1.
Makes sense. I mean, that phy0 was hard blocked.
> After turning off and on again the hard-switch the events were right.
I can't decide where this bug is. I suspect it's in the sony code.
Anyone feel responsible for that code?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* rfkill hard state after booting
From: Norbert Preining @ 2009-09-24 13:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
Hi all,
(please cc)
I recently (on a flight) I found out that when I boot with the hard-switch
activated, so turning off all wireless activity on my laptop, the state
is not correctly announced in /dev/rfkill (reading it with rfkill command,
or my own gnome applet). All the devices seem to be in normal state but
one.
Here some outputs:
$ cd /sys/class/rfkill
$ ls
rfkill0@ rfkill1@ rfkill2@ rfkill3@ rfkill4@ rfkill5@
$ cat rfkill?/name
sony-wifi
sony-bluetooth
sony-wwan
hso-0
hci0
phy0
$
and the three sony-* are the ones for actually turning on/off the devices,
but they showed all soft 0 hard 0 at initial startup. Only phy0 (AFAIR)
had hard 1.
After turning off and on again the hard-switch the events were right.
That is all with 2.6.31.
driver iwlagn, Detected Intel Wireless WiFi Link 5100AGN REV=0x54
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at> Vienna University of Technology
Debian Developer <preining@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
LIMERIGG (vb.)
To jar one's leg as the result of the disappearance of a stair which
isn't there in the darkness.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: [PATCH] cfg80211: don't set privacy w/o key
From: Kalle Valo @ 2009-09-24 13:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1253775657.3868.8.camel@johannes.local>
On Thu, Sep 24, 2009 at 12:00 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> When wpa_supplicant is used to connect to open networks,
> it causes the wdev->wext.keys to point to key memory, but
> that key memory is all empty. Only use privacy when there
> is a default key to be used.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Thanks, this fixes the issue I reported yesterday evening.
Tested-by: Kalle Valo <kalle.valo@iki.fi>
> Never happened of course with iw ...
This is just the reason why I still use stock wpa_supplicant from debian :)
Kalle
^ permalink raw reply
* Re: [PATCH, v2]: nl80211: report age of scan results
From: Johannes Berg @ 2009-09-24 10:29 UTC (permalink / raw)
To: Holger Schurig; +Cc: John Linville, linux-wireless
In-Reply-To: <200909241221.01456.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
On Thu, 2009-09-24 at 12:21 +0200, Holger Schurig wrote:
> Linux keeps scan results up to 15 seconds. This can be a problem for fast
> moving clients: they get back stale data. But if the kernel reports the age
> of the BSS items, then user-space can simply weed out old entries by itself.
>
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Fine with me, I don't care if there is a #define or not.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
johannes
>
> ---
>
> v2: renamed NL80211_BSS_AGE_MS to NL80211_BSS_SEEN_MS_AGO to underline that
> it's a relativene time
>
> --- linux-wl.orig/include/linux/nl80211.h
> +++ linux-wl/include/linux/nl80211.h
> @@ -1277,6 +1277,7 @@
> * @NL80211_BSS_SIGNAL_UNSPEC: signal strength of the probe response/beacon
> * in unspecified units, scaled to 0..100 (u8)
> * @NL80211_BSS_STATUS: status, if this BSS is "used"
> + * @NL80211_BSS_SEEN_MS_AGO: age of this BSS entry in ms
> * @__NL80211_BSS_AFTER_LAST: internal
> * @NL80211_BSS_MAX: highest BSS attribute
> */
> @@ -1291,6 +1292,7 @@
> NL80211_BSS_SIGNAL_MBM,
> NL80211_BSS_SIGNAL_UNSPEC,
> NL80211_BSS_STATUS,
> + NL80211_BSS_SEEN_MS_AGO,
>
> /* keep last */
> __NL80211_BSS_AFTER_LAST,
> --- linux-wl.orig/net/wireless/nl80211.c
> +++ linux-wl/net/wireless/nl80211.c
> @@ -3105,6 +3105,8 @@
> NLA_PUT_U16(msg, NL80211_BSS_BEACON_INTERVAL, res->beacon_interval);
> NLA_PUT_U16(msg, NL80211_BSS_CAPABILITY, res->capability);
> NLA_PUT_U32(msg, NL80211_BSS_FREQUENCY, res->channel->center_freq);
> + NLA_PUT_U32(msg, NL80211_BSS_SEEN_MS_AGO,
> + jiffies_to_msecs(jiffies - intbss->ts));
>
> switch (rdev->wiphy.signal_type) {
> case CFG80211_SIGNAL_TYPE_MBM:
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH, v2]: nl80211: report age of scan results
From: Holger Schurig @ 2009-09-24 10:21 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Johannes Berg
Linux keeps scan results up to 15 seconds. This can be a problem for fast
moving clients: they get back stale data. But if the kernel reports the age
of the BSS items, then user-space can simply weed out old entries by itself.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
---
v2: renamed NL80211_BSS_AGE_MS to NL80211_BSS_SEEN_MS_AGO to underline that
it's a relativene time
--- linux-wl.orig/include/linux/nl80211.h
+++ linux-wl/include/linux/nl80211.h
@@ -1277,6 +1277,7 @@
* @NL80211_BSS_SIGNAL_UNSPEC: signal strength of the probe response/beacon
* in unspecified units, scaled to 0..100 (u8)
* @NL80211_BSS_STATUS: status, if this BSS is "used"
+ * @NL80211_BSS_SEEN_MS_AGO: age of this BSS entry in ms
* @__NL80211_BSS_AFTER_LAST: internal
* @NL80211_BSS_MAX: highest BSS attribute
*/
@@ -1291,6 +1292,7 @@
NL80211_BSS_SIGNAL_MBM,
NL80211_BSS_SIGNAL_UNSPEC,
NL80211_BSS_STATUS,
+ NL80211_BSS_SEEN_MS_AGO,
/* keep last */
__NL80211_BSS_AFTER_LAST,
--- linux-wl.orig/net/wireless/nl80211.c
+++ linux-wl/net/wireless/nl80211.c
@@ -3105,6 +3105,8 @@
NLA_PUT_U16(msg, NL80211_BSS_BEACON_INTERVAL, res->beacon_interval);
NLA_PUT_U16(msg, NL80211_BSS_CAPABILITY, res->capability);
NLA_PUT_U32(msg, NL80211_BSS_FREQUENCY, res->channel->center_freq);
+ NLA_PUT_U32(msg, NL80211_BSS_SEEN_MS_AGO,
+ jiffies_to_msecs(jiffies - intbss->ts));
switch (rdev->wiphy.signal_type) {
case CFG80211_SIGNAL_TYPE_MBM:
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH]: nl80211: report age of scan results
From: Holger Schurig @ 2009-09-24 10:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1253786034.3868.18.camel@johannes.local>
> I'm not sure "age" is appropriate -- the BSS entry might be older but
> have been touched in a new scan etc.
>
> Maybe "last seen"? Although that kinda implies an absolute time while
> "age" implies a relative time ... hmm ...
NL80211_BSS_SEEN_MS_AGO ?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH]: nl80211: report age of scan results
From: Johannes Berg @ 2009-09-24 9:53 UTC (permalink / raw)
To: Holger Schurig; +Cc: John Linville, linux-wireless
In-Reply-To: <200909241055.51604.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]
On Thu, 2009-09-24 at 10:55 +0200, Holger Schurig wrote:
> + * @NL80211_BSS_AGE_MS: age of this BSS entry in ms
I'm not sure "age" is appropriate -- the BSS entry might be older but
have been touched in a new scan etc.
Maybe "last seen"? Although that kinda implies an absolute time while
"age" implies a relative time ... hmm ...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH]: nl80211: report age of scan results
From: Luis R. Rodriguez @ 2009-09-24 9:44 UTC (permalink / raw)
To: Holger Schurig; +Cc: John Linville, linux-wireless, Johannes Berg
In-Reply-To: <200909241119.28207.hs4233@mail.mn-solutions.de>
On Thu, Sep 24, 2009 at 2:19 AM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
> On Thursday 24 September 2009 10:59:57 Luis R. Rodriguez wrote:
>> Wil want to #define NL80211_BSS_AGE_MS NL80211_BSS_AGE_MS as
>> well so userspace apps can ifdef around that feature to know if
>> its supported.
>
> Nice idea.
>
> That could be a different patch. I haven't seen it for anything
> else, e.g. there's no "#define NL80211_BSS_STATUS" anywhere.
Typically a command went in with a set of attributes, I tend to only
add a define for a new command, and then for any new attributes after
that in later patches for the same command.
> "iw" for example has it's own nl80211.h file.
Yes, but not all apps may ship their own ni80211.h, we probably will
be implementing then, but yeah -- we cannot enforce this, only
recommend it.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: don't set privacy w/o key
From: Luis R. Rodriguez @ 2009-09-24 9:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Kalle Valo, linux-wireless
In-Reply-To: <1253775657.3868.8.camel@johannes.local>
On Thu, Sep 24, 2009 at 12:00 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> When wpa_supplicant is used to connect to open networks,
> it causes the wdev->wext.keys to point to key memory, but
> that key memory is all empty. Only use privacy when there
> is a default key to be used.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Luis
^ permalink raw reply
* [PATCH] iw: show age of last scan
From: Holger Schurig @ 2009-09-24 9:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
This shows how old a scan result entry is.
---
Example:
# ./iw eth1 scan trigger freq 2412
# sleep 1
# ./iw eth1 scan dump | grep seen
last seen: 832 ms ago
last seen: 852 ms ago
last seen: 852 ms ago
# sleep 1
# ./iw eth1 scan dump | grep seen
last seen: 1836 ms ago
last seen: 1856 ms ago
last seen: 1856 ms ago
Index: iw/scan.c
===================================================================
--- iw.orig/scan.c 2009-09-21 14:06:47.000000000 +0200
+++ iw/scan.c 2009-09-24 09:57:02.000000000 +0200
@@ -754,6 +754,7 @@ static int print_bss_handler(struct nl_m
[NL80211_BSS_SIGNAL_MBM] = { .type = NLA_U32 },
[NL80211_BSS_SIGNAL_UNSPEC] = { .type = NLA_U8 },
[NL80211_BSS_STATUS] = { .type = NLA_U32 },
+ [NL80211_BSS_AGE_MS] = { .type = NLA_U32 },
};
struct scan_params *params = arg;
@@ -845,6 +846,10 @@ static int print_bss_handler(struct nl_m
unsigned char s = nla_get_u8(bss[NL80211_BSS_SIGNAL_UNSPEC]);
printf("\tsignal: %d/100\n", s);
}
+ if (bss[NL80211_BSS_AGE_MS]) {
+ int age = nla_get_u32(bss[NL80211_BSS_AGE_MS]);
+ printf("\tlast seen: %d ms ago\n", age);
+ }
if (bss[NL80211_BSS_INFORMATION_ELEMENTS])
print_ies(nla_data(bss[NL80211_BSS_INFORMATION_ELEMENTS]),
nla_len(bss[NL80211_BSS_INFORMATION_ELEMENTS]),
Index: iw/nl80211.h
===================================================================
--- iw.orig/nl80211.h 2009-09-24 09:55:57.000000000 +0200
+++ iw/nl80211.h 2009-09-24 09:56:29.000000000 +0200
@@ -1261,6 +1261,7 @@ enum nl80211_channel_type {
* @NL80211_BSS_SIGNAL_UNSPEC: signal strength of the probe response/beacon
* in unspecified units, scaled to 0..100 (u8)
* @NL80211_BSS_STATUS: status, if this BSS is "used"
+ * @NL80211_BSS_AGE_MS: age of this BSS entry in ms
* @__NL80211_BSS_AFTER_LAST: internal
* @NL80211_BSS_MAX: highest BSS attribute
*/
@@ -1275,6 +1276,7 @@ enum nl80211_bss {
NL80211_BSS_SIGNAL_MBM,
NL80211_BSS_SIGNAL_UNSPEC,
NL80211_BSS_STATUS,
+ NL80211_BSS_AGE_MS,
/* keep last */
__NL80211_BSS_AFTER_LAST,
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH]: nl80211: report age of scan results
From: Holger Schurig @ 2009-09-24 9:19 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John Linville, linux-wireless, Johannes Berg
In-Reply-To: <43e72e890909240159x6d733e1bj9c529f6fe77b32f5@mail.gmail.com>
On Thursday 24 September 2009 10:59:57 Luis R. Rodriguez wrote:
> Wil want to #define NL80211_BSS_AGE_MS NL80211_BSS_AGE_MS as
> well so userspace apps can ifdef around that feature to know if
> its supported.
Nice idea.
That could be a different patch. I haven't seen it for anything
else, e.g. there's no "#define NL80211_BSS_STATUS" anywhere.
"iw" for example has it's own nl80211.h file.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH]: nl80211: report age of scan results
From: Luis R. Rodriguez @ 2009-09-24 8:59 UTC (permalink / raw)
To: Holger Schurig; +Cc: John Linville, linux-wireless, Johannes Berg
In-Reply-To: <200909241055.51604.hs4233@mail.mn-solutions.de>
On Thu, Sep 24, 2009 at 1:55 AM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
> Linux keeps scan results up to 15 seconds. This can be a problem for fast
> moving client: they get back stale data. But if the kernel reports the
> age of some BSS, then user-space can simply weed out old entries.
>
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
>
> ---
>
> One question was if I should specify the age in ms, or if I should specify
> an absolute time. In the end I thought age in ms is better suited.
>
> If an absolute time would sent with every BSS item, then user-space would
> need an additional call to time() to find out which BSS items are too old.
> Now it can use the milliseconds directly.
>
> The case there user-space wants an absolute time ("At what hour did I get
> the last probe response from this AP?") seems to be a more theoretical
> problem. But if info is wanted, *THEN* you can call time() and substract the
> reported bss-item-age from it.
>
>
> Index: linux-wl/include/linux/nl80211.h
> ===================================================================
> --- linux-wl.orig/include/linux/nl80211.h 2009-09-24 09:19:03.000000000 +0200
> +++ linux-wl/include/linux/nl80211.h 2009-09-24 09:19:42.000000000 +0200
> @@ -1277,6 +1277,7 @@ enum nl80211_channel_type {
> * @NL80211_BSS_SIGNAL_UNSPEC: signal strength of the probe response/beacon
> * in unspecified units, scaled to 0..100 (u8)
> * @NL80211_BSS_STATUS: status, if this BSS is "used"
> + * @NL80211_BSS_AGE_MS: age of this BSS entry in ms
> * @__NL80211_BSS_AFTER_LAST: internal
> * @NL80211_BSS_MAX: highest BSS attribute
> */
> @@ -1291,6 +1292,7 @@ enum nl80211_bss {
> NL80211_BSS_SIGNAL_MBM,
> NL80211_BSS_SIGNAL_UNSPEC,
> NL80211_BSS_STATUS,
> + NL80211_BSS_AGE_MS,
Wil want to #define NL80211_BSS_AGE_MS NL80211_BSS_AGE_MS as well so
userspace apps can ifdef around that feature to know if its supported.
Luis
^ permalink raw reply
* [PATCH]: nl80211: report age of scan results
From: Holger Schurig @ 2009-09-24 8:55 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Johannes Berg
Linux keeps scan results up to 15 seconds. This can be a problem for fast
moving client: they get back stale data. But if the kernel reports the
age of some BSS, then user-space can simply weed out old entries.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
---
One question was if I should specify the age in ms, or if I should specify
an absolute time. In the end I thought age in ms is better suited.
If an absolute time would sent with every BSS item, then user-space would
need an additional call to time() to find out which BSS items are too old.
Now it can use the milliseconds directly.
The case there user-space wants an absolute time ("At what hour did I get
the last probe response from this AP?") seems to be a more theoretical
problem. But if info is wanted, *THEN* you can call time() and substract the
reported bss-item-age from it.
Index: linux-wl/include/linux/nl80211.h
===================================================================
--- linux-wl.orig/include/linux/nl80211.h 2009-09-24 09:19:03.000000000 +0200
+++ linux-wl/include/linux/nl80211.h 2009-09-24 09:19:42.000000000 +0200
@@ -1277,6 +1277,7 @@ enum nl80211_channel_type {
* @NL80211_BSS_SIGNAL_UNSPEC: signal strength of the probe response/beacon
* in unspecified units, scaled to 0..100 (u8)
* @NL80211_BSS_STATUS: status, if this BSS is "used"
+ * @NL80211_BSS_AGE_MS: age of this BSS entry in ms
* @__NL80211_BSS_AFTER_LAST: internal
* @NL80211_BSS_MAX: highest BSS attribute
*/
@@ -1291,6 +1292,7 @@ enum nl80211_bss {
NL80211_BSS_SIGNAL_MBM,
NL80211_BSS_SIGNAL_UNSPEC,
NL80211_BSS_STATUS,
+ NL80211_BSS_AGE_MS,
/* keep last */
__NL80211_BSS_AFTER_LAST,
Index: linux-wl/net/wireless/nl80211.c
===================================================================
--- linux-wl.orig/net/wireless/nl80211.c 2009-09-24 09:19:03.000000000 +0200
+++ linux-wl/net/wireless/nl80211.c 2009-09-24 09:37:40.000000000 +0200
@@ -3105,6 +3105,7 @@ static int nl80211_send_bss(struct sk_bu
NLA_PUT_U16(msg, NL80211_BSS_BEACON_INTERVAL, res->beacon_interval);
NLA_PUT_U16(msg, NL80211_BSS_CAPABILITY, res->capability);
NLA_PUT_U32(msg, NL80211_BSS_FREQUENCY, res->channel->center_freq);
+ NLA_PUT_U32(msg, NL80211_BSS_AGE_MS, jiffies_to_msecs(jiffies - intbss->ts));
switch (rdev->wiphy.signal_type) {
case CFG80211_SIGNAL_TYPE_MBM:
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: getting "ath5k phy0: noise floor calibration timeout"
From: Holger Schurig @ 2009-09-24 8:15 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1253662161.2510.59.camel@localhost.localdomain>
> I get that all the time, and have since 2.6.27 or earlier. If
> it's a real bug, we should fix it, but if it's just an
> informational message, maybe we should silence it?
On ath5k-devel, there was a mail "[ath5k-devel] [RFC/RFT] ath5k:
use noise calibration from madwifi hal" from Bob Copeland.
Part of the patch is "- we do not complain if NF calibration
isn't complete, instead we keep the last read value.".
I now applied this patch, the message is gone and the device
seems to work quite nicely. Maybe it should still emit a warning
if there are n consecutive calibration errors, but for now I'm
happy.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Problems with "cfg80211: fix SME connect" commit
From: Johannes Berg @ 2009-09-24 8:05 UTC (permalink / raw)
To: Albert Herranz; +Cc: Holger Schurig, linville, linux-wireless
In-Reply-To: <4AB7A5BB.1050300@yahoo.es>
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
On Mon, 2009-09-21 at 18:11 +0200, Albert Herranz wrote:
> Adding back "cfg80211: fix SME connect" and applying "cfg80211: don't
> overwrite privacy setting" fixes the connection issue, but with a
> introduces a small difference vs the previous working version.
> There is now an extra "deauthenticating by local choice (reason=3)"
> message in the logs.
> [ 13.969153] b43-phy0 debug: Adding Interface type 2
> [ 16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
> * master-20090916 + "cfg80211: don't overwrite privacy setting"
> [ 13.218613] b43-phy0 debug: Adding Interface type 2
> [ 15.832582] wlan1: deauthenticating by local choice (reason=3)
> [ 16.131599] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
Very odd. Can you edit the deauthenticating message to show the
BSSID/MAC address?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 3/3 V2] i2400m-sdio: select IWMC3200TOP in Kconfig
From: Tomas Winkler @ 2009-09-24 8:00 UTC (permalink / raw)
To: davem, linville, netdev, linux-wireless, linux-mmc
Cc: yi.zhu, inaky.perez-gonzalez, cindy.h.kao, guy.cohen,
ron.rindjunsky, Tomas Winkler
i2400m-sdio requires iwmc3200top for its operation
create separate config option to separate 3200 specifics
from eventual further wimax sdio HW.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
V2: create separate config option as discussed with Inaky
drivers/net/wimax/i2400m/Kconfig | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wimax/i2400m/Kconfig b/drivers/net/wimax/i2400m/Kconfig
index d623b3d..9723c5c 100644
--- a/drivers/net/wimax/i2400m/Kconfig
+++ b/drivers/net/wimax/i2400m/Kconfig
@@ -31,6 +31,15 @@ config WIMAX_I2400M_SDIO
If unsure, it is safe to select M (module).
+config WIMAX_IWMC3200_SDIO
+ bool "Intel Wireless Multicom WiMAX Connection 3200 over SDIO"
+ depends on WIMAX_I2400M_SDIO
+ select IWMC3200TOP
+ help
+ Select if you have a device based on the Intel Multicom WiMAX
+ Connection 3200 over SDIO.
+
+
config WIMAX_I2400M_DEBUG_LEVEL
int "WiMAX i2400m debug level"
depends on WIMAX_I2400M
--
1.6.0.6
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: BUG: can bring wpa_supplicant/mac80211 into a stuck state at will
From: Holger Schurig @ 2009-09-24 7:56 UTC (permalink / raw)
To: hostap; +Cc: linux-wireless
In-Reply-To: <200909221123.36953.hs4233@mail.mn-solutions.de>
> script -c "./wpa_supplicant -i eth1 -D wext -t -c mnfunk.conf -d" 1
> Wait till "ping" works
Ctrl-C
> script -c "./wpa_supplicant -i eth1 -D wext -t -c mnfunk.conf -d" 2
I cannot reproduce this anymore, dunny why.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: BUG: can bring wpa_supplicant/mac80211 into a stuck state at will
From: Johannes Berg @ 2009-09-24 7:53 UTC (permalink / raw)
To: Holger Schurig; +Cc: hostap, linux-wireless
In-Reply-To: <200909221123.36953.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 302 bytes --]
On Tue, 2009-09-22 at 11:23 +0200, Holger Schurig wrote:
> Maybe some state isn't clear at the implicit "ifdown XXX down"
> that wpa_supplicant does when terminating?
The SSID is kept and then re-applied during ifup, so that would cause a
scan, but shouldn't cause any timeouts.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox