* Re: getting "ath5k phy0: noise floor calibration timeout"
From: Dan Williams @ 2009-09-22 23:29 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <200909210902.23723.hs4233@mail.mn-solutions.de>
On Mon, 2009-09-21 at 09:02 +0200, Holger Schurig wrote:
> I kept my laptop the week-end on. The devices was unused during
> that time. I got a bunch output into my syslog:
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?
Dan
> Sep 18 17:30:03 laptop kernel: ##HS cfg80211_bss_expire:129 0
> Sep 18 17:30:03 laptop kernel: ##HS expire 00:1b:d4:44:35:90
> Sep 18 17:30:03 laptop kernel: ##HS expire 00:13:19:80:da:30
> Sep 18 17:30:03 laptop kernel: ##HS expire 00:1b:53:11:dc:40
> Sep 18 18:15:04 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 18 18:26:12 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 19 11:12:09 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 19 11:29:36 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 19 11:47:57 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 19 12:31:05 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 19 13:06:42 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 19 14:07:51 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 19 14:10:31 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 19 14:12:00 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 20 00:06:20 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 20 07:46:24 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 20 16:36:43 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 20 16:47:43 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 20 16:52:43 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 20 17:01:43 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 20 20:07:57 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 06:22:55 laptop last message repeated 2 times
> Sep 21 06:26:00 laptop last message repeated 2 times
> Sep 21 06:28:26 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 06:33:14 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 06:38:34 laptop last message repeated 2 times
> Sep 21 06:40:21 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 06:41:40 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 06:43:44 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 06:55:17 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 07:03:10 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 07:04:35 laptop last message repeated 2 times
> Sep 21 07:06:11 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 07:16:58 laptop kernel: ath5k phy0: noise floor calibration timeout (2412MHz)
> Sep 21 07:21:37 laptop last message repeated 2 times
>
> Is this anything where I should care? Or can I just
> ignore that? If the latter is the case, should I add a
> patch that only three consecutive calibration timeouts
> produce a message, so that the log doesn't get "spammed" ?
>
^ permalink raw reply
* Flush TX - wireless summit topic
From: Luis R. Rodriguez @ 2009-09-22 22:41 UTC (permalink / raw)
To: Bob Copeland, Jouni.Malinen, Johannes Berg; +Cc: linux-wireless
Another thing we spoke about at the wireless summit was flushing TX
prior to changing channel / scan. Bob, remember the issue with ath5k
on the band not coinciding on received skbs since we don't do a DMA RX
flush prior to channel change? Well one theory discussed was that we
would see that issue disappear if we actually did a proper TX flush
prior to channel change since we expect we would not see further
incoming frames from our AP if we told it we were going to PS (sending
a null func frame). If we implement a proper TX flush then the theory
goes that we wouldn't need to do any sort of DMA flush as we would not
have any frames pending.
So a plan here would be to give that a shot.
Luis
^ permalink raw reply
* Synching trees for BT 3.0 and a possible compat-bluetooth
From: Luis R. Rodriguez @ 2009-09-22 17:01 UTC (permalink / raw)
To: John W. Linville, Marcel Holtmann, Jouni.Malinen, Johannes Berg
Cc: Gaurav Jauhar, Senthil Balasubramanian, Jothikumar Mothilal,
linux-wireless, Kevin Hayes
I forgot to poke about BT 3.0 synching at the summit. To work on
bluetooth 3.0 we'll need some synching of trees between
wireless-testing and Marcel's bluetooth tree. Also a compat-bluetooth
might be in order to accomplish the same as we do with
compat-wireless, only it would seem logical to consider tying to just
merge this with compat-wireless to get the features required for
bluetooth 3.0; to do this having one tree with both would be nice with
the added benefit of all the same compat-2.6.3x.[ch] files being
reused. Synching of the trees would be required only when a feature on
one tree is not yet available on the latest rc kernel (provided marcel
rebases on Linus' latest rc as well, not sure), this will probably be
important during initial implementation, not sure how much divergence
we should expect after this goes through a release through Linus.
So any thoughts on synching bluetooth and wireless-testing other than
doing so on a private tree for development purposes?
Luis
^ permalink raw reply
* Re: [PATCH] b43: Implement RFKILL status for LP PHY
From: Michael Buesch @ 2009-09-22 12:51 UTC (permalink / raw)
To: Larry Finger; +Cc: John Linville, Gábor Stefanik, wireless, Broadcom Linux
In-Reply-To: <4AB8054F.7080600@lwfinger.net>
On Tuesday 22 September 2009 00:59:27 Larry Finger wrote:
> The LP (and probably N) PHY has the same radio disabled bit as
> the higher-revision A and G PHYs.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
ack
> ---
>
> John,
>
> Submission of this change for 2.6.32 would be nice, but not necessary.
>
> Larry
> ---
>
> Index: wireless-testing/drivers/net/wireless/b43/rfkill.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/b43/rfkill.c
> +++ wireless-testing/drivers/net/wireless/b43/rfkill.c
> @@ -28,7 +28,7 @@
> /* Returns TRUE, if the radio is enabled in hardware. */
> bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
> {
> - if (dev->phy.rev >= 3) {
> + if (dev->phy.rev >= 3 || dev->phy.type == B43_PHYTYPE_LP) {
> if (!(b43_read32(dev, B43_MMIO_RADIO_HWENABLED_HI)
> & B43_MMIO_RADIO_HWENABLED_HI_MASK))
> return 1;
>
>
>
>
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] drivers/net/wireless: Use usb_endpoint_dir_out
From: Julia Lawall @ 2009-09-22 11:45 UTC (permalink / raw)
To: John W. Linville, Ulrich Kunitz, Daniel Drake, linux-wireless,
netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Use the usb_endpoint_dir_out API function. Note that the use of
USB_TYPE_MASK in the original code is incorrect; it results in a test that
is always false.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
struct usb_endpoint_descriptor *endpoint;
expression E;
@@
- (endpoint->bEndpointAddress & E) == USB_DIR_OUT
+ usb_endpoint_dir_out(endpoint)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -u -p a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -1070,7 +1070,7 @@ static int eject_installer(struct usb_in
/* Find bulk out endpoint */
endpoint = &iface_desc->endpoint[1].desc;
- if ((endpoint->bEndpointAddress & USB_TYPE_MASK) == USB_DIR_OUT &&
+ if (usb_endpoint_dir_out(endpoint) &&
usb_endpoint_xfer_bulk(endpoint)) {
bulk_out_ep = endpoint->bEndpointAddress;
} else {
^ permalink raw reply
* Re: Comparison of wpa_supplicant with -Dnl80211 and -Dwext, WEP and WPA
From: Holger Schurig @ 2009-09-22 11:17 UTC (permalink / raw)
To: hostap; +Cc: linux-wireless
In-Reply-To: <200909221258.44921.hs4233@mail.mn-solutions.de>
> However, I'm wondering: if several scan commands are
> ...
Ah, the analysis was correct, but not the conclusion. The -EBUSY
wasn't in cfg80211_wext_giwscan(), but in
cfg80211_wext_siwscan().
Hey, I'm talking too much to myself.
/me wishes, the people are back from PDX to normal work :-)
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Comparison of wpa_supplicant with -Dnl80211 and -Dwext, WEP and WPA
From: Holger Schurig @ 2009-09-22 10:58 UTC (permalink / raw)
To: hostap; +Cc: linux-wireless
In-Reply-To: <200909221118.04569.hs4233@mail.mn-solutions.de>
> wep_nl80211
> -----------
> 0.00000 0.00000: Initializing interface ...
> 0.03985 0.03985: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
> 0.03992 0.00007: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
> 0.03998 0.00006: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
> 0.04004 0.00006: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
This is because of net/wireless/nl80211.c, function nl80211_key_allowed():
switch (wdev->iftype) {
...
case NL80211_IFTYPE_STATION:
if (wdev->sme_state != CFG80211_SME_CONNECTED)
return -ENOLINK;
break;
> wep_wext
> --------
> 0.00000 0.00000: Initializing interface ...
> 0.08801 0.08801: Setting scan request: 0 sec 100000 usec
> 0.25167 0.16365: ioctl[SIOCGIWSCAN]: Resource temporarily unavailable
This is because wpa_supplicant very early - in
wpa_driver_wext_finish_drv_init() - calls
wpa_driver_wext_disconnect(). This in turn sets a random 32
character long ESSID, as a desparate means to disconnect.
Now that an essid is set, the calling chain in the kernel
cfg80211_netdev_notifier_call(), case NETDEV_UP
cfg80211_mgd_wext_connect()
__cfg80211_connect()
cfg80211_conn_scan(
get's executed. This starts a scan.
Later, when wpa_supplicant tries to get a scan result, it will
only get an -EBUSY because of net/wireless/scan.c, function
cfg80211_wext_siwscan():
if (rdev->scan_req) {
err = -EBUSY;
goto out;
}
However, I'm wondering: if several scan commands are
supposed to add up into the BSS list anyway (and each BSS list
entry by default pruned after 15 seconds), why is it an error
to access the current state of the BSS list while a scan is
in progress?
In other words, I think the following sequence should be ok:
Request Scan
scan finishes
get scan result (2 BSS entries)
request scan
get scan result (2 BSS entries)
scan finishes (the scan is still in process)
get scan result (5 BSS entries)
If user-space ask for intermediate results, it should be
allowed to do so at any time. If user-space wants full
results, it can wait for the scan-done event.
This would mean that the BSS entries get individual locks
and that rdev->scan_req isn't used as an implicit lock.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: BUG: can bring wpa_supplicant/mac80211 into a stuck state at will
From: Holger Schurig @ 2009-09-22 9:23 UTC (permalink / raw)
To: hostap; +Cc: linux-wireless
In-Reply-To: <200909211259.45431.hs4233@mail.mn-solutions.de>
Another thing that might be related:
Start with freshly loaded modules (ath5k, mac80211, ath, cfg80211).
script -c "./wpa_supplicant -i eth1 -D wext -t -c mnfunk.conf -d" 1
Wait till "ping" works
script -c "./wpa_supplicant -i eth1 -D wext -t -c mnfunk.conf -d" 2
On the second try, it takes 15 seconds till
I'm connected and ping works again.
Maybe some state isn't clear at the implicit "ifdown XXX down"
that wpa_supplicant does when terminating?
--
http://www.holgerschurig.de
^ permalink raw reply
* Comparison of wpa_supplicant with -Dnl80211 and -Dwext, WEP and WPA
From: Holger Schurig @ 2009-09-22 9:18 UTC (permalink / raw)
To: linux-wireless; +Cc: hostap
Management abstrace: NL80211 is now much butter then WEXT :-)
wireless-testing GIT with the "don't overwrite security" patch
and wpa_supplicant git.
I made logs with
script -c "./wpa_supplicant -i eth1 -D nl80211 -t -c wpa.conf -d" wext_nl80211
script -c "./wpa_supplicant -i eth1 -D nl80211 -t -c wpa.conf -d" wpa_nl8021
script -c "./wpa_supplicant -i eth1 -D wext -t -c wep.conf -d" wep_wext
script -c "./wpa_supplicant -i eth1 -D wext -t -c wep.conf -d" wep_wext
Then I wrote a little python script to sift throught the weeds,
extract interesting events and get me the time since start and
time since previous event.
Some of those "interesting" events are further marked as
"##ERROR" to stand out from the log.
wep_wext
--------
0.00000 0.00000: Initializing interface ...
0.08801 0.08801: Setting scan request: 0 sec 100000 usec
0.25167 0.16365: ioctl[SIOCGIWSCAN]: Resource temporarily unavailable
0.25171 0.00005: ##ERROR: Failed to get scan results
0.25172 0.00001: ##ERROR: Failed to get scan results - try scanning again
0.25173 0.00001: Setting scan request: 0 sec 0 usec
0.25176 0.00003: ioctl[SIOCSIWSCAN]: Device or resource busy
0.25179 0.00003: ##ERROR: Failed to initiate AP scan.
0.25180 0.00001: Setting scan request: 10 sec 0 usec
3.07458 2.82278: CTRL-EVENT-CONNECTED - Connection to 00:1b:d4:44:35:90 completed (auth) [id=0 id_str=]
wep_nl80211
-----------
0.00000 0.00000: Initializing interface ...
0.03985 0.03985: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.03992 0.00007: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.03998 0.00006: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.04004 0.00006: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.04008 0.00004: Setting scan request: 0 sec 100000 usec
0.14061 0.10053: Received scan results (0 BSSes)
0.14070 0.00009: Setting scan request: 0 sec 0 usec
0.78813 0.64743: Received scan results (5 BSSes)
0.78853 0.00040: Trying to authenticate with 00:1b:53:11:dc:40 (SSID='MNFUNK' freq=2412 MHz)
0.78888 0.00034: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.96270 0.17382: SME: Authentication response: peer=00:1b:53:11:dc:40 auth_type=0 status_code=0
wpa_wext
--------
0.00000 0.00000: Initializing interface ...
0.07409 0.07409: Setting scan request: 0 sec 100000 usec
0.24986 0.17576: ioctl[SIOCGIWSCAN]: Resource temporarily unavailable
0.24990 0.00004: ##ERROR: Failed to get scan results
0.24991 0.00001: ##ERROR: Failed to get scan results - try scanning again
0.24991 0.00001: Setting scan request: 0 sec 0 usec
0.24995 0.00003: ioctl[SIOCSIWSCAN]: Device or resource busy
0.24998 0.00003: ##ERROR: Failed to initiate AP scan.
0.24998 0.00001: Setting scan request: 10 sec 0 usec
3.15609 2.90611: CTRL-EVENT-CONNECTED - Connection to 00:1b:d4:44:35:90 completed (auth) [id=0 id_str=]
wpa_nl80211
-----------
0.00000 0.00000: Initializing interface ...
0.07400 0.07400: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.07406 0.00007: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.07413 0.00006: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.07419 0.00006: ##ERROR: nl80211: set_key failed; err=-67 Link has been severed)
0.07424 0.00005: Setting scan request: 0 sec 100000 usec
0.17475 0.10052: Received scan results (0 BSSes)
0.17485 0.00009: Setting scan request: 0 sec 0 usec
0.67432 0.49947: Received scan results (3 BSSes)
0.67463 0.00032: Trying to authenticate with 00:1b:d4:44:35:90 (SSID='MNWPA' freq=2412 MHz)
0.81141 0.13678: SME: Authentication response: peer=00:1b:d4:44:35:90 auth_type=0 status_code=0
0.98805 0.17664: CTRL-EVENT-CONNECTED - Connection to 00:1b:d4:44:35:90 completed (auth) [id=0 id_str=]
For those tests, it was needed to rmmod mac80211 & friends
between those test, because otherwise connection could take up to
15 seconds.
We've quite a number of errors.
Also, NL80211 is usually faster connecting one than WEXT.
I can't say if this is a property of NL80211, it might also be
because COMPAT-WEXT has still some bugs and produces more errors,
making wpa_supplicant do excessive scanning.
--
http://www.holgerschurig.de
^ permalink raw reply
* BUGLET? cfg80211: .dumpit methods called twice
From: Holger Schurig @ 2009-09-22 7:33 UTC (permalink / raw)
To: linux-wireless
I just noticed that all functions mentioned on .dumpit in
net/wireless/nl80211.c are actually called twice.
For example, I've added
--- linux-wl.orig/net/wireless/nl80211.c 2009-09-18
14:44:28.000000000 +0200
+++ linux-wl/net/wireless/nl80211.c 2009-09-18
14:45:41.000000000 +0200
@@ -2919,6 +2919,8 @@ static int nl80211_trigger_scan(struct s
enum ieee80211_band band;
size_t ie_len;
+ printk("##HS %s:%d\n", __func__, __LINE__);
+
if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
return -EINVAL;
and when I now issue one "iw eth1 scan dump" I get two logs of
this printk in my dmesg.
AFAIK it doesn't cause any harm, but it's not that efficient and
it might cause harm in the future if any of the .dumpit methods
has the "right" side-effects.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: p54spi: dbm_antsignal value, is it RSSI or dbm?
From: Christian Lamparter @ 2009-09-22 1:46 UTC (permalink / raw)
To: Andre K; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <76516bfc0909211704iddf2ebcm9a8e12548c50fecd@mail.gmail.com>
On Tuesday 22 September 2009 02:04:32 Andre K wrote:
> I actually wouldn't mind investing some time to help sort this out,
> but I have no idea where to start.
stlc45xx gives you two clues:
a rough formula:
status.signal = data->rcpi / 2 - 110;
=> a rough formula
/* let's assume that maximum rcpi value is 140 (= -35 dBm) */
=> a _valid_ point (140 rssi => -35 dBm)
more bits can be retrieved from the original cx3110x driver and
maybe by comparing the signal/noise figures with other devices
in the same location.
> For now I think I'll have to revert to stlc45xx v1.3 and the calibration tool.
better start cracking! stlc45xx's end is near...
"stlc45xx Another wireless driver that no one seems to care about.
So sad. I guess no one will miss it when it goes away in .33."
http://www.kroah.com/log/linux/staging-status-09-2009.html
> On 9/21/09, Gábor Stefanik <netrolller.3d@gmail.com> wrote:
> > On Mon, Sep 21, 2009 at 9:04 PM, Christian Lamparter
> >>
> >> stlc45xx has a completely different phy/rf (longbow - rxhw = 5) and
> >> the specs are not a part of the freely available fw iface documentation.
> >>
> >> here's the relevant quote from a Nokia official: "
> >>> If this is so, what's so secret about the values that it needs a
> >>> binary-only tool and hidden storage area? Is there legal issues with
> >>> it (related to the radio device regulations)?
> >>
> >> Yes, this is because regulatory requirements. So thank FCC and ETSI
> >> for all this. This causes much grief for all wireless vendors, for
> >> example Intel had to do major changes in iwl3945 firmware for their
> >> mac80211 driver. "
> >> (ref:
> >> http://www.mail-archive.com/stlc45xx-devel@garage.maemo.org/msg00021.html
> >> )
> >
> > I've actually read somewhere (AFAIK on this list, but I am not sure)
> > that this is actually a misinterpretation of the FCC requirements...
AFAIK, the FCC changed the regulation wording some time ago?
But, other countries regulatory institutions (like ETSI, IC, MKK)
might have a word, or two as well...
Regards,
Chr
^ permalink raw reply
* Re: p54spi: dbm_antsignal value, is it RSSI or dbm?
From: Andre K @ 2009-09-22 0:04 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Christian Lamparter, linux-wireless
In-Reply-To: <69e28c910909211325o271c471eydb9f37e20b9bd4c3@mail.gmail.com>
Thanks for the replies and the clarification.
I actually wouldn't mind investing some time to help sort this out,
but I have no idea where to start. For now I think I'll have to revert
to stlc45xx v1.3 and the calibration tool.
-Andre.
On 9/21/09, Gábor Stefanik <netrolller.3d@gmail.com> wrote:
> On Mon, Sep 21, 2009 at 9:04 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
>> On Monday 21 September 2009 20:19:35 Andre K wrote:
>>> Hi all,
>>>
>>> I've been using the new p54spi driver on a couple of n800s. Some
>>> specifics:
>>> Kernel : 2.6.29-omap1
>>> Wireless-compat: compat-wireless-2009-08-22
>>> OS: Maemo
>>> Options: disabled CONFIG_RFKILL_BACKPORT_LEDS because it didn't compile
>>>
>>> The driver loads and functions normally. However, the values for the
>>> dbm_antsignal (from RadioTap header), are they RSSI or dbm? Initially
>>> I thought they were dbm since tcpdump showed negative values, which
>>> makes sense:
>>>
>>> Tcpdump:
>>> 14:08:25.312988 4469382526us tsft 2.0 Mb/s 2437 MHz (0x00a0) -49dB
>>> signal -41dB noise antenna 0 [0x0000000e] Acknowledgment
>>> RA:00:1d:e0:3d:5a:53 (oui Unknown)
>> heh, noise is higher than the signal.
>>
>>> 14:08:25.313903 4469383345us tsft 1.0 Mb/s 2437 MHz (0x00a0) 4dB
>>> signal -41dB noise antenna 0 [0x0000000e] 04:c2:08:00:07:07 (oui
>>> Unknown) Unknown SSAP 0x0a >
>>>
>>> Which shows up the first positive dbm value. Next I set up another
>>> n800 to broadcast ping packets (using hping3, since busybox's ping
>>> doesn't allow broadcast).
>>>
>>> 14:12:22.066192 13296010370us tsft 1.0 Mb/s 2437 MHz (0x00a0) 87dB
>>> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
>>> 192.168.10.255: ICMP echo request, id 6662, seq 40704, length 8
>>> 14:12:22.092376 13296036864us tsft 18.0 Mb/s 2437 MHz (0x00c0) 82dB
>>> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
>>> 192.168.10.255: ICMP echo request, id 6662, seq 40960, length 8
>>> 14:12:22.094787 13296037678us tsft 1.0 Mb/s 2437 MHz (0x00a0) 112dB
>>> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
>>> 192.168.10.255: ICMP echo request, id 6662, seq 40960, length 8
>>>
>>> I get strange dbm values, in the range of 50 - 100dbm, which doesn't
>>> make much sense.
>>>
>>> Does anyone have an idea what value is being returned and if there is
>>> an error in the dbm calculation?
>>>
>>
>> no, this has been on the TODO list for some time now.
>>
>> (drivers/net/wireless/p54/txrx.c)
>> static int p54_rssi_to_dbm(struct p54_common *priv, int rssi)
>> {
>> int band = priv->hw->conf.channel->band;
>>
>> if (priv->rxhw != 5)
>> return ((rssi * priv->rssical_db[band].mul) / 64 +
>> priv->rssical_db[band].add) / 4;
>> else
>> /*
>> * TODO: find the correct formula
>> */
>> return ((rssi * priv->rssical_db[band].mul) / 64 +
>> priv->rssical_db[band].add) / 4;
>> }
>>
>> the .mul & .add values can be retrieved from the p54spi_eeprom.h blob.
>>
>> 0x09, 0x00, 0xad, 0xde, /* PDR_RSSI_LINEAR_APPROXIMATION_CUSTOM
>> */
>> 0x0a, 0x01, 0x72, 0xfe, 0x1a, 0x00, 0x00, 0x00,
>> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>>
>> => translates into: (best viewed with a fixed-width font)
>> .mul = 0x010a = 416 (base 10)
>> .add = 0xfe72 = -398
>> .longbow_unkn1 = 0x001a = 26
>> .longbow_unkn2 = 0x0000 = 0
>>
>> ---
>>
>> stlc45xx has a completely different phy/rf (longbow - rxhw = 5) and
>> the specs are not a part of the freely available fw iface documentation.
>>
>> here's the relevant quote from a Nokia official: "
>>> If this is so, what's so secret about the values that it needs a
>>> binary-only tool and hidden storage area? Is there legal issues with
>>> it (related to the radio device regulations)?
>>
>> Yes, this is because regulatory requirements. So thank FCC and ETSI
>> for all this. This causes much grief for all wireless vendors, for
>> example Intel had to do major changes in iwl3945 firmware for their
>> mac80211 driver. "
>> (ref:
>> http://www.mail-archive.com/stlc45xx-devel@garage.maemo.org/msg00021.html
>> )
>
> I've actually read somewhere (AFAIK on this list, but I am not sure)
> that this is actually a misinterpretation of the FCC requirements...
>
>>
>> ---
>>
>> if you need real dBm reading for signal and noise, you have
>> to some "reverse engineering" on your own or find someone else
>> with the hardware and some spare time to burn.
>>
>> Regards,
>> Chr
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
^ permalink raw reply
* Re: [PATCH v2] mac80211: Fix [re]association power saving issue on AP side
From: Johannes Berg @ 2009-09-21 23:36 UTC (permalink / raw)
To: Igor Perminov; +Cc: John W. Linville, Jouni Malinen, linux-wireless
In-Reply-To: <1253564744.4477.18.camel@sunlight>
[-- Attachment #1: Type: text/plain, Size: 195 bytes --]
On Tue, 2009-09-22 at 00:25 +0400, Igor Perminov wrote:
> Consider the following step-by step:
NACK this, we'll take care of it properly with the required cleanup as
mentioned.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] b43: Implement RFKILL status for LP PHY
From: Larry Finger @ 2009-09-21 22:59 UTC (permalink / raw)
To: John Linville, Michael Buesch, Gábor Stefanik
Cc: wireless, Broadcom Linux
The LP (and probably N) PHY has the same radio disabled bit as
the higher-revision A and G PHYs.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
Submission of this change for 2.6.32 would be nice, but not necessary.
Larry
---
Index: wireless-testing/drivers/net/wireless/b43/rfkill.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/rfkill.c
+++ wireless-testing/drivers/net/wireless/b43/rfkill.c
@@ -28,7 +28,7 @@
/* Returns TRUE, if the radio is enabled in hardware. */
bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
{
- if (dev->phy.rev >= 3) {
+ if (dev->phy.rev >= 3 || dev->phy.type == B43_PHYTYPE_LP) {
if (!(b43_read32(dev, B43_MMIO_RADIO_HWENABLED_HI)
& B43_MMIO_RADIO_HWENABLED_HI_MASK))
return 1;
^ permalink raw reply
* [PATCH v2] mac80211: Fix [re]association power saving issue on AP side
From: Igor Perminov @ 2009-09-21 20:25 UTC (permalink / raw)
To: John W. Linville; +Cc: Johannes Berg, Jouni Malinen, linux-wireless
Consider the following step-by step:
1. A STA authenticates and associates with the AP and exchanges
traffic.
2. The STA reports to the AP that it is going to PS state.
3. Some time later the STA device goes to the stand-by mode (not only
its wi-fi card, but the device itself) and drops the association state
without sending a disassociation frame.
4. The STA device wakes up and begins authentication with an
Auth frame as it hasn't been authenticated/associated previously.
At the step 4 the AP "remembers" the STA and considers it is still in
the PS state, so the AP buffers frames, which it has to send to the STA.
But the STA isn't actually in the PS state and so it neither checks
TIM bits nor reports to the AP that it isn't power saving.
Because of that authentication/[re]association fails.
To fix authentication/[re]association stage of this issue, Auth, Assoc
Resp and Reassoc Resp frames are transmitted disregarding of STA's power
saving state.
N.B. This patch doesn't fix further data frame exchange after
authentication/[re]association. A patch in hostapd is required to fix
that.
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
---
net/mac80211/tx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 10a1099..4d981e7 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -367,7 +367,10 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
u32 staflags;
- if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)))
+ if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)
+ || ieee80211_is_auth(hdr->frame_control)
+ || ieee80211_is_assoc_resp(hdr->frame_control)
+ || ieee80211_is_reassoc_resp(hdr->frame_control)))
return TX_CONTINUE;
staflags = get_sta_flags(sta);
^ permalink raw reply related
* Re: p54spi: dbm_antsignal value, is it RSSI or dbm?
From: Gábor Stefanik @ 2009-09-21 20:25 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Andre K, linux-wireless
In-Reply-To: <200909212104.28665.chunkeey@googlemail.com>
On Mon, Sep 21, 2009 at 9:04 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Monday 21 September 2009 20:19:35 Andre K wrote:
>> Hi all,
>>
>> I've been using the new p54spi driver on a couple of n800s. Some specifics:
>> Kernel : 2.6.29-omap1
>> Wireless-compat: compat-wireless-2009-08-22
>> OS: Maemo
>> Options: disabled CONFIG_RFKILL_BACKPORT_LEDS because it didn't compile
>>
>> The driver loads and functions normally. However, the values for the
>> dbm_antsignal (from RadioTap header), are they RSSI or dbm? Initially
>> I thought they were dbm since tcpdump showed negative values, which
>> makes sense:
>>
>> Tcpdump:
>> 14:08:25.312988 4469382526us tsft 2.0 Mb/s 2437 MHz (0x00a0) -49dB
>> signal -41dB noise antenna 0 [0x0000000e] Acknowledgment RA:00:1d:e0:3d:5a:53 (oui Unknown)
> heh, noise is higher than the signal.
>
>> 14:08:25.313903 4469383345us tsft 1.0 Mb/s 2437 MHz (0x00a0) 4dB
>> signal -41dB noise antenna 0 [0x0000000e] 04:c2:08:00:07:07 (oui
>> Unknown) Unknown SSAP 0x0a >
>>
>> Which shows up the first positive dbm value. Next I set up another
>> n800 to broadcast ping packets (using hping3, since busybox's ping
>> doesn't allow broadcast).
>>
>> 14:12:22.066192 13296010370us tsft 1.0 Mb/s 2437 MHz (0x00a0) 87dB
>> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
>> 192.168.10.255: ICMP echo request, id 6662, seq 40704, length 8
>> 14:12:22.092376 13296036864us tsft 18.0 Mb/s 2437 MHz (0x00c0) 82dB
>> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
>> 192.168.10.255: ICMP echo request, id 6662, seq 40960, length 8
>> 14:12:22.094787 13296037678us tsft 1.0 Mb/s 2437 MHz (0x00a0) 112dB
>> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
>> 192.168.10.255: ICMP echo request, id 6662, seq 40960, length 8
>>
>> I get strange dbm values, in the range of 50 - 100dbm, which doesn't
>> make much sense.
>>
>> Does anyone have an idea what value is being returned and if there is
>> an error in the dbm calculation?
>>
>
> no, this has been on the TODO list for some time now.
>
> (drivers/net/wireless/p54/txrx.c)
> static int p54_rssi_to_dbm(struct p54_common *priv, int rssi)
> {
> int band = priv->hw->conf.channel->band;
>
> if (priv->rxhw != 5)
> return ((rssi * priv->rssical_db[band].mul) / 64 +
> priv->rssical_db[band].add) / 4;
> else
> /*
> * TODO: find the correct formula
> */
> return ((rssi * priv->rssical_db[band].mul) / 64 +
> priv->rssical_db[band].add) / 4;
> }
>
> the .mul & .add values can be retrieved from the p54spi_eeprom.h blob.
>
> 0x09, 0x00, 0xad, 0xde, /* PDR_RSSI_LINEAR_APPROXIMATION_CUSTOM */
> 0x0a, 0x01, 0x72, 0xfe, 0x1a, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>
> => translates into: (best viewed with a fixed-width font)
> .mul = 0x010a = 416 (base 10)
> .add = 0xfe72 = -398
> .longbow_unkn1 = 0x001a = 26
> .longbow_unkn2 = 0x0000 = 0
>
> ---
>
> stlc45xx has a completely different phy/rf (longbow - rxhw = 5) and
> the specs are not a part of the freely available fw iface documentation.
>
> here's the relevant quote from a Nokia official: "
>> If this is so, what's so secret about the values that it needs a
>> binary-only tool and hidden storage area? Is there legal issues with
>> it (related to the radio device regulations)?
>
> Yes, this is because regulatory requirements. So thank FCC and ETSI
> for all this. This causes much grief for all wireless vendors, for
> example Intel had to do major changes in iwl3945 firmware for their
> mac80211 driver. "
> (ref: http://www.mail-archive.com/stlc45xx-devel@garage.maemo.org/msg00021.html )
I've actually read somewhere (AFAIK on this list, but I am not sure)
that this is actually a misinterpretation of the FCC requirements...
>
> ---
>
> if you need real dBm reading for signal and noise, you have
> to some "reverse engineering" on your own or find someone else
> with the hardware and some spare time to burn.
>
> Regards,
> Chr
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: p54spi: dbm_antsignal value, is it RSSI or dbm?
From: Christian Lamparter @ 2009-09-21 19:04 UTC (permalink / raw)
To: Andre K; +Cc: linux-wireless
In-Reply-To: <76516bfc0909211119i4362ca35k13fc1f87857fb393@mail.gmail.com>
On Monday 21 September 2009 20:19:35 Andre K wrote:
> Hi all,
>
> I've been using the new p54spi driver on a couple of n800s. Some specifics:
> Kernel : 2.6.29-omap1
> Wireless-compat: compat-wireless-2009-08-22
> OS: Maemo
> Options: disabled CONFIG_RFKILL_BACKPORT_LEDS because it didn't compile
>
> The driver loads and functions normally. However, the values for the
> dbm_antsignal (from RadioTap header), are they RSSI or dbm? Initially
> I thought they were dbm since tcpdump showed negative values, which
> makes sense:
>
> Tcpdump:
> 14:08:25.312988 4469382526us tsft 2.0 Mb/s 2437 MHz (0x00a0) -49dB
> signal -41dB noise antenna 0 [0x0000000e] Acknowledgment RA:00:1d:e0:3d:5a:53 (oui Unknown)
heh, noise is higher than the signal.
> 14:08:25.313903 4469383345us tsft 1.0 Mb/s 2437 MHz (0x00a0) 4dB
> signal -41dB noise antenna 0 [0x0000000e] 04:c2:08:00:07:07 (oui
> Unknown) Unknown SSAP 0x0a >
>
> Which shows up the first positive dbm value. Next I set up another
> n800 to broadcast ping packets (using hping3, since busybox's ping
> doesn't allow broadcast).
>
> 14:12:22.066192 13296010370us tsft 1.0 Mb/s 2437 MHz (0x00a0) 87dB
> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
> 192.168.10.255: ICMP echo request, id 6662, seq 40704, length 8
> 14:12:22.092376 13296036864us tsft 18.0 Mb/s 2437 MHz (0x00c0) 82dB
> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
> 192.168.10.255: ICMP echo request, id 6662, seq 40960, length 8
> 14:12:22.094787 13296037678us tsft 1.0 Mb/s 2437 MHz (0x00a0) 112dB
> signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
> 192.168.10.255: ICMP echo request, id 6662, seq 40960, length 8
>
> I get strange dbm values, in the range of 50 - 100dbm, which doesn't
> make much sense.
>
> Does anyone have an idea what value is being returned and if there is
> an error in the dbm calculation?
>
no, this has been on the TODO list for some time now.
(drivers/net/wireless/p54/txrx.c)
static int p54_rssi_to_dbm(struct p54_common *priv, int rssi)
{
int band = priv->hw->conf.channel->band;
if (priv->rxhw != 5)
return ((rssi * priv->rssical_db[band].mul) / 64 +
priv->rssical_db[band].add) / 4;
else
/*
* TODO: find the correct formula
*/
return ((rssi * priv->rssical_db[band].mul) / 64 +
priv->rssical_db[band].add) / 4;
}
the .mul & .add values can be retrieved from the p54spi_eeprom.h blob.
0x09, 0x00, 0xad, 0xde, /* PDR_RSSI_LINEAR_APPROXIMATION_CUSTOM */
0x0a, 0x01, 0x72, 0xfe, 0x1a, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
=> translates into: (best viewed with a fixed-width font)
.mul = 0x010a = 416 (base 10)
.add = 0xfe72 = -398
.longbow_unkn1 = 0x001a = 26
.longbow_unkn2 = 0x0000 = 0
---
stlc45xx has a completely different phy/rf (longbow - rxhw = 5) and
the specs are not a part of the freely available fw iface documentation.
here's the relevant quote from a Nokia official: "
> If this is so, what's so secret about the values that it needs a
> binary-only tool and hidden storage area? Is there legal issues with
> it (related to the radio device regulations)?
Yes, this is because regulatory requirements. So thank FCC and ETSI
for all this. This causes much grief for all wireless vendors, for
example Intel had to do major changes in iwl3945 firmware for their
mac80211 driver. "
(ref: http://www.mail-archive.com/stlc45xx-devel@garage.maemo.org/msg00021.html )
---
if you need real dBm reading for signal and noise, you have
to some "reverse engineering" on your own or find someone else
with the hardware and some spare time to burn.
Regards,
Chr
^ permalink raw reply
* p54spi: dbm_antsignal value, is it RSSI or dbm?
From: Andre K @ 2009-09-21 18:19 UTC (permalink / raw)
To: linux-wireless
Hi all,
I've been using the new p54spi driver on a couple of n800s. Some specifics:
Kernel : 2.6.29-omap1
Wireless-compat: compat-wireless-2009-08-22
OS: Maemo
Options: disabled CONFIG_RFKILL_BACKPORT_LEDS because it didn't compile
The driver loads and functions normally. However, the values for the
dbm_antsignal (from RadioTap header), are they RSSI or dbm? Initially
I thought they were dbm since tcpdump showed negative values, which
makes sense:
14:05:39.458831 8602124us tsft 1.0 Mb/s 2412 MHz (0x00a0) -46dB signal
-60dB noise antenna 0 [0x0000000e] Beacon (**SSID_REMOVED**) [1.0*
2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 Mbit] ESS CH: 1, PRIVACY
14:05:39.461090 8603807us tsft 1.0 Mb/s 2412 MHz (0x00a0) -52dB signal
-60dB noise antenna 0 [0x0000000e] Beacon (**SSID_REMOVED**) [1.0*
2.0* 5.5* 11.0* 6.0 12.0 24.0 36.0 Mbit] ESS CH: 1, PRIVACY
14:05:39.506713 8652588us tsft 1.0 Mb/s 2412 MHz (0x00a0) -52dB signal
-60dB noise antenna 0 [0x0000000e] Beacon (**SSID_REMOVED**) [1.0*
2.0* 5.5* 11.0* Mbit] ESS CH: 1, PRIVACY
14:05:39.541900 8687877us tsft 1.0 Mb/s 2412 MHz (0x00a0) -47dB signal
-60dB noise antenna 0 [0x0000000e] Beacon (**SSID_REMOVED**)[|802.11]
Output of iwconfig:
wlan0 IEEE 802.11bg Mode:Monitor Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
However, when I select a channel (6 in this case) its starts to behave
strangely:
Output of iwconfig:
wlan0 IEEE 802.11bg Mode:Monitor Frequency:2.437 GHz
Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Tcpdump:
14:08:25.312988 4469382526us tsft 2.0 Mb/s 2437 MHz (0x00a0) -49dB
signal -41dB noise antenna 0 [0x0000000e] Acknowledgment
RA:00:1d:e0:3d:5a:53 (oui Unknown)
14:08:25.313903 4469383345us tsft 1.0 Mb/s 2437 MHz (0x00a0) 4dB
signal -41dB noise antenna 0 [0x0000000e] 04:c2:08:00:07:07 (oui
Unknown) Unknown SSAP 0x0a >
Which shows up the first positive dbm value. Next I set up another
n800 to broadcast ping packets (using hping3, since busybox's ping
doesn't allow broadcast).
14:12:22.066192 13296010370us tsft 1.0 Mb/s 2437 MHz (0x00a0) 87dB
signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
192.168.10.255: ICMP echo request, id 6662, seq 40704, length 8
14:12:22.092376 13296036864us tsft 18.0 Mb/s 2437 MHz (0x00c0) 82dB
signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
192.168.10.255: ICMP echo request, id 6662, seq 40960, length 8
14:12:22.094787 13296037678us tsft 1.0 Mb/s 2437 MHz (0x00a0) 112dB
signal -62dB noise antenna 0 [0x0000000e] IP 192.168.10.11 >
192.168.10.255: ICMP echo request, id 6662, seq 40960, length 8
I get strange dbm values, in the range of 50 - 100dbm, which doesn't
make much sense.
Does anyone have an idea what value is being returned and if there is
an error in the dbm calculation?
Thanks,
Andre.
P.S. Would be happy to provide more info. and feedback.
^ permalink raw reply
* Re: [PATCH] mac80211: Fix [re]association power saving issue on AP side
From: Johannes Berg @ 2009-09-21 17:19 UTC (permalink / raw)
To: Igor Perminov; +Cc: John W. Linville, Jouni Malinen, linux-wireless
In-Reply-To: <1253200137.26765.338.camel@sunlight>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
Hi,
Jouni and I just discussed this and noticed that there are even more
things broken that your patch doesn't fix either, so we will need just
the last hunk of your patch (quoted below), and a one-line fix in
hostapd.
And then we can also remove the workaround from net/mac80211/cfg.c (the
entire EEXIST branch).
Thanks,
johannes
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -367,7 +367,10 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
> u32 staflags;
>
> - if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)))
> + if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)
> + || ieee80211_is_auth(hdr->frame_control)
> + || ieee80211_is_assoc_resp(hdr->frame_control)
> + || ieee80211_is_reassoc_resp(hdr->frame_control)))
> return TX_CONTINUE;
>
> staflags = get_sta_flags(sta);
>
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Problems with "cfg80211: fix SME connect" commit
From: Albert Herranz @ 2009-09-21 16:11 UTC (permalink / raw)
To: Holger Schurig; +Cc: johannes, linville, linux-wireless
In-Reply-To: <200909210845.51247.hs4233@mail.mn-solutions.de>
Holger Schurig wrote:
> Can you try "[PATCH] cfg80211: don't overwrite privacy setting"
> from [1]?
>
> [1] http://marc.info/?l=linux-wireless&m=125323296617306&w=2
>
>
> And can you use the mailing list archives? This is now the third
> time this poppep up, I just copied Sedat's mail for you.
>
Hi,
Thanks for the information.
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.
* master-20090914
[ 13.222940] b43-phy0 debug: Chip initialized
[ 13.291359] b43-phy0 debug: PIO initialized
[ 13.330116] b43-phy0 debug: QoS disabled
[ 13.861636] b43-phy0 debug: Wireless interface started
[ 13.969153] b43-phy0 debug: Adding Interface type 2
[ 16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
[ 16.700998] wlan1 direct probe responded
[ 16.707013] wlan1: authenticate with AP 00:12:17:15:e7:79 (try 1)
[ 16.720205] wlan1: authenticated
[ 16.726261] wlan1: associate with AP 00:12:17:15:e7:79 (try 1)
[ 16.740697] wlan1: RX AssocResp from 00:12:17:15:e7:79 (capab=0x431 status=0 aid=1)
[ 16.758042] wlan1: associated
* master-20090916 + "cfg80211: don't overwrite privacy setting"
[ 12.849778] b43-phy0 debug: Chip initialized
[ 12.865561] b43-phy0 debug: PIO initialized
[ 12.872482] b43-phy0 debug: QoS disabled
[ 13.053373] b43-phy0 debug: Wireless interface started
[ 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)
[ 16.145589] wlan1 direct probe responded
[ 16.154501] wlan1: authenticate with AP 00:12:17:15:e7:79 (try 1)
[ 16.175640] wlan1: authenticated
[ 16.181829] wlan1: associate with AP 00:12:17:15:e7:79 (try 1)
[ 16.198990] wlan1: RX AssocResp from 00:12:17:15:e7:79 (capab=0x431 status=0 aid=1)
[ 16.210791] wlan1: associated
Any comments on this?
Thanks,
Albert
^ permalink raw reply
* Re: BUG? I can reproduce "Association request to the driver failed" at will
From: Holger Schurig @ 2009-09-21 15:31 UTC (permalink / raw)
To: linux-wireless; +Cc: hostap
In-Reply-To: <200909211309.40476.hs4233@mail.mn-solutions.de>
Hmm, this seems to be racy. This morning I succeeded 3 times to
get that message, now I didn't on the first try. But now I
enabled verbose-mac80211-debugging ...
But on the second try, I succeeded again.
> Let wpa_supplicant associate.
phy10: Selected rate control algorithm 'minstrel'
ath5k phy10: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy10: RF2112B 2GHz radio found (0x46)
eth1: direct probe to AP 00:13:19:80:da:30 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:13:19:80:da:30 (try 1)
eth1: authenticated
eth1: associate with AP 00:13:19:80:da:30 (try 1)
eth1: RX AssocResp from 00:13:19:80:da:30 (capab=0x11 status=0
aid=114)
eth1: associated
> Turn one AP off. wpa_supplicant automatically associates to the
> second.
eth1: deauthenticated from 00:13:19:80:da:30 (Reason: 1)
eth1: direct probe to AP 00:13:19:80:da:30 (try 1)
eth1: direct probe to AP 00:13:19:80:da:30 (try 2)
eth1: direct probe to AP 00:13:19:80:da:30 (try 3)
eth1: direct probe to AP 00:13:19:80:da:30 timed out
eth1: direct probe to AP 00:1b:d4:44:35:90 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:1b:d4:44:35:90 (try 1)
eth1: authenticated
eth1: associate with AP 00:1b:d4:44:35:90 (try 1)
eth1: RX AssocResp from 00:1b:d4:44:35:90 (capab=0x11 status=0
aid=127)
eth1: associated
Side node: here mac80211 had stale scan data in the cache, thus
wpa_supplicant first asked it to authenticate to the
just-turned-off AP. You can see the three probes ...
> Now turn the first AP on again. Issue a manual scan command
eth1: direct probe to AP 00:13:19:80:da:30 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:13:19:80:da:30 (try 1)
eth1: authenticate with AP 00:13:19:80:da:30 (try 2)
eth1: authenticated
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: BUG: can bring wpa_supplicant/mac80211 into a stuck state at will
From: Holger Schurig @ 2009-09-21 15:22 UTC (permalink / raw)
To: hostap; +Cc: linux-wireless
In-Reply-To: <200909211259.45431.hs4233@mail.mn-solutions.de>
Johannes asked me off-list for dmesg output:
> First, it associates to the MNHS-AP:
eth1: direct probe to AP 00:13:19:80:da:30 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:13:19:80:da:30 (try 1)
eth1: authenticated
eth1: associate with AP 00:13:19:80:da:30 (try 1)
eth1: RX AssocResp from 00:13:19:80:da:30 (capab=0x11 status=0
aid=112)
eth1: associate
> Next I turn of the AP where I'm associated to. wpa_supplicant
> successfully associates to the WEP-based AP:
eth1: deauthenticated from 00:13:19:80:da:30 (Reason: 1)
eth1: direct probe to AP 00:1b:53:11:dc:40 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:1b:53:11:dc:40 (try 1)
eth1: authenticated
eth1: associate with AP 00:1b:53:11:dc:40 (try 1)
eth1: RX AssocResp from 00:1b:53:11:dc:40 (capab=0x11 status=0
aid=91)
eth1: associated
> Now I turn on again the MNHS AP. And then I issue a scan
> from the cmdline: "iw eth1 scan trigger freq 2412"
eth1: direct probe to AP 00:13:19:80:da:30 (try 1)
eth1 direct probe responded
eth1: authenticate with AP 00:13:19:80:da:30 (try 1)
eth1: authenticated
Also the output of "iw eth1 info":
iw eth1 link
Connected to 00:1b:53:11:dc:40 (on eth1)
SSID: MNFUNK
freq: 2412
Authenticated with 00:13:19:80:da:30 (on eth1)
RX: 78173 bytes (722 packets)
TX: 144 bytes (4 packets)
signal: -67 dBm
tx bitrate: 11.0 MBit/s
If I understand this right, then mac80211 thinks it's connected,
even before the 4-way key exchange?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Mel Gorman @ 2009-09-21 13:37 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Pekka Enberg, Luis R. Rodriguez, Tso Ted, Aneesh Kumar K.V,
Zhu Yi, Andrew Morton, Johannes Weiner, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <200909211512.14785.bzolnier@gmail.com>
On Mon, Sep 21, 2009 at 03:12:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Monday 21 September 2009 12:56:48 Pekka Enberg wrote:
> > On Mon, 2009-09-21 at 12:46 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > I don't know why people don't see it but for me it has a memory management
> > > > > regression and reliability issue written all over it.
> > > >
> > > > Possibly but drivers that reload their firmware as a response to an
> > > > error condition is relatively new and loading network drivers while the
> > > > system is already up and running a long time does not strike me as
> > > > typical system behaviour.
> > >
> > > Loading drivers after boot is a typical desktop/laptop behavior, please
> > > think about hotplug (the hardware in question is an USB dongle).
> >
> > Yeah, I wonder what broke things. Did the wireless stack change in
> > 2.6.31-rc1 too? IIRC Mel ruled out page allocator changes as a suspect.
>
> The thing is that the mm behavior change has been narrowed down already
> over a month ago to -mm merge in 2.6.31-rc1 (as has been noted in my initial
> reports), I first though that that it was -next breakage but it turned out
> that it came the other way around (because -mm is not even pulled into -next
> currently -- great way to set an example for other kernel maintainers BTW).
>
Is there a reliable reproduction case for this that narrowed it down to
2.6.31-rc1? That is the window where a number of page-allocator optimisation
patches made it in. None of them should have affected the allocator from a
fragmentation perspective though.
If you have a reliable reproduction case, testing between commits
d239171e4f6efd58d7e423853056b1b6a74f1446..a1dd268cf6306565a31a48deff8bf4f6b4b105f7
would be nice, particularly if it can be bisected within that small
window rather than a full bisect of an rc1 which I know can be a major
mess.
> I understand that behavior change may be justified and technically correct
> in itself. I also completely agree that high order allocations in certain
> drivers need fixing anyway.
>
> However there is something wrong with the big picture and the way changes
> are happening. I'm not saying that I'm surprised though, especially given
> the recent decline in the quality assurance and the paradigm shift that
> I'm seeing (some influential top level people talking that -rc1 is fine for
> testing new code now or the "new kernel new hardware" thing).
>
The quality assurance comment is a bit unfair with respect to the page
allocator. There are a lot of things that can have changed that would hose
order-6 atomic allocations. Furthermore, test cases used for mm patches
would not have taken into account such allocations as being critical. Even
if it was considered, it would have been dismissed as "it makes no sense
for drivers to be doing order-6 GFP_ATOMIC" allocations.
> Sorry but I have no more time currently to narrow down the issue some more
> (guess what, there are other kernel bugs standing in the way to bisect it
> and I would have to provide some reliable way to reproduce it first) so I
> see no more point in wasting people's time on this. I can certainly get by
> with allocation failure here and there. Not a big deal for me personally..
>
That is somewhat unfortunate. Even testing within the window above if
possible would be very helpful if you get the chance.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Bartlomiej Zolnierkiewicz @ 2009-09-21 13:12 UTC (permalink / raw)
To: Pekka Enberg
Cc: Mel Gorman, Luis R. Rodriguez, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Mel Gorman,
netdev@vger.kernel.org, linux-mm@kvack.org, James Ketrenos,
Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <1253530608.5216.17.camel@penberg-laptop>
On Monday 21 September 2009 12:56:48 Pekka Enberg wrote:
> On Mon, 2009-09-21 at 12:46 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > I don't know why people don't see it but for me it has a memory management
> > > > regression and reliability issue written all over it.
> > >
> > > Possibly but drivers that reload their firmware as a response to an
> > > error condition is relatively new and loading network drivers while the
> > > system is already up and running a long time does not strike me as
> > > typical system behaviour.
> >
> > Loading drivers after boot is a typical desktop/laptop behavior, please
> > think about hotplug (the hardware in question is an USB dongle).
>
> Yeah, I wonder what broke things. Did the wireless stack change in
> 2.6.31-rc1 too? IIRC Mel ruled out page allocator changes as a suspect.
The thing is that the mm behavior change has been narrowed down already
over a month ago to -mm merge in 2.6.31-rc1 (as has been noted in my initial
reports), I first though that that it was -next breakage but it turned out
that it came the other way around (because -mm is not even pulled into -next
currently -- great way to set an example for other kernel maintainers BTW).
I understand that behavior change may be justified and technically correct
in itself. I also completely agree that high order allocations in certain
drivers need fixing anyway.
However there is something wrong with the big picture and the way changes
are happening. I'm not saying that I'm surprised though, especially given
the recent decline in the quality assurance and the paradigm shift that
I'm seeing (some influential top level people talking that -rc1 is fine for
testing new code now or the "new kernel new hardware" thing).
Sorry but I have no more time currently to narrow down the issue some more
(guess what, there are other kernel bugs standing in the way to bisect it
and I would have to provide some reliable way to reproduce it first) so I
see no more point in wasting people's time on this. I can certainly get by
with allocation failure here and there. Not a big deal for me personally..
^ permalink raw reply
* BUG? I can reproduce "Association request to the driver failed" at will
From: Holger Schurig @ 2009-09-21 11:09 UTC (permalink / raw)
To: linux-wireless; +Cc: hostap
The following is an indication about yet another MLME problem:
Two APs, both set to the MNHS/WPA.
Let wpa_supplicant associate. Turn one AP off. wpa_supplicant
automatically associates to the second.
Now turn the first AP on again. Issue a manual scan command:
1253527140.577702: nl80211: Event message available
1253527140.577751: nl80211: Ignored unknown event (cmd=33)
1253527140.794448: nl80211: Event message available
1253527140.794490: nl80211: New scan results available
1253527140.794921: Received scan results (3 BSSes)
1253527140.794947: CTRL-EVENT-SCAN-RESULTS
1253527140.794960: Selecting BSS from priority group 0
1253527140.794972: Try to find WPA-enabled AP
1253527140.794984: 0: 00:13:19:80:da:30 ssid='MNWPA' wpa_ie_len=24 rsn_ie_len=0 caps=0x11
1253527140.795007: selected based on WPA IE
1253527140.795018: selected WPA AP 00:13:19:80:da:30 ssid='MNWPA'
1253527140.795035: Automatic auth_alg selection: 0x1
1253527140.795052: WPA: using IEEE 802.11i/D3.0
1253527140.795063: WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2 proto 1
1253527140.795079: WPA: set AP WPA IE - hexdump(len=26): dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 28 00
1253527140.795117: WPA: clearing AP RSN IE
1253527140.795129: WPA: using GTK TKIP
1253527140.795141: WPA: using PTK TKIP
1253527140.795154: WPA: using KEY_MGMT WPA-PSK
1253527140.795165: WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
1253527140.795203: Cancelling scan request
1253527140.795221: Trying to authenticate with 00:13:19:80:da:30 (SSID='MNWPA' freq=2412 MHz)
1253527140.795234: nl_set_encr: ifindex=34 alg=0 addr=0x8092a8e key_idx=0 set_tx=0 seq_len=0 key_len=0
1253527140.795286: nl_set_encr: ifindex=34 alg=0 addr=0x8092a8e key_idx=1 set_tx=0 seq_len=0 key_len=0
1253527140.795341: nl_set_encr: ifindex=34 alg=0 addr=0x8092a8e key_idx=2 set_tx=0 seq_len=0 key_len=0
1253527140.795389: nl_set_encr: ifindex=34 alg=0 addr=0x8092a8e key_idx=3 set_tx=0 seq_len=0 key_len=0
1253527140.795435: nl_set_encr: ifindex=34 alg=0 addr=0x91ce96c key_idx=0 set_tx=0 seq_len=0 key_len=0
1253527140.795460: addr=00:13:19:80:da:30
1253527140.795498: State: COMPLETED -> AUTHENTICATING
1253527140.795515: EAPOL: External notification - EAP success=0
1253527140.795530: EAPOL: External notification - EAP fail=0
1253527140.795542: EAPOL: External notification - portControl=Auto
1253527140.795559: nl80211: Authenticate (ifindex=34)
1253527140.795572: * bssid=00:13:19:80:da:30
1253527140.795587: * freq=2412
1253527140.795598: * SSID - hexdump_ascii(len=5):
4d 4e 57 50 41 MNWPA
1253527140.795630: * IEs - hexdump(len=0): [NULL]
1253527140.795643: * Auth Type 0
1253527140.795683: nl80211: Authentication request send successfully
1253527140.795707: RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
1253527140.795725: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1253527140.953161: nl80211: Event message available
1253527140.953200: nl80211: MLME event 37
1253527140.953216: SME: Authentication response: peer=00:13:19:80:da:30 auth_type=0 status_code=0
1253527140.953243: Trying to associate with 00:13:19:80:da:30 (SSID='MNWPA' freq=2412 MHz)
1253527140.953257: State: AUTHENTICATING -> ASSOCIATING
1253527140.953270: wpa_driver_nl80211_set_operstate: operstate 1->0 (DORMANT)
1253527140.953284: nl80211: Operstate: linkmode=-1, operstate=5
1253527140.953901: nl80211: Associate (ifindex=34)
1253527140.953919: * bssid=00:13:19:80:da:30
1253527140.953934: * freq=2412
1253527140.953945: * SSID - hexdump_ascii(len=5):
4d 4e 57 50 41 MNWPA
1253527140.953977: * IEs - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
1253527140.954064: nl80211: MLME command failed: ret=-114 (Operation already in progress)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1253527140.954086: Association request to the driver failed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1253527140.954113: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
1253527140.954131: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
The "Association request to the driver failed" will
be shown even without "-d". Also note that the association
seems to actually work, e.g. I can ping throught the
connection.
--
http://www.holgerschurig.de
^ 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