* Re: ieee80211_tx_status: headroom too small
From: Johannes Berg @ 2009-10-31 9:25 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Nikolai ZHUBR, linux-wireless
In-Reply-To: <200910310959.43260.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
On Sat, 2009-10-31 at 09:59 +0100, Ivo van Doorn wrote:
> On Saturday 31 October 2009, Johannes Berg wrote:
> > On Sat, 2009-10-31 at 09:51 +0100, Ivo van Doorn wrote:
> >
> > > > Ok. I looked at the problem and it's a very odd problem -- mac80211
> > > > should always reserve enough headroom in buffers it passes to the
> > > > driver. Does rt61pci somehow realloc frames?
> > >
> > > It does use skb_push. but will/should always stay within the limits
> > > of rt2x00dev->hw->extra_tx_headroom. Although I just realize there
> > > might be a situation where it needs to align the frame to a 4-byte boundary,
> > > it could exceed that amount. :(
> >
> > extra_tx_headroom is set to max_t(driver, mac80211) so that there's
> > always some headroom. This doesn't take into account alignment though.
> > Should we simply add 2 to that value?
>
> 4 actually, wasn't there some cases where the header could have an odd
> number of bytes and would require 3 bytes for alignment?
Hm, is there? I thought they changed the 11s draft to no longer have
that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: ieee80211_tx_status: headroom too small
From: Ivo van Doorn @ 2009-10-31 9:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: Nikolai ZHUBR, linux-wireless
In-Reply-To: <1256981113.3555.92.camel@johannes.local>
On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 09:59 +0100, Ivo van Doorn wrote:
> > On Saturday 31 October 2009, Johannes Berg wrote:
> > > On Sat, 2009-10-31 at 09:51 +0100, Ivo van Doorn wrote:
> > >
> > > > > Ok. I looked at the problem and it's a very odd problem -- mac80211
> > > > > should always reserve enough headroom in buffers it passes to the
> > > > > driver. Does rt61pci somehow realloc frames?
> > > >
> > > > It does use skb_push. but will/should always stay within the limits
> > > > of rt2x00dev->hw->extra_tx_headroom. Although I just realize there
> > > > might be a situation where it needs to align the frame to a 4-byte boundary,
> > > > it could exceed that amount. :(
> > >
> > > extra_tx_headroom is set to max_t(driver, mac80211) so that there's
> > > always some headroom. This doesn't take into account alignment though.
> > > Should we simply add 2 to that value?
> >
> > 4 actually, wasn't there some cases where the header could have an odd
> > number of bytes and would require 3 bytes for alignment?
>
> Hm, is there? I thought they changed the 11s draft to no longer have
> that.
Well 2 is fine in that case, (I was basing my comment on something said on this mailinglist
a long time ago). :)
Ivo
^ permalink raw reply
* Re: ieee80211_tx_status: headroom too small
From: Johannes Berg @ 2009-10-31 9:34 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Nikolai ZHUBR, linux-wireless
In-Reply-To: <200910311030.45582.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 763 bytes --]
On Sat, 2009-10-31 at 10:30 +0100, Ivo van Doorn wrote:
> > > 4 actually, wasn't there some cases where the header could have an odd
> > > number of bytes and would require 3 bytes for alignment?
> >
> > Hm, is there? I thought they changed the 11s draft to no longer have
> > that.
>
> Well 2 is fine in that case, (I was basing my comment on something said on this mailinglist
> a long time ago). :)
However, it really all depends on the hardware too ... Maybe we should
put more of the logic into drivers, and have mac80211 only export its
required headroom?
Or maybe we should just not bother with having drivers do the alignment
any more -- mac80211 does that now and it only does it if necessary
(i.e. not on powerpc/x86)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] nl80211: allow to authenticate to access point that we already authenticated
From: Maxim Levitsky @ 2009-10-31 9:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, hostap@lists.shmoo.com
In-Reply-To: <1256967840.3555.70.camel@johannes.local>
On Sat, 2009-10-31 at 06:44 +0100, Johannes Berg wrote:
> On Fri, 2009-10-30 at 23:54 +0200, Maxim Levitsky wrote:
> > >From 02be2525b95ec3c57323dda1a9e0c6da3a9817e6 Mon Sep 17 00:00:00 2001
> > From: Maxim Levitsky <maximlevitsky@gmail.com>
> > Date: Fri, 30 Oct 2009 23:50:27 +0200
> > Subject: [PATCH 2/2] nl80211: allow to authenticate to access point that we already authenticated
> >
> > This is permitted by standards, and used by driver_nl80211 of wpa_supplicant
> > Just start new authentication as if we weren't authenticated before
>
> NACK. This leaks the auth request here and in mac80211, so we cannot do
> it this simply. Again though, the case you're running into should be
> fixed by that wpa_supplicant patch.
I was afraid of that... oh well thanks.
Best regards,
Maxim Levitsky
>
> johannes
>
> > ---
> > net/wireless/mlme.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
> > index 83c2a28..3d91b4e 100644
> > --- a/net/wireless/mlme.c
> > +++ b/net/wireless/mlme.c
> > @@ -372,7 +372,7 @@ int __cfg80211_mlme_auth(struct cfg80211_registered_device *rdev,
> > if (wdev->auth_bsses[i] &&
> > memcmp(bssid, wdev->auth_bsses[i]->pub.bssid,
> > ETH_ALEN) == 0)
> > - return -EALREADY;
> > + wdev->auth_bsses[i] = NULL;
> > }
> >
> > memset(&req, 0, sizeof(req));
>
^ permalink raw reply
* Re: ieee80211_tx_status: headroom too small
From: Ivo van Doorn @ 2009-10-31 9:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: Nikolai ZHUBR, linux-wireless
In-Reply-To: <1256981677.3555.94.camel@johannes.local>
On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 10:30 +0100, Ivo van Doorn wrote:
>
> > > > 4 actually, wasn't there some cases where the header could have an odd
> > > > number of bytes and would require 3 bytes for alignment?
> > >
> > > Hm, is there? I thought they changed the 11s draft to no longer have
> > > that.
> >
> > Well 2 is fine in that case, (I was basing my comment on something said on this mailinglist
> > a long time ago). :)
>
> However, it really all depends on the hardware too ... Maybe we should
> put more of the logic into drivers, and have mac80211 only export its
> required headroom?
>
> Or maybe we should just not bother with having drivers do the alignment
> any more -- mac80211 does that now and it only does it if necessary
> (i.e. not on powerpc/x86)
I think you mean the RX alignment, while I am talking about the TX alignment.
Beacons and some othe frames must be 4-byte alignment because the wireleless
hardware requires it.
Ivo
^ permalink raw reply
* Re: [PATCH 1/2] Allow scanning while in authenticated only state
From: Maxim Levitsky @ 2009-10-31 9:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, hostap@lists.shmoo.com
In-Reply-To: <1256967782.3555.69.camel@johannes.local>
On Sat, 2009-10-31 at 06:43 +0100, Johannes Berg wrote:
> On Fri, 2009-10-30 at 23:52 +0200, Maxim Levitsky wrote:
> > >From 1d13f997f652c7e632d4ddb053df3f3fad78da23 Mon Sep 17 00:00:00 2001
> > From: Maxim Levitsky <maximlevitsky@gmail.com>
> > Date: Fri, 30 Oct 2009 23:36:20 +0200
> > Subject: [PATCH 1/2] Allow scanning while in authenticated only state
> >
> > Since ifmgd->work_list is {ab}used as a storage for authenticated,
> > but not associated access points (this is done using idle work items),
> > allow scanning if all work items are in this state.
> >
> > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
>
> I don't think this is needed. While not _strictly_ wrong, I still
> dislike the additional complexity.
>
> I think you just need this wpa_supplicant patch:
> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
Nope, this patch doesn't help.
if I remove the bssid_changed, then it seems to work when connecting to
same AP, but still scan hangs when connecting to different.
The problem is that wpa_supplicant doesn't do deauthentication
explicitly, and I was told that this is right thing to do. This confuses
all the nl80211 and mac80211...
I also think that its best just to do both deauthentication and
disassociation in same time.
Yet, I think this path is ok, that is, when you disallow scanning, you
can be sure that wifi will be dead, and this patch catches the situation
when it for sure will disallowed forever.
Best regards,
Maxim Levitsky
>
> johannes
>
> > ---
> > net/mac80211/scan.c | 12 +++++++++---
> > 1 files changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
> > index c46ac01..c932765 100644
> > --- a/net/mac80211/scan.c
> > +++ b/net/mac80211/scan.c
> > @@ -418,6 +418,7 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
> > {
> > struct ieee80211_local *local = sdata->local;
> > struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> > + struct ieee80211_mgd_work *wk, *tmp;
> > int rc;
> >
> > if (local->scan_req)
> > @@ -450,9 +451,14 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
> > if (req != local->int_scan_req &&
> > sdata->vif.type == NL80211_IFTYPE_STATION &&
> > !list_empty(&ifmgd->work_list)) {
> > - /* actually wait for the work it's doing to finish/time out */
> > - set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
> > - return 0;
> > +
> > + /* actually wait for the work it's doing to finish/time out*/
> > + list_for_each_entry_safe(wk, tmp, &ifmgd->work_list, list) {
> > + if (wk->state != IEEE80211_MGD_STATE_IDLE) {
> > + set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
> > + return 0;
> > + }
> > + }
> > }
> >
> > if (local->ops->hw_scan)
>
^ permalink raw reply
* Re: [PATCH 1/2] Allow scanning while in authenticated only state
From: Johannes Berg @ 2009-10-31 10:02 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless, hostap@lists.shmoo.com
In-Reply-To: <1256982381.3089.10.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]
On Sat, 2009-10-31 at 11:46 +0200, Maxim Levitsky wrote:
> > I think you just need this wpa_supplicant patch:
> > http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
>
> Nope, this patch doesn't help.
>
> if I remove the bssid_changed, then it seems to work when connecting to
> same AP, but still scan hangs when connecting to different.
Hmm, Luis said it worked when connecting to a different AP. But he got
assoc refused and/or disassoc from the AP
> The problem is that wpa_supplicant doesn't do deauthentication
> explicitly, and I was told that this is right thing to do. This confuses
> all the nl80211 and mac80211...
I thought Jouni committed that workaround. I'm still not convinced that
wpa_supplicant is doing the right thing.
> I also think that its best just to do both deauthentication and
> disassociation in same time.
But then why do we bother?
> Yet, I think this path is ok, that is, when you disallow scanning, you
> can be sure that wifi will be dead, and this patch catches the situation
> when it for sure will disallowed forever.
True, in some sense, but the real problem is that the authentication is
lingering along. If we really need to clean that up in the kernel then
we'd have to time out authentication structs that didn't get promoted to
association, instead of just ignoring them like your two patches
implement [1]. However, since we put control of all this into
wpa_supplicant, I don't know whether the kernel really should be
required to clean up -- I was going to write "clean up after it" but
that's not true [2], you're proposing that the kernel clean up *while*
wpa_supplicant is in control. I don't think that's right, since it might
actually want to hang on for an authentication while doing something
else, for a while at least. How can we calculate an upper bound on that
in the kernel?
Now, I can kinda agree that we should allow authentication frames to go
through while already authenticated, but that's something quite
different although your patches here would also allow that in some
hackish way (by accumulating more and more authentication structs that
are then ignored).
Now, especially since you say that this still runs into problems while
connecting to a new AP, I think that wpa_supplicant should
deauthenticate from the old AP. After all, it wants to eventually
control FT and anything we do in the kernel will come back and interfere
with that.
johannes
[1] and that'd have to be in cfg80211
[2] Except when the interface is taken down, but that is already cleaned
up by cfg80211.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: ieee80211_tx_status: headroom too small
From: Johannes Berg @ 2009-10-31 10:03 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Nikolai ZHUBR, linux-wireless
In-Reply-To: <200910311044.45687.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Sat, 2009-10-31 at 10:44 +0100, Ivo van Doorn wrote:
> > Or maybe we should just not bother with having drivers do the alignment
> > any more -- mac80211 does that now and it only does it if necessary
> > (i.e. not on powerpc/x86)
>
> I think you mean the RX alignment, while I am talking about the TX alignment.
> Beacons and some othe frames must be 4-byte alignment because the wireleless
> hardware requires it.
Oh, indeed, I got confused.
Hmm. TX alignment is weird ... no driver really needs that except rt2x00
afaik. Which frames require this?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: ieee80211_tx_status: headroom too small
From: Ivo van Doorn @ 2009-10-31 10:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Nikolai ZHUBR, linux-wireless
In-Reply-To: <1256983432.3555.121.camel@johannes.local>
On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 10:44 +0100, Ivo van Doorn wrote:
>
> > > Or maybe we should just not bother with having drivers do the alignment
> > > any more -- mac80211 does that now and it only does it if necessary
> > > (i.e. not on powerpc/x86)
> >
> > I think you mean the RX alignment, while I am talking about the TX alignment.
> > Beacons and some othe frames must be 4-byte alignment because the wireleless
> > hardware requires it.
>
> Oh, indeed, I got confused.
>
> Hmm. TX alignment is weird ... no driver really needs that except rt2x00
> afaik. Which frames require this?
At the least the beacons, but I am not sure about if there are other frame types
which also have this requirement.
Users had reported that if they align beacon frames, rt2500pci finally starts
beaconing correctly in master mode.
Ivo
^ permalink raw reply
* Re: ieee80211_tx_status: headroom too small
From: Johannes Berg @ 2009-10-31 10:23 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Nikolai ZHUBR, linux-wireless
In-Reply-To: <200910311117.22300.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
On Sat, 2009-10-31 at 11:17 +0100, Ivo van Doorn wrote:
> At the least the beacons, but I am not sure about if there are other frame types
> which also have this requirement.
So you align them all right now? Just wondering since beacons shouldn't
be status-reported.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: ieee80211_tx_status: headroom too small
From: Ivo van Doorn @ 2009-10-31 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: Nikolai ZHUBR, linux-wireless
In-Reply-To: <1256984615.3555.122.camel@johannes.local>
On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 11:17 +0100, Ivo van Doorn wrote:
>
> > At the least the beacons, but I am not sure about if there are other frame types
> > which also have this requirement.
>
> So you align them all right now? Just wondering since beacons shouldn't
> be status-reported.
Currently I do all, but that is because I am not sure which specific frames
require it. I might just fix this for beacons only and just see what happens
with the other frames.
Ivo
^ permalink raw reply
* Re: [PATCH 1/2] Allow scanning while in authenticated only state
From: Maxim Levitsky @ 2009-10-31 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, hostap@lists.shmoo.com
In-Reply-To: <1256983366.3555.119.camel@johannes.local>
On Sat, 2009-10-31 at 11:02 +0100, Johannes Berg wrote:
> On Sat, 2009-10-31 at 11:46 +0200, Maxim Levitsky wrote:
>
> > > I think you just need this wpa_supplicant patch:
> > > http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
> >
> > Nope, this patch doesn't help.
> >
> > if I remove the bssid_changed, then it seems to work when connecting to
> > same AP, but still scan hangs when connecting to different.
>
> Hmm, Luis said it worked when connecting to a different AP. But he got
> assoc refused and/or disassoc from the AP
>
> > The problem is that wpa_supplicant doesn't do deauthentication
> > explicitly, and I was told that this is right thing to do. This confuses
> > all the nl80211 and mac80211...
>
> I thought Jouni committed that workaround. I'm still not convinced that
> wpa_supplicant is doing the right thing.
>
> > I also think that its best just to do both deauthentication and
> > disassociation in same time.
>
> But then why do we bother?
>
> > Yet, I think this path is ok, that is, when you disallow scanning, you
> > can be sure that wifi will be dead, and this patch catches the situation
> > when it for sure will disallowed forever.
>
> True, in some sense, but the real problem is that the authentication is
> lingering along. If we really need to clean that up in the kernel then
> we'd have to time out authentication structs that didn't get promoted to
> association, instead of just ignoring them like your two patches
> implement [1]. However, since we put control of all this into
> wpa_supplicant, I don't know whether the kernel really should be
> required to clean up -- I was going to write "clean up after it" but
> that's not true [2], you're proposing that the kernel clean up *while*
> wpa_supplicant is in control. I don't think that's right, since it might
> actually want to hang on for an authentication while doing something
> else, for a while at least. How can we calculate an upper bound on that
> in the kernel?
>
> Now, I can kinda agree that we should allow authentication frames to go
> through while already authenticated, but that's something quite
> different although your patches here would also allow that in some
> hackish way (by accumulating more and more authentication structs that
> are then ignored).
>
> Now, especially since you say that this still runs into problems while
> connecting to a new AP, I think that wpa_supplicant should
> deauthenticate from the old AP. After all, it wants to eventually
> control FT and anything we do in the kernel will come back and interfere
> with that.
Exactly, at least for now.
How about putting this in wpa_supplicant, and end all trouble with this
for once?
This is a workaround/hack, but at least it works....
Best regards,
Maxim Levitsky
---
commit e57bfd6e760c32177ab74c462839dd20a92343b8
Author: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Sat Oct 31 12:05:35 2009 +0200
driver_nl80211: send deauth on disassoc
diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
index b3861f5..dfed87d 100644
--- a/src/drivers/driver_nl80211.c
+++ b/src/drivers/driver_nl80211.c
@@ -2046,12 +2046,18 @@ static int wpa_driver_nl80211_deauthenticate(void *priv, const u8 *addr,
static int wpa_driver_nl80211_disassociate(void *priv, const u8 *addr,
int reason_code)
{
+ int err;
struct wpa_driver_nl80211_data *drv = priv;
if (!(drv->capa.flags & WPA_DRIVER_FLAGS_SME))
return wpa_driver_nl80211_disconnect(drv, addr, reason_code);
wpa_printf(MSG_DEBUG, "%s", __func__);
drv->associated = 0;
- return wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DISASSOCIATE,
+
+ err = wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DISASSOCIATE,
+ reason_code);
+ if (err)
+ return err;
+ return wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DEAUTHENTICATE,
reason_code);
}
^ permalink raw reply related
* Re: [PATCH 1/2] Allow scanning while in authenticated only state
From: Johannes Berg @ 2009-10-31 10:44 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless, hostap@lists.shmoo.com
In-Reply-To: <1256985196.3089.34.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]
On Sat, 2009-10-31 at 12:33 +0200, Maxim Levitsky wrote:
> > Now, especially since you say that this still runs into problems while
> > connecting to a new AP, I think that wpa_supplicant should
> > deauthenticate from the old AP. After all, it wants to eventually
> > control FT and anything we do in the kernel will come back and interfere
> > with that.
> Exactly, at least for now.
>
> How about putting this in wpa_supplicant, and end all trouble with this
> for once?
>
> This is a workaround/hack, but at least it works....
I'm all for fixing the problem in wpa_supplicant, and it should be
plenty clear that I believe that except for the little auth-while-auth
thing, the bug _is_ in wpa_supplicant.
However, it's not my decision. I'll fix the auth-while-auth eventually,
but I believe it is not really the problem in your case.
johannes
> commit e57bfd6e760c32177ab74c462839dd20a92343b8
> Author: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Sat Oct 31 12:05:35 2009 +0200
>
> driver_nl80211: send deauth on disassoc
>
> diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
> index b3861f5..dfed87d 100644
> --- a/src/drivers/driver_nl80211.c
> +++ b/src/drivers/driver_nl80211.c
> @@ -2046,12 +2046,18 @@ static int wpa_driver_nl80211_deauthenticate(void *priv, const u8 *addr,
> static int wpa_driver_nl80211_disassociate(void *priv, const u8 *addr,
> int reason_code)
> {
> + int err;
> struct wpa_driver_nl80211_data *drv = priv;
> if (!(drv->capa.flags & WPA_DRIVER_FLAGS_SME))
> return wpa_driver_nl80211_disconnect(drv, addr, reason_code);
> wpa_printf(MSG_DEBUG, "%s", __func__);
> drv->associated = 0;
> - return wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DISASSOCIATE,
> +
> + err = wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DISASSOCIATE,
> + reason_code);
> + if (err)
> + return err;
> + return wpa_driver_nl80211_mlme(drv, addr, NL80211_CMD_DEAUTHENTICATE,
> reason_code);
> }
>
>
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Prism54/p54pci
From: Luis R. Rodriguez @ 2009-10-31 13:26 UTC (permalink / raw)
To: James Grossmann
Cc: linux-wireless, John W. Linville, Larry Finger,
Christian Lamparter
In-Reply-To: <167ae39b0910310615k5475e5cp55d1c0d60e7a443b@mail.gmail.com>
Please keep the CC list here. This type of report is rare and we need
it archived. Please try using wireless-testing or compat-wireless:
http://wireless.kernel.org/en/users/Download
Luis
On Sat, Oct 31, 2009 at 6:15 AM, James Grossmann <cctsurf@gmail.com> wrote:
> Attempted under Ubuntu 9.10, using their kernel 2.6.31-14-generic.
> Unfortunately it still does not work, is it possible to load the
> fullmac firmware through p54pci? just a thought...
> Here's my relevant dmesg:
> [ 15.369250] pcmcia_socket pcmcia_socket0: cs: IO port probe
> 0x100-0x3af: clean.
> [ 15.370157] pcmcia_socket pcmcia_socket0: cs: IO port probe
> 0x3e0-0x4ff: excluding 0x4d0-0x4d7
> [ 15.370585] pcmcia_socket pcmcia_socket0: cs: IO port probe
> 0x820-0x8ff: clean.
> [ 15.370956] pcmcia_socket pcmcia_socket0: cs: IO port probe
> 0xc00-0xcf7: clean.
> [ 15.371596] pcmcia_socket pcmcia_socket0: cs: IO port probe
> 0xa00-0xaff: clean.
> [ 15.776624] p54pci 0000:03:00.0: enabling device (0000 -> 0002)
> [ 15.776653] p54pci 0000:03:00.0: PCI INT A -> Link[LNKA] -> GSI 11
> (level, low) -> IRQ 11
> [ 15.776675] p54pci 0000:03:00.0: setting latency timer to 64
> [ 15.776789] p54pci 0000:03:00.0: firmware: requesting isl3886pci
> [ 15.916240] cfg80211: World regulatory domain updated:
> [ 15.916252] (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ 15.916260] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi,
> 2000 mBm)
> [ 15.916267] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi,
> 2000 mBm)
> [ 15.916274] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi,
> 2000 mBm)
> [ 15.916280] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi,
> 2000 mBm)
> [ 15.916287] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi,
> 2000 mBm)
> [ 16.048573] phy0: p54 detected a LM86 firmware
> [ 16.048582] p54: rx_mtu reduced from 3240 to 2376
> [ 16.048588] phy0: FW rev 2.13.12.0 - Softmac protocol 5.9
> [ 16.048594] phy0: cryptographic accelerator WEP:YES, TKIP:YES,
> CCMP:YES
> [ 16.328427] Intel ICH 0000:00:1f.5: enabling device (0000 -> 0001)
> [ 16.328448] Intel ICH 0000:00:1f.5: PCI INT B -> Link[LNKB] -> GSI
> 11 (level, low) -> IRQ 11
> [ 16.328477] Intel ICH 0000:00:1f.5: setting latency timer to 64
> [ 16.917291] phy0: hwaddr 00:xx:xx:xx:xx:xx, MAC:isl3880 RF:Frisbee
> [ 17.140101] intel8x0_measure_ac97_clock: measured 52127 usecs (2506
> samples)
> [ 17.140111] intel8x0: clocking to 48000
> [ 17.265086] phy0: Selected rate control algorithm 'minstrel'
> [ 17.266862] Registered led device: p54-phy0::assoc
> [ 17.266906] Registered led device: p54-phy0::tx
> [ 17.266951] Registered led device: p54-phy0::rx
> [ 17.266992] Registered led device: p54-phy0::radio
> [ 17.267007] p54pci 0000:03:00.0: is registered as 'phy0'
> [ 17.292918] udev: renamed network interface wlan0 to wlan1
> [ 30.512797] EXT3 FS on sda5, internal journal
> [ 31.876640] kjournald starting. Commit interval 5 seconds
> [ 31.876989] EXT3 FS on sda7, internal journal
> [ 31.877000] EXT3-fs: mounted filesystem with writeback data mode.
> [ 32.829400] type=1505 audit(1256993753.257:9):
> operation="profile_replace" pid=853 name=/sbin/dhclient3
> [ 32.830401] type=1505 audit(1256993753.257:10):
> operation="profile_replace" pid=853
> name=/usr/lib/NetworkManager/nm-dhcp-client.action
> [ 32.830965] type=1505 audit(1256993753.257:11):
> operation="profile_replace" pid=853
> name=/usr/lib/connman/scripts/dhclient-script
> [ 32.837982] type=1505 audit(1256993753.265:12):
> operation="profile_replace" pid=855
> name=/usr/lib/cups/backend/cups-pdf
> [ 32.839224] type=1505 audit(1256993753.265:13):
> operation="profile_replace" pid=855 name=/usr/sbin/cupsd
> [ 32.844175] type=1505 audit(1256993753.273:14):
> operation="profile_replace" pid=856 name=/usr/sbin/mysqld-akonadi
> [ 32.847992] type=1505 audit(1256993753.273:15):
> operation="profile_replace" pid=857 name=/usr/sbin/tcpdump
> [ 37.182116] RPC: Registered udp transport module.
> [ 37.182124] RPC: Registered tcp transport module.
> [ 37.410106] Installing knfsd (copyright (C) 1996
> okir@monad.swb.de).
> [ 40.921453] svc: failed to register lockdv1 RPC service (errno 97).
> [ 40.923471] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
> recovery directory
> [ 40.988229] NFSD: starting 90-second grace period
> [ 41.914184] ADDRCONF(NETDEV_UP): wlan1: link is not ready
> [ 41.938395] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 42.970111] [drm] Initialized drm 1.1.0 20060810
> [ 42.978943] pci 0000:01:00.0: power state changed by ACPI to D0
> [ 42.978965] pci 0000:01:00.0: PCI INT A -> Link[LNKA] -> GSI 11
> (level, low) -> IRQ 11
> [ 42.979601] [drm] Initialized savage 2.4.1 20050313 for
> 0000:01:00.0 on minor 0
> [ 43.052134] phy0: frequency change failed
> [ 43.052155] phy0: frequency change failed
> [ 43.052163] phy0: frequency change failed
> [ 43.052170] phy0: frequency change failed
> [ 43.052177] phy0: frequency change failed
> [ 43.116051] phy0: frequency change failed
> [ 43.116070] phy0: frequency change failed
> [ 43.116077] phy0: frequency change failed
> [ 43.116085] phy0: frequency change failed
> [ 43.116092] phy0: frequency change failed
> [ 63.664124] phy0: frequency change failed
> [ 63.664154] phy0: frequency change failed
> [ 63.664162] phy0: frequency change failed
> [ 63.664170] phy0: frequency change failed
> [ 63.664177] phy0: frequency change failed
> [ 63.724148] phy0: frequency change failed
> [ 63.724174] phy0: frequency change failed
> [ 63.724182] phy0: frequency change failed
> [ 63.724189] phy0: frequency change failed
> [ 63.724197] phy0: frequency change failed
> [ 69.288818] ondemand governor failed, too long transition latency
> of HW, fallback to performance governor
> [ 93.668072] phy0: frequency change failed
> [ 93.668093] phy0: frequency change failed
> [ 93.668101] phy0: frequency change failed
> [ 93.668108] phy0: frequency change failed
> [ 93.668115] phy0: frequency change failed
> [ 93.724065] phy0: frequency change failed
> [ 93.724086] phy0: frequency change failed
> [ 93.724094] phy0: frequency change failed
> [ 93.724101] phy0: frequency change failed
> [ 93.724108] phy0: frequency change failed
> [ 109.068537] ondemand governor failed, too long transition latency
> of HW, fallback to performance governor
> [ 115.912103] phy0: frequency change failed
> [ 115.912120] phy0: frequency change failed
> [ 115.912128] phy0: frequency change failed
> [ 115.912135] phy0: frequency change failed
> [ 115.912142] phy0: frequency change failed
> [ 115.968099] phy0: frequency change failed
> [ 115.968112] phy0: frequency change failed
> [ 115.968120] phy0: frequency change failed
> [ 115.968127] phy0: frequency change failed
> [ 115.968134] phy0: frequency change failed
> [ 116.368824] phy0: frequency change failed
> [ 116.371618] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx try 1
> [ 116.568114] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx try 2
> [ 116.769380] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx try 3
> [ 116.968120] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx timed out
> [ 121.456176] phy0: frequency change failed
> [ 121.456193] phy0: frequency change failed
> [ 121.456201] phy0: frequency change failed
> [ 121.456208] phy0: frequency change failed
> [ 121.456215] phy0: frequency change failed
> [ 121.512156] phy0: frequency change failed
> [ 121.512169] phy0: frequency change failed
> [ 121.512177] phy0: frequency change failed
> [ 121.512184] phy0: frequency change failed
> [ 121.512191] phy0: frequency change failed
> [ 121.912200] phy0: frequency change failed
> [ 121.915107] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx
> [ 122.112177] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx
> [ 122.312156] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx
> [ 122.512154] wlan1: authentication with AP 00:xx:xx:xx:xx:xx timed
> out
> [ 127.000168] phy0: frequency change failed
> [ 127.000184] phy0: frequency change failed
> [ 127.000192] phy0: frequency change failed
> [ 127.000199] phy0: frequency change failed
> [ 127.000206] phy0: frequency change failed
> [ 127.056164] phy0: frequency change failed
> [ 127.056173] phy0: frequency change failed
> [ 127.056181] phy0: frequency change failed
> [ 127.056188] phy0: frequency change failed
> [ 127.056195] phy0: frequency change failed
> [ 127.460382] phy0: frequency change failed
>
> and it continues like that until I remove the module.
>
>
> On Tue, Oct 27, 2009 at 1:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Thu, Oct 8, 2009 at 9:28 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>> On 10/07/2009 04:00 PM, James Grossmann wrote:
>>>>
>>>> I have the gigafast WF728-AEX, which doesn't seem to work with the
>>>> p54pci drivers, I was previously using it with my Thinkpad T23 under
>>>> Gentoo (gentoo kernels 2.6.29 and 2.6.30), and could only use the
>>>> 1.0.4.3 firmware, now, I am using it under Ubuntu 9.04
>>>> (2.6.28-15-generic kernel) on the same computer, and find that I have
>>>> to load the prism54 driver to make it work.
>>>> I noticed that you were considering this to be depricated, I hope that
>>>> you can help me to make p54pci work!
>>>
>>> As it works with 2.6.29 and 2.6.30 kernels, but not with 2.6.28, it seems
>>> likely that you need a later version of the driver. Does Ubuntu have a
>>> package for compat-wireless? If so, install it. If not, you will need to
>>> install from source.
>>
>> James, please do test with a new driver and appropriate firmware and
>> let us know if it worked or not.
>>
>> Luis
>>
>
^ permalink raw reply
* Re: [PATCH] cfg80211: fix NULL ptr deref
From: Luis R. Rodriguez @ 2009-10-31 13:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Parag Warudkar, linux-wireless
In-Reply-To: <1256971237.3555.87.camel@johannes.local>
On Fri, Oct 30, 2009 at 11:40 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> commit 211a4d12abf86fe0df4cd68fc6327cbb58f56f81
> Author: Johannes Berg <johannes@sipsolutions.net>
> Date: Tue Oct 20 15:08:53 2009 +0900
>
> cfg80211: sme: deauthenticate on assoc failure
>
> introduced a potential NULL pointer dereference that
> some people have been hitting for some reason -- the
> params.bssid pointer is not guaranteed to be non-NULL
> for what seems to be a race between various ways of
> reaching the same thing.
>
> While I'm trying to analyse the problem more let's
> first fix the crash. I think the real fix may be to
> avoid doing _anything_ if it ended up being NULL, but
> right now I'm not sure yet.
>
> I think
> http://bugzilla.kernel.org/show_bug.cgi?id=14342
> might also be this issue.
>
> Reported-by: Parag Warudkar <parag.lkml@gmail.com>
> Tested-by: Parag Warudkar <parag.lkml@gmail.com>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Do we know if this will also affect 2.6.32?
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: fix NULL ptr deref
From: Johannes Berg @ 2009-10-31 13:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John Linville, Parag Warudkar, linux-wireless
In-Reply-To: <43e72e890910310635q6015cf3bq639426d5c1502454@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
On Sat, 2009-10-31 at 06:35 -0700, Luis R. Rodriguez wrote:
> On Fri, Oct 30, 2009 at 11:40 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > commit 211a4d12abf86fe0df4cd68fc6327cbb58f56f81
> > Author: Johannes Berg <johannes@sipsolutions.net>
> > Date: Tue Oct 20 15:08:53 2009 +0900
> >
> > cfg80211: sme: deauthenticate on assoc failure
> >
> > introduced a potential NULL pointer dereference that
> > some people have been hitting for some reason -- the
> > params.bssid pointer is not guaranteed to be non-NULL
> > for what seems to be a race between various ways of
> > reaching the same thing.
> >
> > While I'm trying to analyse the problem more let's
> > first fix the crash. I think the real fix may be to
> > avoid doing _anything_ if it ended up being NULL, but
> > right now I'm not sure yet.
> >
> > I think
> > http://bugzilla.kernel.org/show_bug.cgi?id=14342
> > might also be this issue.
> >
> > Reported-by: Parag Warudkar <parag.lkml@gmail.com>
> > Tested-by: Parag Warudkar <parag.lkml@gmail.com>
> > Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> Do we know if this will also affect 2.6.32?
I'm pretty sure -- have we got any changes to this code that are not
in .32?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: OOPS in cfg80211_conn_work
From: Parag Warudkar @ 2009-10-31 13:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: Parag Warudkar, LKML, linux-wireless
In-Reply-To: <1256970899.3555.86.camel@johannes.local>
On Sat, 31 Oct 2009, Johannes Berg wrote:
>
> iw event -t -f > /tmp/log
Here it goes - this is while trying couple times to reproduce the issue.
Parag
1256995923.900741: wlan0 (phy #0): deauth 00:21:6a:1e:33:1a -> 00:1d:7e:93:3a:58 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS [frame: c0 00 00 00 00 1d 7e 93 3a 58 00 21 6a 1e 33 1a 00 1d 7e 93 3a 58 00 00 03 00]
1256995923.900918: wlan0 (phy #0): disconnected (local request)
1256995923.900953: wlan0 (phy #0): deauth 00:21:6a:1e:33:1a -> 00:16:01:d6:6f:12 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS [frame: c0 00 00 00 00 16 01 d6 6f 12 00 21 6a 1e 33 1a 00 16 01 d6 6f 12 00 00 03 00]
1256995923.901000: wlan0 (phy #0): failed to connect to 00:16:01:d6:6f:12, status: 1: Unspecified failure
1256995923.901861: wlan0 (phy #0): scan started
1256995923.918218: wlan0 (phy #0): failed to connect, status: 1: Unspecified failure
1256995923.918270: wlan0 (phy #0): scan finished: 2452, "f2\x0d\xb71X\xa3Z%]\x05\x17X\xe9^\xd4\xab\xb2\xcd\xc6\x9b\xb4T\x11\x0e\x82tA!=\xdc\x87"
1256995933.941448: wlan0 (phy #0): scan started
1256995937.245751: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785 5805 5825, ""
1256995937.247315: wlan0 (phy #0): scan started
1256995937.247366: wlan0 (phy #0): deauth 00:21:6a:1e:33:1a -> 00:16:01:d6:6f:12 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS [frame: c0 00 00 00 00 16 01 d6 6f 12 00 21 6a 1e 33 1a 00 16 01 d6 6f 12 00 00 03 00]
1256995937.247417: wlan0 (phy #0): failed to connect to 00:16:01:d6:6f:12, status: 1: Unspecified failure
1256995937.287319: wlan0 (phy #0): scan finished: 2452, "f2\x0d\xb71X\xa3Z%]\x05\x17X\xe9^\xd4\xab\xb2\xcd\xc6\x9b\xb4T\x11\x0e\x82tA!=\xdc\x87"
1256995937.293899: wlan0 (phy #0): auth 00:1d:7e:93:3a:58 -> 00:21:6a:1e:33:1a status: 0: Successful [frame: b0 00 3a 01 00 21 6a 1e 33 1a 00 1d 7e 93 3a 58 00 1d 7e 93 3a 58 10 f0 00 00 02 00 00 00]
1256995937.298275: wlan0 (phy #0): assoc 00:1d:7e:93:3a:58 -> 00:21:6a:1e:33:1a status: 0: Successful [frame: 10 00 3a 01 00 21 6a 1e 33 1a 00 1d 7e 93 3a 58 00 1d 7e 93 3a 58 20 f0 11 04 00 00 02 c0 01 04 82 84 8b 96 32 08 8c 12 98 24 b0 48 60 6c dd 18 00 50 f2 02 01 01 80 00 03 a4 00 00 27 a4 00 00 42 43 5e 00 62 32 2f 00 dd 07 00 0c 43 01 00 00 00]
1256995937.298391: wlan0 (phy #0): connected to 00:1d:7e:93:3a:58
1256995941.863589: wlan0 (phy #0): deauth 00:21:6a:1e:33:1a -> 00:1d:7e:93:3a:58 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS [frame: c0 00 00 00 00 1d 7e 93 3a 58 00 21 6a 1e 33 1a 00 1d 7e 93 3a 58 00 00 03 00]
1256995941.863706: wlan0 (phy #0): disconnected (local request)
1256995941.863744: wlan0 (phy #0): deauth 00:21:6a:1e:33:1a -> 00:16:01:d6:6f:12 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS [frame: c0 00 00 00 00 16 01 d6 6f 12 00 21 6a 1e 33 1a 00 16 01 d6 6f 12 00 00 03 00]
1256995941.863791: wlan0 (phy #0): failed to connect to 00:16:01:d6:6f:12, status: 1: Unspecified failure
1256995941.864860: wlan0 (phy #0): scan started
1256995941.883549: wlan0 (phy #0): failed to connect, status: 1: Unspecified failure
1256995941.883658: wlan0 (phy #0): scan finished: 2452, "p\xe9>\xa1A\xe1\xfcg>\x01~\x97\xea\xdck\x96\x8f8\*\xec\xb0;\xfb2\xaf<T\xec\x18\xdb\"
1256995951.192371: wlan0 (phy #0): scan started
1256995954.482288: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785 5805 5825, "pbwloft2"
1256995954.483920: wlan0 (phy #0): scan started
1256995954.483976: wlan0 (phy #0): deauth 00:21:6a:1e:33:1a -> 00:16:01:d6:6f:12 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS [frame: c0 00 00 00 00 16 01 d6 6f 12 00 21 6a 1e 33 1a 00 16 01 d6 6f 12 00 00 03 00]
1256995954.484027: wlan0 (phy #0): failed to connect to 00:16:01:d6:6f:12, status: 1: Unspecified fa
^ permalink raw reply
* Re: [PATCH] cfg80211: fix NULL ptr deref
From: Luis R. Rodriguez @ 2009-10-31 13:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Parag Warudkar, linux-wireless
In-Reply-To: <1256996211.3555.131.camel@johannes.local>
On Sat, Oct 31, 2009 at 6:36 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sat, 2009-10-31 at 06:35 -0700, Luis R. Rodriguez wrote:
>> On Fri, Oct 30, 2009 at 11:40 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>> > commit 211a4d12abf86fe0df4cd68fc6327cbb58f56f81
>> > Author: Johannes Berg <johannes@sipsolutions.net>
>> > Date: Tue Oct 20 15:08:53 2009 +0900
>> >
>> > cfg80211: sme: deauthenticate on assoc failure
>> >
>> > introduced a potential NULL pointer dereference that
>> > some people have been hitting for some reason -- the
>> > params.bssid pointer is not guaranteed to be non-NULL
>> > for what seems to be a race between various ways of
>> > reaching the same thing.
>> >
>> > While I'm trying to analyse the problem more let's
>> > first fix the crash. I think the real fix may be to
>> > avoid doing _anything_ if it ended up being NULL, but
>> > right now I'm not sure yet.
>> >
>> > I think
>> > http://bugzilla.kernel.org/show_bug.cgi?id=14342
>> > might also be this issue.
>> >
>> > Reported-by: Parag Warudkar <parag.lkml@gmail.com>
>> > Tested-by: Parag Warudkar <parag.lkml@gmail.com>
>> > Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>>
>> Do we know if this will also affect 2.6.32?
>
> I'm pretty sure -- have we got any changes to this code that are not
> in .32?
Not sure, I just wanted to make sure we fix .32 as well, that's all.
Luis
^ permalink raw reply
* Re: OOPS in cfg80211_conn_work
From: Johannes Berg @ 2009-10-31 13:47 UTC (permalink / raw)
To: Parag Warudkar; +Cc: LKML, linux-wireless
In-Reply-To: <alpine.DEB.2.00.0910310936110.5317@parag-laptop>
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]
On Sat, 2009-10-31 at 09:37 -0400, Parag Warudkar wrote:
>
> On Sat, 31 Oct 2009, Johannes Berg wrote:
> >
> > iw event -t -f > /tmp/log
>
> Here it goes - this is while trying couple times to reproduce the issue.
Thanks. I'll analyse it later and if I see any issues fix them.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Prism54/p54pci
From: James Grossmann @ 2009-10-31 14:11 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, John W. Linville, Larry Finger,
Christian Lamparter
In-Reply-To: <43e72e890910310626q6d145673he38a3a4e56ca8f7c@mail.gmail.com>
No help with the compat drivers:
[ 4185.320334] Unloaded prism54 driver
[ 4200.794299] cfg80211: Calling CRDA to update world regulatory
domain
[ 4200.857330] p54pci 0000:03:00.0: PCI INT A -> Link[LNKA] -> GSI 11
(level, low) -> IRQ 11
[ 4200.857408] p54pci 0000:03:00.0: firmware: requesting isl3886pci
[ 4201.432596] phy0: p54 detected a LM86 firmware
[ 4201.432604] p54: rx_mtu reduced from 3240 to 2376
[ 4201.432610] phy0: FW rev 2.13.12.0 - Softmac protocol 5.9
[ 4201.432616] phy0: cryptographic accelerator WEP:YES, TKIP:YES,
CCMP:YES
[ 4201.661701] cfg80211: World regulatory domain updated:
[ 4201.661710] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 4201.661718] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 4201.661724] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi,
2000 mBm)
[ 4201.661731] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi,
2000 mBm)
[ 4201.661738] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 4201.661745] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 4202.293254] phy0: EEPROM is damaged... you may not be ableto use
all channels with this device.
[ 4202.293286] phy0: [iqauto calibration data] is/are missing for
channel:2 [2417 MHz].
[ 4202.293293] phy0: [iqauto calibration data] is/are missing for
channel:3 [2422 MHz].
[ 4202.293300] phy0: [iqauto calibration data] is/are missing for
channel:4 [2427 MHz].
[ 4202.293306] phy0: [iqauto calibration data] is/are missing for
channel:5 [2432 MHz].
[ 4202.293313] phy0: [iqauto calibration data] is/are missing for
channel:6 [2437 MHz].
[ 4202.293320] phy0: [iqauto calibration data] is/are missing for
channel:8 [2447 MHz].
[ 4202.293326] phy0: [iqauto calibration data] is/are missing for
channel:9 [2452 MHz].
[ 4202.293333] phy0: [iqauto calibration data] is/are missing for
channel:10 [2457 MHz].
[ 4202.293340] phy0: [iqauto calibration data] is/are missing for
channel:11 [2462 MHz].
[ 4202.293346] phy0: [iqauto calibration data] is/are missing for
channel:12 [2467 MHz].
[ 4202.293356] phy0: hwaddr 00:xx:xx:xx:xx:xx, MAC:isl3880 RF:Frisbee
[ 4202.293787] phy0: Selected rate control algorithm 'minstrel'
[ 4202.295616] Registered led device: p54-phy0::assoc
[ 4202.295657] Registered led device: p54-phy0::tx
[ 4202.295703] Registered led device: p54-phy0::rx
[ 4202.295744] Registered led device: p54-phy0::radio
[ 4202.295758] p54pci 0000:03:00.0: is registered as 'phy0'
[ 4202.378618] udev: renamed network interface wlan0 to wlan1
[ 4202.509483] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 4202.724125] phy0: frequency change to channel 2 failed.
[ 4202.724138] phy0: frequency change to channel 3 failed.
[ 4202.724145] phy0: frequency change to channel 4 failed.
[ 4202.724151] phy0: frequency change to channel 5 failed.
[ 4202.724157] phy0: frequency change to channel 6 failed.
[ 4202.780179] phy0: frequency change to channel 8 failed.
[ 4202.780193] phy0: frequency change to channel 9 failed.
[ 4202.780199] phy0: frequency change to channel 10 failed.
[ 4202.780206] phy0: frequency change to channel 11 failed.
[ 4202.780212] phy0: frequency change to channel 12 failed.
[ 4208.212168] phy0: frequency change to channel 2 failed.
[ 4208.212180] phy0: frequency change to channel 3 failed.
[ 4208.212187] phy0: frequency change to channel 4 failed.
[ 4208.212193] phy0: frequency change to channel 5 failed.
[ 4208.212199] phy0: frequency change to channel 6 failed.
[ 4208.276097] phy0: frequency change to channel 8 failed.
[ 4208.276112] phy0: frequency change to channel 9 failed.
[ 4208.276119] phy0: frequency change to channel 10 failed.
[ 4208.276125] phy0: frequency change to channel 11 failed.
[ 4208.276132] phy0: frequency change to channel 12 failed.
[ 4208.524788] phy0: frequency change to channel 6 failed.
[ 4208.524949] wlan1: deauthenticating from 00:xx:xx:xx:xx:xx by local
choice (reason=3)
[ 4208.525084] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
[ 4208.724191] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 2)
[ 4208.924197] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 3)
[ 4209.124181] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx timed out
[ 4213.712173] phy0: frequency change to channel 2 failed.
[ 4213.712186] phy0: frequency change to channel 3 failed.
[ 4213.712193] phy0: frequency change to channel 4 failed.
[ 4213.712199] phy0: frequency change to channel 5 failed.
[ 4213.712205] phy0: frequency change to channel 6 failed.
[ 4213.768179] phy0: frequency change to channel 8 failed.
[ 4213.768193] phy0: frequency change to channel 9 failed.
[ 4213.768199] phy0: frequency change to channel 10 failed.
[ 4213.768206] phy0: frequency change to channel 11 failed.
[ 4213.768212] phy0: frequency change to channel 12 failed.
[ 4214.016190] phy0: frequency change to channel 6 failed.
[ 4214.016941] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
[ 4214.217439] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 2)
[ 4214.416177] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 3)
[ 4214.616183] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx timed out
On Sat, Oct 31, 2009 at 8:26 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Please keep the CC list here. This type of report is rare and we need
> it archived. Please try using wireless-testing or compat-wireless:
>
> http://wireless.kernel.org/en/users/Download
>
> Luis
>
> On Sat, Oct 31, 2009 at 6:15 AM, James Grossmann <cctsurf@gmail.com> wrote:
>> Attempted under Ubuntu 9.10, using their kernel 2.6.31-14-generic.
>> Unfortunately it still does not work, is it possible to load the
>> fullmac firmware through p54pci? just a thought...
>> Here's my relevant dmesg:
>> [ 15.369250] pcmcia_socket pcmcia_socket0: cs: IO port probe
>> 0x100-0x3af: clean.
>> [ 15.370157] pcmcia_socket pcmcia_socket0: cs: IO port probe
>> 0x3e0-0x4ff: excluding 0x4d0-0x4d7
>> [ 15.370585] pcmcia_socket pcmcia_socket0: cs: IO port probe
>> 0x820-0x8ff: clean.
>> [ 15.370956] pcmcia_socket pcmcia_socket0: cs: IO port probe
>> 0xc00-0xcf7: clean.
>> [ 15.371596] pcmcia_socket pcmcia_socket0: cs: IO port probe
>> 0xa00-0xaff: clean.
>> [ 15.776624] p54pci 0000:03:00.0: enabling device (0000 -> 0002)
>> [ 15.776653] p54pci 0000:03:00.0: PCI INT A -> Link[LNKA] -> GSI 11
>> (level, low) -> IRQ 11
>> [ 15.776675] p54pci 0000:03:00.0: setting latency timer to 64
>> [ 15.776789] p54pci 0000:03:00.0: firmware: requesting isl3886pci
>> [ 15.916240] cfg80211: World regulatory domain updated:
>> [ 15.916252] (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 15.916260] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi,
>> 2000 mBm)
>> [ 15.916267] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi,
>> 2000 mBm)
>> [ 15.916274] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi,
>> 2000 mBm)
>> [ 15.916280] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi,
>> 2000 mBm)
>> [ 15.916287] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi,
>> 2000 mBm)
>> [ 16.048573] phy0: p54 detected a LM86 firmware
>> [ 16.048582] p54: rx_mtu reduced from 3240 to 2376
>> [ 16.048588] phy0: FW rev 2.13.12.0 - Softmac protocol 5.9
>> [ 16.048594] phy0: cryptographic accelerator WEP:YES, TKIP:YES,
>> CCMP:YES
>> [ 16.328427] Intel ICH 0000:00:1f.5: enabling device (0000 -> 0001)
>> [ 16.328448] Intel ICH 0000:00:1f.5: PCI INT B -> Link[LNKB] -> GSI
>> 11 (level, low) -> IRQ 11
>> [ 16.328477] Intel ICH 0000:00:1f.5: setting latency timer to 64
>> [ 16.917291] phy0: hwaddr 00:xx:xx:xx:xx:xx, MAC:isl3880 RF:Frisbee
>> [ 17.140101] intel8x0_measure_ac97_clock: measured 52127 usecs (2506
>> samples)
>> [ 17.140111] intel8x0: clocking to 48000
>> [ 17.265086] phy0: Selected rate control algorithm 'minstrel'
>> [ 17.266862] Registered led device: p54-phy0::assoc
>> [ 17.266906] Registered led device: p54-phy0::tx
>> [ 17.266951] Registered led device: p54-phy0::rx
>> [ 17.266992] Registered led device: p54-phy0::radio
>> [ 17.267007] p54pci 0000:03:00.0: is registered as 'phy0'
>> [ 17.292918] udev: renamed network interface wlan0 to wlan1
>> [ 30.512797] EXT3 FS on sda5, internal journal
>> [ 31.876640] kjournald starting. Commit interval 5 seconds
>> [ 31.876989] EXT3 FS on sda7, internal journal
>> [ 31.877000] EXT3-fs: mounted filesystem with writeback data mode.
>> [ 32.829400] type=1505 audit(1256993753.257:9):
>> operation="profile_replace" pid=853 name=/sbin/dhclient3
>> [ 32.830401] type=1505 audit(1256993753.257:10):
>> operation="profile_replace" pid=853
>> name=/usr/lib/NetworkManager/nm-dhcp-client.action
>> [ 32.830965] type=1505 audit(1256993753.257:11):
>> operation="profile_replace" pid=853
>> name=/usr/lib/connman/scripts/dhclient-script
>> [ 32.837982] type=1505 audit(1256993753.265:12):
>> operation="profile_replace" pid=855
>> name=/usr/lib/cups/backend/cups-pdf
>> [ 32.839224] type=1505 audit(1256993753.265:13):
>> operation="profile_replace" pid=855 name=/usr/sbin/cupsd
>> [ 32.844175] type=1505 audit(1256993753.273:14):
>> operation="profile_replace" pid=856 name=/usr/sbin/mysqld-akonadi
>> [ 32.847992] type=1505 audit(1256993753.273:15):
>> operation="profile_replace" pid=857 name=/usr/sbin/tcpdump
>> [ 37.182116] RPC: Registered udp transport module.
>> [ 37.182124] RPC: Registered tcp transport module.
>> [ 37.410106] Installing knfsd (copyright (C) 1996
>> okir@monad.swb.de).
>> [ 40.921453] svc: failed to register lockdv1 RPC service (errno 97).
>> [ 40.923471] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state
>> recovery directory
>> [ 40.988229] NFSD: starting 90-second grace period
>> [ 41.914184] ADDRCONF(NETDEV_UP): wlan1: link is not ready
>> [ 41.938395] ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [ 42.970111] [drm] Initialized drm 1.1.0 20060810
>> [ 42.978943] pci 0000:01:00.0: power state changed by ACPI to D0
>> [ 42.978965] pci 0000:01:00.0: PCI INT A -> Link[LNKA] -> GSI 11
>> (level, low) -> IRQ 11
>> [ 42.979601] [drm] Initialized savage 2.4.1 20050313 for
>> 0000:01:00.0 on minor 0
>> [ 43.052134] phy0: frequency change failed
>> [ 43.052155] phy0: frequency change failed
>> [ 43.052163] phy0: frequency change failed
>> [ 43.052170] phy0: frequency change failed
>> [ 43.052177] phy0: frequency change failed
>> [ 43.116051] phy0: frequency change failed
>> [ 43.116070] phy0: frequency change failed
>> [ 43.116077] phy0: frequency change failed
>> [ 43.116085] phy0: frequency change failed
>> [ 43.116092] phy0: frequency change failed
>> [ 63.664124] phy0: frequency change failed
>> [ 63.664154] phy0: frequency change failed
>> [ 63.664162] phy0: frequency change failed
>> [ 63.664170] phy0: frequency change failed
>> [ 63.664177] phy0: frequency change failed
>> [ 63.724148] phy0: frequency change failed
>> [ 63.724174] phy0: frequency change failed
>> [ 63.724182] phy0: frequency change failed
>> [ 63.724189] phy0: frequency change failed
>> [ 63.724197] phy0: frequency change failed
>> [ 69.288818] ondemand governor failed, too long transition latency
>> of HW, fallback to performance governor
>> [ 93.668072] phy0: frequency change failed
>> [ 93.668093] phy0: frequency change failed
>> [ 93.668101] phy0: frequency change failed
>> [ 93.668108] phy0: frequency change failed
>> [ 93.668115] phy0: frequency change failed
>> [ 93.724065] phy0: frequency change failed
>> [ 93.724086] phy0: frequency change failed
>> [ 93.724094] phy0: frequency change failed
>> [ 93.724101] phy0: frequency change failed
>> [ 93.724108] phy0: frequency change failed
>> [ 109.068537] ondemand governor failed, too long transition latency
>> of HW, fallback to performance governor
>> [ 115.912103] phy0: frequency change failed
>> [ 115.912120] phy0: frequency change failed
>> [ 115.912128] phy0: frequency change failed
>> [ 115.912135] phy0: frequency change failed
>> [ 115.912142] phy0: frequency change failed
>> [ 115.968099] phy0: frequency change failed
>> [ 115.968112] phy0: frequency change failed
>> [ 115.968120] phy0: frequency change failed
>> [ 115.968127] phy0: frequency change failed
>> [ 115.968134] phy0: frequency change failed
>> [ 116.368824] phy0: frequency change failed
>> [ 116.371618] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx try 1
>> [ 116.568114] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx try 2
>> [ 116.769380] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx try 3
>> [ 116.968120] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx timed out
>> [ 121.456176] phy0: frequency change failed
>> [ 121.456193] phy0: frequency change failed
>> [ 121.456201] phy0: frequency change failed
>> [ 121.456208] phy0: frequency change failed
>> [ 121.456215] phy0: frequency change failed
>> [ 121.512156] phy0: frequency change failed
>> [ 121.512169] phy0: frequency change failed
>> [ 121.512177] phy0: frequency change failed
>> [ 121.512184] phy0: frequency change failed
>> [ 121.512191] phy0: frequency change failed
>> [ 121.912200] phy0: frequency change failed
>> [ 121.915107] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx
>> [ 122.112177] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx
>> [ 122.312156] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx
>> [ 122.512154] wlan1: authentication with AP 00:xx:xx:xx:xx:xx timed
>> out
>> [ 127.000168] phy0: frequency change failed
>> [ 127.000184] phy0: frequency change failed
>> [ 127.000192] phy0: frequency change failed
>> [ 127.000199] phy0: frequency change failed
>> [ 127.000206] phy0: frequency change failed
>> [ 127.056164] phy0: frequency change failed
>> [ 127.056173] phy0: frequency change failed
>> [ 127.056181] phy0: frequency change failed
>> [ 127.056188] phy0: frequency change failed
>> [ 127.056195] phy0: frequency change failed
>> [ 127.460382] phy0: frequency change failed
>>
>> and it continues like that until I remove the module.
>>
>>
>> On Tue, Oct 27, 2009 at 1:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>> On Thu, Oct 8, 2009 at 9:28 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>> On 10/07/2009 04:00 PM, James Grossmann wrote:
>>>>>
>>>>> I have the gigafast WF728-AEX, which doesn't seem to work with the
>>>>> p54pci drivers, I was previously using it with my Thinkpad T23 under
>>>>> Gentoo (gentoo kernels 2.6.29 and 2.6.30), and could only use the
>>>>> 1.0.4.3 firmware, now, I am using it under Ubuntu 9.04
>>>>> (2.6.28-15-generic kernel) on the same computer, and find that I have
>>>>> to load the prism54 driver to make it work.
>>>>> I noticed that you were considering this to be depricated, I hope that
>>>>> you can help me to make p54pci work!
>>>>
>>>> As it works with 2.6.29 and 2.6.30 kernels, but not with 2.6.28, it seems
>>>> likely that you need a later version of the driver. Does Ubuntu have a
>>>> package for compat-wireless? If so, install it. If not, you will need to
>>>> install from source.
>>>
>>> James, please do test with a new driver and appropriate firmware and
>>> let us know if it worked or not.
>>>
>>> Luis
>>>
>>
>
^ permalink raw reply
* Re[2]: ieee80211_tx_status: headroom too small
From: Nikolai ZHUBR @ 2009-10-31 14:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ivo van Doorn, linux-wireless
In-Reply-To: <1256981677.3555.94.camel@johannes.local>
Saturday, October 31, 2009, 12:34:37 PM, Johannes Berg wrote:
>> > > 4 actually, wasn't there some cases where the header could have an odd
>> > > number of bytes and would require 3 bytes for alignment?
>> >
>> > Hm, is there? I thought they changed the 11s draft to no longer have
>> > that.
>>
>> Well 2 is fine in that case, (I was basing my comment on something said on this mailinglist
>> a long time ago). :)
> However, it really all depends on the hardware too ... Maybe we should
> put more of the logic into drivers, and have mac80211 only export its
> required headroom?
> Or maybe we should just not bother with having drivers do the alignment
> any more -- mac80211 does that now and it only does it if necessary
> (i.e. not on powerpc/x86)
I'm having this issue on mips platform, if it matters. I cannot test
it on x86 yet.
Now, searching for "extra_tx_headroom" gives me essentially the
following two:
net/mac80211/main.c:
local->tx_headroom = max_t(unsigned int , local->hw.extra_tx_headroom,
sizeof(struct ieee80211_tx_status_rtap_hdr));
drivers/net/wireless/rt*pci.c:
rt2x00dev->hw->extra_tx_headroom = 0;
So, as a quick-and-dirty fix, should I replace "max_t(..." by "4 + max_t(..."
or "= 0" by "= 4" ?
Thank you!
Nikolai ZHUBR
> johannes
^ permalink raw reply
* Re: OOPS in cfg80211_conn_work
From: Johannes Berg @ 2009-10-31 15:11 UTC (permalink / raw)
To: Parag Warudkar; +Cc: LKML, linux-wireless
In-Reply-To: <alpine.DEB.2.00.0910310936110.5317@parag-laptop>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
On Sat, 2009-10-31 at 09:37 -0400, Parag Warudkar wrote:
>
> On Sat, 31 Oct 2009, Johannes Berg wrote:
> >
> > iw event -t -f > /tmp/log
>
> Here it goes - this is while trying couple times to reproduce the issue.
Ok, I think this looks fine and we don't need to do anything else. In
fact, I think the behaviour we have there now in the no-bssid case is
like the behaviour we had previously.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] cfg80211: remove dead variable
From: Johannes Berg @ 2009-10-31 15:15 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
commit 211a4d12abf86fe0df4cd68fc6327cbb58f56f81
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Tue Oct 20 15:08:53 2009 +0900
cfg80211: sme: deauthenticate on assoc failure
accidentally introduced a dead variable, I had
changed the code to not need it while creating
the patch and it looks like I forgot to remove
the variable (and nobody else noticed either).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/mlme.c | 2 --
1 file changed, 2 deletions(-)
--- wireless-testing.orig/net/wireless/mlme.c 2009-10-31 16:13:12.000000000 +0100
+++ wireless-testing/net/wireless/mlme.c 2009-10-31 16:13:16.000000000 +0100
@@ -62,7 +62,6 @@ void cfg80211_send_rx_assoc(struct net_d
u8 *ie = mgmt->u.assoc_resp.variable;
int i, ieoffs = offsetof(struct ieee80211_mgmt, u.assoc_resp.variable);
struct cfg80211_internal_bss *bss = NULL;
- bool need_connect_result = true;
wdev_lock(wdev);
@@ -97,7 +96,6 @@ void cfg80211_send_rx_assoc(struct net_d
WARN_ON(!bss);
} else if (wdev->conn) {
cfg80211_sme_failed_assoc(wdev);
- need_connect_result = false;
/*
* do not call connect_result() now because the
* sme will schedule work that does it later.
^ permalink raw reply
* Re: Re[2]: ieee80211_tx_status: headroom too small
From: Johannes Berg @ 2009-10-31 15:35 UTC (permalink / raw)
To: Nikolai ZHUBR; +Cc: Ivo van Doorn, linux-wireless
In-Reply-To: <7724371.20091031172437@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
On Sat, 2009-10-31 at 17:24 +0300, Nikolai ZHUBR wrote:
> Saturday, October 31, 2009, 12:34:37 PM, Johannes Berg wrote:
> >> > > 4 actually, wasn't there some cases where the header could have an odd
> >> > > number of bytes and would require 3 bytes for alignment?
> >> >
> >> > Hm, is there? I thought they changed the 11s draft to no longer have
> >> > that.
> >>
> >> Well 2 is fine in that case, (I was basing my comment on something said on this mailinglist
> >> a long time ago). :)
>
> > However, it really all depends on the hardware too ... Maybe we should
> > put more of the logic into drivers, and have mac80211 only export its
> > required headroom?
>
> > Or maybe we should just not bother with having drivers do the alignment
> > any more -- mac80211 does that now and it only does it if necessary
> > (i.e. not on powerpc/x86)
>
> I'm having this issue on mips platform, if it matters. I cannot test
> it on x86 yet.
>
> Now, searching for "extra_tx_headroom" gives me essentially the
> following two:
>
> net/mac80211/main.c:
> local->tx_headroom = max_t(unsigned int , local->hw.extra_tx_headroom,
> sizeof(struct ieee80211_tx_status_rtap_hdr));
>
> drivers/net/wireless/rt*pci.c:
> rt2x00dev->hw->extra_tx_headroom = 0;
>
> So, as a quick-and-dirty fix, should I replace "max_t(..." by "4 + max_t(..."
> or "= 0" by "= 4" ?
4 + max ... should work if it's what we think it is. Let us know.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re[4]: ieee80211_tx_status: headroom too small
From: Nikolai ZHUBR @ 2009-10-31 17:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ivo van Doorn, linux-wireless
In-Reply-To: <1257003344.3555.136.camel@johannes.local>
Saturday, October 31, 2009, 6:35:44 PM, Johannes Berg wrote:
>> net/mac80211/main.c:
>> local->tx_headroom = max_t(unsigned int , local->hw.extra_tx_headroom,
>> sizeof(struct ieee80211_tx_status_rtap_hdr));
>>
>> drivers/net/wireless/rt*pci.c:
>> rt2x00dev->hw->extra_tx_headroom = 0;
>>
>> So, as a quick-and-dirty fix, should I replace "max_t(..." by "4 + max_t(...."
>> or "= 0" by "= 4" ?
> 4 + max ... should work if it's what we think it is. Let us know.
Yes, it removed those messages.
The actual speed is still not very high (like at 10Mbit maybe,
though 54Mbit is shown and the distance from the AP is very small,
so signal quality should be good I suppose) but it is ok for me.
Thank you!
Nikolai ZHUBR
> johannes
^ 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