* 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
* Re: ipw2200: firmware DMA loading rework
From: Mel Gorman @ 2009-09-21 11:02 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Luis R. Rodriguez, Tso Ted, Aneesh Kumar K.V, Zhu Yi,
Andrew Morton, Johannes Weiner, Pekka Enberg, 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: <200909211246.34774.bzolnier@gmail.com>
On Mon, Sep 21, 2009 at 12:46:34PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > <SNIP>
> > > > >
> > > > > This time it is an order-6 page allocation failure for rt2870sta
> > > > > (w/ upcoming driver changes) and Linus' tree from few days ago..
> > > > >
> > > >
> > > > It's another high-order atomic allocation which is difficult to grant.
> > > > I didn't look closely, but is this the same type of thing - large allocation
> > > > failure during firmware loading? If so, is this during resume or is the
> > > > device being reloaded for some other reason?
> > >
> > > Just modprobing the driver on a system running for some time.
> > >
> >
> > Was this a common situation before?
>
> Yes, just like firmware restarts with ipw2200.
>
> > > > I suspect that there are going to be a few of these bugs cropping up
> > > > every so often where network devices are assuming large atomic
> > > > allocations will succeed because the "only time they happen" is during
> > > > boot but these days are happening at runtime for other reasons.
> > >
> > > I wouldn't go so far as calling a normal order-6 (256kB) allocation on
> > > 512MB machine with 1024MB swap a bug. Moreover such failures just never
> > > happened before 2.6.31-rc1.
> >
> > It's not that normal, it's an allocation that cannot sleep and cannot
> > reclaim. Why is something like firmware loading allocating memory like
>
> OK.
>
> > that? Is this use of GFP_ATOMIC relatively recent or has it always been
> > that way?
>
> It has always been like that.
>
Nuts, why is firmware loading depending on GFP_ATOMIC?
> > > 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).
>
In that case, how reproducible is this problem so it can be
bisected? Basically, there are no guarantees that GFP_ATOMIC allocations
of this order will succeed although you can improve the odds by increasing
min_free_kbytes. Network drivers should never have been depending on GFP_ATOMIC
succeeding like this but the hole has been dug now.
If it's happening more frequently now than it used to then either
1. The allocations are occuring more frequently where as previously a
pool might have been reused or the memory not freed for the lifetime of
the system.
2. Something has changed in the allocator. I'm not aware of recent
changes that could cause this though in such a recent time-frame.
3. Something has changed recently with respect to reclaim. There have
been changes made recently to lumpy reclaim and that might be impacting
kswapd's efforts at keeping large contiguous regions free.
4. Hotplug events that involve driver loads are more common now than they
were previously for some reason. You mention that this is a USB dongle for
example. Was it a case before that the driver loaded early and remained
resident but only active after a hotplug event? If that was the case,
the memory would be allocated once at boot. However, if an optimisation
made recently unloads those unused drivers and re-loads them later, there
would be more order-6 allocations than they were previously and manifest
as these bug reports. Is this a possibility?
The ideal would be that network drivers not make allocations like this
in the first place by, for example, DMAing the firmware across in
page-size chunks instead of one contiguous lump :/
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* BUG: can bring wpa_supplicant/mac80211 into a stuck state at will
From: Holger Schurig @ 2009-09-21 10:59 UTC (permalink / raw)
To: hostap; +Cc: linux-wireless
Steps to reproduce:
network={
ssid="MNHS"
key_mgmt=NONE
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
psk="99999999"
scan_freq=2412
}
network={
ssid="MNFUNK"
key_mgmt=NONE
wep_key0="99999"
scan_freq=2412
}
Also two APs, MNHS/WPA2 and MNFUNK/WEP.
Current wireless-testing from GIT + patch "cfg80211: don't
overwrite privacy setting"
Current wpa_supplicant from GIT.
Command: ./wpa_supplicant -i eth1 -D nl80211 -t -c mnhs.conf -d
First, it associates to the MNHS-AP:
...
1253526128.147011: selected based on RSN IE
1253526128.147024: selected WPA AP 00:13:19:80:da:30 ssid='MNHS'
...
1253526128.436265: Associated to a new BSS: BSSID=00:13:19:80:da:30
1253526128.436280: No keys have been configured - skip key clearing
1253526128.436297: Associated with 00:13:19:80:da:30
...
1253526128.470149: CTRL-EVENT-CONNECTED - Connection to 00:13:19:80:da:30 completed (auth) [id=0 id_str=]
...
Fine so far.
Next I turn of the AP where I'm associated to. wpa_supplicant
successfully associates to the WEP-based AP:
...
1253526139.247356: Setting scan request: 0 sec 100000 usec
1253526139.247373: Added BSSID 00:13:19:80:da:30 into blacklist
...
1253526139.727196: selected non-WPA AP 00:1b:53:11:dc:40 ssid='MNFUNK'
...
1253526140.025300: Associated to a new BSS: BSSID=00:1b:53:11:dc:40
1253526140.025320: Associated with 00:1b:53:11:dc:40
...
1253526140.025654: CTRL-EVENT-CONNECTED - Connection to 00:1b:53:11:dc:40 completed (reauth) [id=1 id_str=]
...
Now I turn on again the MNHS AP. And then I issue a scan
from the cmdline: "iw eth1 scan trigger freq 2412"
And now it's getting interesting:
...
1253526175.739000: Received scan results (3 BSSes)
...
1253526175.739064: 0: 00:13:19:80:da:30 ssid='MNHS' wpa_ie_len=0 rsn_ie_len=20 caps=0x11
1253526175.739087: selected based on RSN IE
1253526175.739098: selected WPA AP 00:13:19:80:da:30 ssid='MNHS'
1253526175.739115: Automatic auth_alg selection: 0x1
1253526175.739133: RSN: using IEEE 802.11i/D9.0
1253526175.739144: WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 proto 2
1253526175.739160: WPA: clearing AP WPA IE
1253526175.739171: WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 28 00
1253526175.739206: WPA: using GTK CCMP
1253526175.739219: WPA: using PTK CCMP
1253526175.739231: WPA: using KEY_MGMT WPA-PSK
1253526175.739243: WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00
1253526175.739280: Cancelling scan request
1253526175.739298: Trying to authenticate with 00:13:19:80:da:30 (SSID='MNHS' freq=2412 MHz)
1253526175.739312: nl_set_encr: ifindex=34 alg=0 addr=0x8092a8e key_idx=0 set_tx=0 seq_len=0 key_len=0
1253526175.739370: nl_set_encr: ifindex=34 alg=0 addr=0x8092a8e key_idx=1 set_tx=0 seq_len=0 key_len=0
1253526175.739420: nl_set_encr: ifindex=34 alg=0 addr=0x8092a8e key_idx=2 set_tx=0 seq_len=0 key_len=0
1253526175.739466: nl_set_encr: ifindex=34 alg=0 addr=0x8092a8e key_idx=3 set_tx=0 seq_len=0 key_len=0
1253526175.739512: nl_set_encr: ifindex=34 alg=0 addr=0x84e1b34 key_idx=0 set_tx=0 seq_len=0 key_len=0
1253526175.739537: addr=00:13:19:80:da:30
1253526175.739575: State: COMPLETED -> AUTHENTICATING
1253526175.739593: EAPOL: External notification - EAP success=0
1253526175.739609: EAPOL: External notification - EAP fail=0
1253526175.739622: EAPOL: External notification - portControl=Auto
1253526175.739634: EAPOL: SUPP_PAE entering state DISCONNECTED
1253526175.739646: EAPOL: Supplicant port status: Unauthorized
1253526175.739713: EAPOL: SUPP_BE entering state INITIALIZE
1253526175.739732: EAPOL: SUPP_PAE entering state CONNECTING
1253526175.739744: EAPOL: enable timer tick
1253526175.739757: EAPOL: SUPP_BE entering state IDLE
1253526175.739773: nl80211: Authenticate (ifindex=34)
1253526175.739787: * bssid=00:13:19:80:da:30
1253526175.739802: * freq=2412
1253526175.739813: * SSID - hexdump_ascii(len=4):
4d 4e 48 53 MNHS
1253526175.739845: * IEs - hexdump(len=0): [NULL]
1253526175.739858: * Auth Type 0
1253526175.739899: nl80211: Authentication request send successfully
1253526175.739918: RSN: Ignored PMKID candidate without preauth flag
1253526175.739936: RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
1253526175.739954: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1253526175.954553: nl80211: Event message available
1253526175.954592: nl80211: MLME event 37
1253526175.954608: SME: Authentication response: peer=00:13:19:80:da:30 auth_type=0 status_code=0
1253526175.954635: Trying to associate with 00:13:19:80:da:30 (SSID='MNHS' freq=2412 MHz)
1253526175.954649: State: AUTHENTICATING -> ASSOCIATING
1253526175.954662: wpa_driver_nl80211_set_operstate: operstate 1->0 (DORMANT)
1253526175.954677: nl80211: Operstate: linkmode=-1, operstate=5
1253526175.955294: nl80211: Associate (ifindex=34)
1253526175.955312: * bssid=00:13:19:80:da:30
1253526175.955327: * freq=2412
1253526175.955338: * SSID - hexdump_ascii(len=4):
4d 4e 48 53 MNHS
1253526175.955370: * IEs - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00
1253526175.955456: nl80211: MLME command failed: ret=-114 (Operation already in progress)
1253526175.955479: Association request to the driver failed
1253526175.955512: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
1253526175.955530: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1253526178.742658: EAPOL: startWhen --> 0
1253526178.742678: EAPOL: disable timer tick
1253526178.742690: EAPOL: SUPP_PAE entering state CONNECTING
1253526178.742701: EAPOL: enable timer tick
1253526178.742714: EAPOL: txStart
1253526178.742725: WPA: drop TX EAPOL in non-IEEE 802.1X mode (type=1 len=0)
1253526208.774009: EAPOL: startWhen --> 0
1253526208.774043: EAPOL: disable timer tick
1253526208.774055: EAPOL: SUPP_PAE entering state CONNECTING
1253526208.774066: EAPOL: enable timer tick
1253526208.774079: EAPOL: txStart
1253526208.774090: WPA: drop TX EAPOL in non-IEEE 802.1X mode (type=1 len=0)
1253526238.805764: EAPOL: startWhen --> 0
1253526238.805790: EAPOL: disable timer tick
1253526238.805802: EAPOL: SUPP_PAE entering state CONNECTING
1253526238.805814: EAPOL: enable timer tick
1253526238.805827: EAPOL: txStart
1253526238.805838: WPA: drop TX EAPOL in non-IEEE 802.1X mode (type=1 len=0)
1253526268.837109: EAPOL: startWhen --> 0
1253526268.837130: EAPOL: disable timer tick
1253526268.837143: EAPOL: SUPP_PAE entering state HELD
1253526268.837154: EAPOL: enable timer tick
1253526268.837166: EAPOL: Supplicant port status: Unauthorized
1253526268.837296: EAPOL authentication completed unsuccessfully
1253526268.837322: Setting authentication timeout: 2 sec 0 usec
1253526270.838400: Authentication with 00:13:19:80:da:30 timed out.
1253526270.838421: BSSID 00:13:19:80:da:30 blacklist count incremented to 2
1253526270.838440: No keys have been configured - skip key clearing
1253526270.838453: State: ASSOCIATING -> DISCONNECTED
1253526270.838466: wpa_driver_nl80211_set_operstate: operstate 0->0 (DORMANT)
1253526270.838481: nl80211: Operstate: linkmode=-1, operstate=5
1253526270.838506: EAPOL: External notification - portEnabled=0
1253526270.838520: EAPOL: SUPP_PAE entering state DISCONNECTED
1253526270.838532: EAPOL: Supplicant port status: Unauthorized
1253526270.838600: EAPOL: SUPP_BE entering state INITIALIZE
1253526270.838619: EAPOL: Supplicant port status: Unauthorized
1253526270.838679: EAPOL: External notification - portValid=0
1253526270.838697: EAPOL: Supplicant port status: Unauthorized
1253526270.838755: EAPOL: External notification - EAP success=0
1253526270.838772: EAPOL: Supplicant port status: Unauthorized
1253526270.838837: Setting scan request: 0 sec 0 usec
1253526270.838867: EAPOL: Supplicant port status: Unauthorized
1253526270.838936: State: DISCONNECTED -> SCANNING
1253526270.838959: Starting AP scan for wildcard SSID
1253526270.839130: Scan requested (ret=0) - scan timeout 30 seconds
1253526270.839165: nl80211: Event message available
1253526270.839193: nl80211: Ignored unknown event (cmd=33)
1253526271.839909: EAPOL: Supplicant port status: Unauthorized
1253526272.840948: EAPOL: Supplicant port status: Unauthorized
1253526273.841988: EAPOL: Supplicant port status: Unauthorized
1253526274.843028: EAPOL: Supplicant port status: Unauthorized
1253526275.844068: EAPOL: Supplicant port status: Unauthorized
1253526276.845110: EAPOL: Supplicant port status: Unauthorized
1253526277.846150: EAPOL: Supplicant port status: Unauthorized
1253526278.847174: EAPOL: Supplicant port status: Unauthorized
1253526279.848214: EAPOL: Supplicant port status: Unauthorized
1253526280.849255: EAPOL: Supplicant port status: Unauthorized
1253526281.850294: EAPOL: Supplicant port status: Unauthorized
1253526282.851334: EAPOL: Supplicant port status: Unauthorized
1253526283.852374: EAPOL: Supplicant port status: Unauthorized
1253526284.853414: EAPOL: Supplicant port status: Unauthorized
1253526285.854454: EAPOL: Supplicant port status: Unauthorized
1253526286.855495: EAPOL: Supplicant port status: Unauthorized
1253526287.856534: EAPOL: Supplicant port status: Unauthorized
1253526288.857574: EAPOL: Supplicant port status: Unauthorized
1253526289.858613: EAPOL: Supplicant port status: Unauthorized
1253526290.859653: EAPOL: Supplicant port status: Unauthorized
1253526291.860693: EAPOL: Supplicant port status: Unauthorized
1253526292.861733: EAPOL: Supplicant port status: Unauthorized
1253526293.862773: EAPOL: Supplicant port status: Unauthorized
1253526294.863813: EAPOL: Supplicant port status: Unauthorized
1253526295.864853: EAPOL: Supplicant port status: Unauthorized
... AD INIFINITUM ...
--
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