How to reproduce the problem:
After booting the system, I get a trace (see attached file "messages.txt")
Expeced result
No trace at all
Actual result
Kernel trace at the logs
Why I think this is a bug
In addition to the trace, I also get random wireless reconnects
Error rate
I get a trace always after booting
Kernel versions tested
3.3 (self compiled from kernel.org)
3.2.12 (Debian based)
Attached files
Full dmesg and messages (exposing the trace)
Observations
Despite the trace, there are no other visible effects except the
random reconnects
The rate of wireless reconnects for kernel 3.2 were more frequent
References
http://bugs.debian.org/664767
Greetings,
--
Camale?n
2012/3/28 Arend van Spriel <[email protected]>:
> On 03/28/2012 01:26 PM, Camale?n wrote:
>>> Did you have any opportunity to test the patch?
>>
>>
>> I did manage to compile and install the full 3.3 kernel sources with
>> the patch applied last night but until a couple a hours or so I cannot
>> start the netbook because is located in a different place :-)
>>
>> Will provide any feedback as soon as I got news.
>>
>> Greetings,
>>
>
> Thanks.
Here it goes.
There's another trace, so now I doubt that I have applied the patches
correctly... Mmm, how could check if the brcmsmac module which I have
compiled and loaded has the patch applied? :-?
Greetings,
--
Camale?n
On 03/24/2012 12:21 PM, Camale?n wrote:
> 2012/3/24 Camale?n<[email protected]>:
>
>> I will keep and eye on this, bu all seems good and working fine now.
>
> Okay, I got another trace :-(
>
> NetworkManager asked for the password (which was already set and
> printed at the input box, I didn't have to type it again) and
> reconnected fine but it logged the trace at /var/log/messages.
>
> See attached files.
>
The WARNING message is preceded by a cfg80211 message regarding world
regulatory domain. I suspect there is a relatio, but not sure what it
is. Regarding channels 12 and 13 I will come up with a fix today and
send you the patch to try.
Gr. AvS
On 03/26/2012 07:13 PM, Seth Forshee wrote:
> On Mon, Mar 26, 2012 at 06:54:22PM +0200, Arend van Spriel wrote:
>> I suspect the warning is caused because mac80211 flush callback is
>> done after scanning on channels 12 and/or 13. I have a quick fix.
>> The longer and preferred fix would be to cleanup channel.c and
>> incorporate your regdom change. I plan to do that in separate
>> patches.
>
> At this point I think the regdom patch I sent is incomplete. We can do a
> lot better. I'll follow up on the other thread a little later today with
> my thoughts.
>
Agree. And I will keep an eye on my email ;-)
Gr. AvS
On 03/28/2012 01:26 PM, Camaleón wrote:
> El 2012-03-28 a las 13:19 +0200, Arend van Spriel escribió:
>> On 03/27/2012 10:47 AM, Arend van Spriel wrote:
>>> On 03/26/2012 11:28 PM, Camaleón wrote:
>
> (...)
>
>>>> Well, I got a new trace today, I'm attaching the usual logs (dmesg and
>>>> messages).
>>>>
>>>> Should I try the aforementioned patch?
>>>>
>>>
>>> I would appreciate it, yes.
>>>
>>
>> Hi Camaleón,
>>
>> Did you have any opportunity to test the patch?
>
> I did manage to compile and install the full 3.3 kernel sources with
> the patch applied last night but until a couple a hours or so I cannot
> start the netbook because is located in a different place :-)
>
> Will provide any feedback as soon as I got news.
>
> Greetings,
>
Thanks.
Gr. AvS
On 03/26/2012 11:43 AM, Camaleón wrote:
> Based on a user advice, I have set the regulatory domain to ES (Spain)
> and I had not experienced another trace since that (the netbook was
> running yesterday all day long).
It all depends what channels are allowed for the ES domain. However, I
am a bit surprised.
> Still, I will keep my "three" eyes over it and test any pacth you
> consider convenient. Will comment back as soon as I get another trace
> or there's something worth to add :-)
Thanks.
Gr. AvS
2012/3/24 Camale?n <[email protected]>:
> I will keep and eye on this, bu all seems good and working fine now.
Okay, I got another trace :-(
NetworkManager asked for the password (which was already set and
printed at the input box, I didn't have to type it again) and
reconnected fine but it logged the trace at /var/log/messages.
See attached files.
--
Camale?n
On 03/26/2012 04:32 PM, Seth Forshee wrote:
> On Mon, Mar 26, 2012 at 11:23:57AM +0200, Arend van Spriel wrote:
>>
>> The WARNING message is preceded by a cfg80211 message regarding
>> world regulatory domain. I suspect there is a relatio, but not sure
>> what it is. Regarding channels 12 and 13 I will come up with a fix
>> today and send you the patch to try.
>
> The trace is related to handling a disconnection, which will also
> trigger a reprocessing of the regulatory rules. The warning and the
> regulatory message share a common cause, but I don't think there's a
> direct relationship between them.
Thanks, Seth
I agree. That seems a more accurate statement. Without additional
tracing (from e.g. wpa_supplicant?) it is hard to say what caused the
disconnect.
> This also seems to indicate that by the time either of these messages
> appears the connection with the AP is already in the process of being
> dropped. I don't think the regulatory messages give any cluse as to why
> the connection was dropped. I suppose the warning might but I don't
> know.
I suspect the warning is caused because mac80211 flush callback is done
after scanning on channels 12 and/or 13. I have a quick fix. The longer
and preferred fix would be to cleanup channel.c and incorporate your
regdom change. I plan to do that in separate patches.
Gr. AvS
2012/3/26 Arend van Spriel <[email protected]>:
> On 03/26/2012 11:43 AM, Camale?n wrote:
>>
>> Based on a user advice, I have set the regulatory domain to ES (Spain)
>> and I had not experienced another trace since that (the netbook was
>> running yesterday all day long).
>
>
> It all depends what channels are allowed for the ES domain. However, I am a
> bit surprised.
>
>
>> Still, I will keep my "three" eyes over it and test any pacth you
>> consider convenient. Will comment back as soon as I get another trace
>> or there's something worth to add :-)
>
>
> Thanks.
Well, I got a new trace today, I'm attaching the usual logs (dmesg and
messages).
Should I try the aforementioned patch?
Greetings,
--
Camale?n
On 03/27/2012 10:47 AM, Arend van Spriel wrote:
> On 03/26/2012 11:28 PM, Camale?n wrote:
>> 2012/3/26 Arend van Spriel<[email protected]>:
>>> On 03/26/2012 11:43 AM, Camale?n wrote:
>>>>
>>>> Based on a user advice, I have set the regulatory domain to ES (Spain)
>>>> and I had not experienced another trace since that (the netbook was
>>>> running yesterday all day long).
>>>
>>>
>>> It all depends what channels are allowed for the ES domain. However, I am a
>>> bit surprised.
>>>
>>>
>>>> Still, I will keep my "three" eyes over it and test any pacth you
>>>> consider convenient. Will comment back as soon as I get another trace
>>>> or there's something worth to add :-)
>>>
>>>
>>> Thanks.
>>
>> Well, I got a new trace today, I'm attaching the usual logs (dmesg and
>> messages).
>>
>> Should I try the aforementioned patch?
>>
>
> I would appreciate it, yes.
>
Hi Camale?n,
Did you have any opportunity to test the patch?
Gr. AvS
On 03/28/2012 11:59 PM, Camale?n wrote:
> 2012/3/28 Arend van Spriel<[email protected]>:
>> On 03/28/2012 01:26 PM, Camale?n wrote:
>
>>>> Did you have any opportunity to test the patch?
>>>
>>>
>>> I did manage to compile and install the full 3.3 kernel sources with
>>> the patch applied last night but until a couple a hours or so I cannot
>>> start the netbook because is located in a different place :-)
>>>
>>> Will provide any feedback as soon as I got news.
>>>
>>> Greetings,
>>>
>>
>> Thanks.
>
> Here it goes.
>
> There's another trace, so now I doubt that I have applied the patches
> correctly... Mmm, how could check if the brcmsmac module which I have
> compiled and loaded has the patch applied? :-?
>
> Greetings,
>
So you have 3.3 kernel sources. Is that from a tarball or are you using
git? For git it would be pretty easy to verify you have the patch.
Gr. AvS
2012/3/24 Arend van Spriel <[email protected]>:
> On 03/24/2012 09:55 AM, Camale?n wrote:
>>
>> How to reproduce the problem:
>> After booting the system, I get a trace (see attached file "messages.txt")
>>
>
> Hi Camale?n,
>
> From the trace I see that your system apparently is setup for regulatory
> domain EU. Could you configure it US instead.
Sure. I have edited "/etc/default/crda" and set there the default
settings (US), see attached logs. The trace has disappeared from
"messages" log :-)
Is it fine to have this default while I'm located in Europe (Spain)?
Wireless seems to be working fine but I don't know if there should be
any drawbacks.
> I think brcmsmac is not handling the channel 12 and 13 properly. Is you AP on either of > these channels? Regardless, mac80211 will probably switch to those channels for
> (passive) scanning.
The AP is configured for channel 06 (2437 MHz.), this shouldn't be a issue.
I will keep and eye on this, bu all seems good and working fine now.
Thanks!
--
Camale?n
On Mon, Mar 26, 2012 at 06:54:22PM +0200, Arend van Spriel wrote:
> I suspect the warning is caused because mac80211 flush callback is
> done after scanning on channels 12 and/or 13. I have a quick fix.
> The longer and preferred fix would be to cleanup channel.c and
> incorporate your regdom change. I plan to do that in separate
> patches.
At this point I think the regdom patch I sent is incomplete. We can do a
lot better. I'll follow up on the other thread a little later today with
my thoughts.
Seth
El 2012-03-29 a las 13:56 +0200, Arend van Spriel escribió:
> On 03/28/2012 11:59 PM, Camaleón wrote:
>> 2012/3/28 Arend van Spriel<[email protected]>:
>>> On 03/28/2012 01:26 PM, Camaleón wrote:
>>
>>>>> Did you have any opportunity to test the patch?
(...)
>> Here it goes.
>>
>> There's another trace, so now I doubt that I have applied the patches
>> correctly... Mmm, how could check if the brcmsmac module which I have
>> compiled and loaded has the patch applied? :-?
>>
>> Greetings,
>>
>
> So you have 3.3 kernel sources. Is that from a tarball or are you using
> git? For git it would be pretty easy to verify you have the patch.
I have the sources, so I applied the patch ("patch -p1 < file.patch")
and then compiled the full kernel again. I can see the three files
(channel.c, main.c and main.h) have been modified but I'm unsure.
Greetings,
--
Camaleón
El 2012-03-26 a las 11:23 +0200, Arend van Spriel escribió:
> On 03/24/2012 12:21 PM, Camaleón wrote:
>> 2012/3/24 Camaleón<[email protected]>:
>>
>>> I will keep and eye on this, bu all seems good and working fine now.
>>
>> Okay, I got another trace :-(
>>
>> NetworkManager asked for the password (which was already set and
>> printed at the input box, I didn't have to type it again) and
>> reconnected fine but it logged the trace at /var/log/messages.
>>
>> See attached files.
>>
>
> The WARNING message is preceded by a cfg80211 message regarding world
> regulatory domain. I suspect there is a relatio, but not sure what it
> is. Regarding channels 12 and 13 I will come up with a fix today and
> send you the patch to try.
Based on a user advice, I have set the regulatory domain to ES (Spain)
and I had not experienced another trace since that (the netbook was
running yesterday all day long).
Still, I will keep my "three" eyes over it and test any pacth you
consider convenient. Will comment back as soon as I get another trace
or there's something worth to add :-)
Greetings,
--
Camaleón
El 2012-03-28 a las 13:19 +0200, Arend van Spriel escribió:
> On 03/27/2012 10:47 AM, Arend van Spriel wrote:
>> On 03/26/2012 11:28 PM, Camaleón wrote:
(...)
>>> Well, I got a new trace today, I'm attaching the usual logs (dmesg and
>>> messages).
>>>
>>> Should I try the aforementioned patch?
>>>
>>
>> I would appreciate it, yes.
>>
>
> Hi Camaleón,
>
> Did you have any opportunity to test the patch?
I did manage to compile and install the full 3.3 kernel sources with
the patch applied last night but until a couple a hours or so I cannot
start the netbook because is located in a different place :-)
Will provide any feedback as soon as I got news.
Greetings,
--
Camaleón
On 03/26/2012 11:28 PM, Camale?n wrote:
> 2012/3/26 Arend van Spriel<[email protected]>:
>> On 03/26/2012 11:43 AM, Camale?n wrote:
>>>
>>> Based on a user advice, I have set the regulatory domain to ES (Spain)
>>> and I had not experienced another trace since that (the netbook was
>>> running yesterday all day long).
>>
>>
>> It all depends what channels are allowed for the ES domain. However, I am a
>> bit surprised.
>>
>>
>>> Still, I will keep my "three" eyes over it and test any pacth you
>>> consider convenient. Will comment back as soon as I get another trace
>>> or there's something worth to add :-)
>>
>>
>> Thanks.
>
> Well, I got a new trace today, I'm attaching the usual logs (dmesg and
> messages).
>
> Should I try the aforementioned patch?
>
I would appreciate it, yes.
Gr. AvS
On Mon, Mar 26, 2012 at 11:23:57AM +0200, Arend van Spriel wrote:
> On 03/24/2012 12:21 PM, Camaleón wrote:
> >2012/3/24 Camaleón<[email protected]>:
> >
> >>I will keep and eye on this, bu all seems good and working fine now.
> >
> >Okay, I got another trace :-(
> >
> >NetworkManager asked for the password (which was already set and
> >printed at the input box, I didn't have to type it again) and
> >reconnected fine but it logged the trace at /var/log/messages.
> >
> >See attached files.
> >
>
> The WARNING message is preceded by a cfg80211 message regarding
> world regulatory domain. I suspect there is a relatio, but not sure
> what it is. Regarding channels 12 and 13 I will come up with a fix
> today and send you the patch to try.
The trace is related to handling a disconnection, which will also
trigger a reprocessing of the regulatory rules. The warning and the
regulatory message share a common cause, but I don't think there's a
direct relationship between them.
This also seems to indicate that by the time either of these messages
appears the connection with the AP is already in the process of being
dropped. I don't think the regulatory messages give any cluse as to why
the connection was dropped. I suppose the warning might but I don't
know.
Seth
On 03/24/2012 09:55 AM, Camale?n wrote:
> How to reproduce the problem:
> After booting the system, I get a trace (see attached file "messages.txt")
>
Hi Camale?n,
From the trace I see that your system apparently is setup for
regulatory domain EU. Could you configure it US instead. I think
brcmsmac is not handling the channel 12 and 13 properly. Is you AP on
either of these channels? Regardless, mac80211 will probably switch to
those channels for (passive) scanning.
Gr. AvS
2012/3/29 Camale?n <[email protected]>:
> El 2012-03-29 a las 13:56 +0200, Arend van Spriel escribi?:
>> On 03/28/2012 11:59 PM, Camale?n wrote:
>>> 2012/3/28 Arend van Spriel<[email protected]>:
>>>> On 03/28/2012 01:26 PM, Camale?n wrote:
>>>
>>>>>> Did you have any opportunity to test the patch?
>
> (...)
>
>>> Here it goes.
>>>
>>> There's another trace, so now I doubt that I have applied the patches
>>> correctly... Mmm, how could check if the brcmsmac module which I have
>>> compiled and loaded has the patch applied? :-?
>>>
>>> Greetings,
>>>
>>
>> So you have 3.3 kernel sources. Is that from a tarball or are you using
>> git? For git it would be pretty easy to verify you have the patch.
>
> I have the sources, so I applied the patch ("patch -p1 < file.patch")
> and then compiled the full kernel again. I can see the three files
> (channel.c, main.c and main.h) have been modified but I'm unsure.
Just an update on this.
I compiled the latest kernel 3.4-rc1 and the trace is still there (see
attached dmesg and messages).
Were the patches applied to the mainline?
Greetings,
--
Camale?n
Camaleón wrote:
> Were the patches applied to the mainline?
I doubt it. Where can one find the patches you were testing, by the
way?
Curious,
Jonathan
El 2012-04-02 a las 16:50 -0500, Jonathan Nieder escribió:
> Camaleón wrote:
>
> > Were the patches applied to the mainline?
>
> I doubt it.
Ouch. I'm out of luck then.
> Where can one find the patches you were testing, by the way?
>
> Curious,
> Jonathan
I received the patch by e-mail ("[PATCH] brcm80211: smac: do not mute tx
in driver for restricted channels"), but I don't know if it was uploaded
elsewhere.
Greetings,
--
Camaleón
On 04/02/2012 11:50 PM, Jonathan Nieder wrote:
> Camaleón wrote:
>
>> Were the patches applied to the mainline?
>
> I doubt it. Where can one find the patches you were testing, by the
> way?
>
> Curious,
> Jonathan
>
I sent the patch to Camaleón to test it before sending out the patch. So
the answer it definitely no. I wanted to get it into rc1, but we missed
that.
Gr. AvS
On Fri, May 11, 2012 at 10:31:49AM -0700, Seth Forshee wrote:
> > > I've sent RFC patches that strip out the vast majority of this code in
> > > favor of better integration with the protocol-level regulatory support.
> > > The piece that's under discussion here is a behavior I maintained in my
> > > changes, which mutes tx on passive scan channels until data is received
> > > on a given channel. But in my opinion, if this sort of behavior is
> > > desired it ought to be implemented at the protocol level instead of in
> > > the driver, so I'd really prefer to see it removed from brcmsmac.
> >
> > This isn't implemented in mac80211, and since some HW (e.g. ours)
> > implements it in lower levels, I don't think you can just generally say
> > it has to be in mac80211 now.
>
> I guess I need to familiarize myself with the situation for other
> hardware then, which I will do next week when I'm not at a conference.
> It just seems to me that if we want to enforce consistent regulatory
> behavior for all HW then mac80211 is the logical place to implement it.
I had a look at iwlwifi, and I see how passive channels are being
handled. I don't understand though how having this functionality in
mac80211 would hurt iwlwifi, but perhaps we can find an acceptible
solution.
Actually the support already present for regulatory beacon hints would
probably suit this purpose fairly well, and in fact it already does seem
to work for some channels. But for reasons I don't understand the beacon
hints are only processed for channels with IEEE80211_CHAN_RADAR cleared,
making it ineffective for most of the 5 GHz band. If this was changed to
at least give the driver some indication that a beacon has been seen on
the channel (even just setting chan->beacon_found) then drivers should
be able to use it to know when tx can be enabled on passive channels.
Cheers,
Seth
On 05/09/2012 07:41 PM, Seth Forshee wrote:
> On Wed, May 09, 2012 at 12:23:43PM +0200, Arend van Spriel wrote:
>> On 05/09/2012 11:41 AM, Jonathan Nieder wrote:
>>> Hi Arend,
>>>
>>> Arend van Spriel wrote, about a month ago[1]:
>>>
>>>> I sent the patch to Camaleón to test it before sending out the
>>>> patch. So the answer it definitely no. I wanted to get it into rc1,
>>>> but we missed that.
>>>
>>> Any news? If there's a patch that goes in the right direction with
>>> known problems I'd still be interested in it, among other reasons
>>> because it would make the bug more concrete and make it easier to
>>> think about possible fixes.
>>
>> Well, there is the short term fix, which is already upstream and moved
>> to stable. The long term fix for which Seth Forshee (Canonical) did a
>> great job is reviewed over here, but it involves regulatory related code
>> so it needs discussions with our compliance team and supervisor. So that
>> causes some lag time.
>
> The patches I sent still relies on the transmit-after-beacon fix, as I
> preserved the behavior of muting tx if the channel is passive scan. I
> *think* this isn't actually necessary, but I'd have to investigate a
> little further to be certain.
>
> Seth
>
As part of the discussion over here I am proposing to get rid of the tx
muting in brcmsmac as mac80211 already has that behaviour for passive
channels if I am not mistaken (is this true, Johannes?).
Gr. AvS
On Thu, 2012-05-10 at 09:35 -0700, Seth Forshee wrote:
> > On passive channels, when scanning, mac80211 will send a probe only
> > after receiving a frame on that channel. When associating, it has no
> > such behaviour, at least not directly, but I suppose it could be
> > implemented (waiting for the beacon)
>
> The background is that brcmsmac contains a bunch of code for regulatory
> support that is either duplicated (and in conflict) with the
> protocol-level support or else it would better be handled there. This is
> causing problems on pretty much any channel that isn't part of the
> default world regulatory domain.
>
> I've sent RFC patches that strip out the vast majority of this code in
> favor of better integration with the protocol-level regulatory support.
> The piece that's under discussion here is a behavior I maintained in my
> changes, which mutes tx on passive scan channels until data is received
> on a given channel. But in my opinion, if this sort of behavior is
> desired it ought to be implemented at the protocol level instead of in
> the driver, so I'd really prefer to see it removed from brcmsmac.
This isn't implemented in mac80211, and since some HW (e.g. ours)
implements it in lower levels, I don't think you can just generally say
it has to be in mac80211 now.
johannes
On Wed, May 09, 2012 at 12:23:43PM +0200, Arend van Spriel wrote:
> On 05/09/2012 11:41 AM, Jonathan Nieder wrote:
> > Hi Arend,
> >
> > Arend van Spriel wrote, about a month ago[1]:
> >
> >> I sent the patch to Camaleón to test it before sending out the
> >> patch. So the answer it definitely no. I wanted to get it into rc1,
> >> but we missed that.
> >
> > Any news? If there's a patch that goes in the right direction with
> > known problems I'd still be interested in it, among other reasons
> > because it would make the bug more concrete and make it easier to
> > think about possible fixes.
>
> Well, there is the short term fix, which is already upstream and moved
> to stable. The long term fix for which Seth Forshee (Canonical) did a
> great job is reviewed over here, but it involves regulatory related code
> so it needs discussions with our compliance team and supervisor. So that
> causes some lag time.
The patches I sent still relies on the transmit-after-beacon fix, as I
preserved the behavior of muting tx if the channel is passive scan. I
*think* this isn't actually necessary, but I'd have to investigate a
little further to be certain.
Seth
On Fri, May 11, 2012 at 11:32:52AM +0200, Johannes Berg wrote:
> On Thu, 2012-05-10 at 09:35 -0700, Seth Forshee wrote:
>
> > > On passive channels, when scanning, mac80211 will send a probe only
> > > after receiving a frame on that channel. When associating, it has no
> > > such behaviour, at least not directly, but I suppose it could be
> > > implemented (waiting for the beacon)
> >
> > The background is that brcmsmac contains a bunch of code for regulatory
> > support that is either duplicated (and in conflict) with the
> > protocol-level support or else it would better be handled there. This is
> > causing problems on pretty much any channel that isn't part of the
> > default world regulatory domain.
> >
> > I've sent RFC patches that strip out the vast majority of this code in
> > favor of better integration with the protocol-level regulatory support.
> > The piece that's under discussion here is a behavior I maintained in my
> > changes, which mutes tx on passive scan channels until data is received
> > on a given channel. But in my opinion, if this sort of behavior is
> > desired it ought to be implemented at the protocol level instead of in
> > the driver, so I'd really prefer to see it removed from brcmsmac.
>
> This isn't implemented in mac80211, and since some HW (e.g. ours)
> implements it in lower levels, I don't think you can just generally say
> it has to be in mac80211 now.
I guess I need to familiarize myself with the situation for other
hardware then, which I will do next week when I'm not at a conference.
It just seems to me that if we want to enforce consistent regulatory
behavior for all HW then mac80211 is the logical place to implement it.
Seth
On Wed, 2012-05-16 at 15:15 -0500, Seth Forshee wrote:
> > > This isn't implemented in mac80211, and since some HW (e.g. ours)
> > > implements it in lower levels, I don't think you can just generally say
> > > it has to be in mac80211 now.
> >
> > I guess I need to familiarize myself with the situation for other
> > hardware then, which I will do next week when I'm not at a conference.
> > It just seems to me that if we want to enforce consistent regulatory
> > behavior for all HW then mac80211 is the logical place to implement it.
>
> I had a look at iwlwifi, and I see how passive channels are being
> handled. I don't understand though how having this functionality in
> mac80211 would hurt iwlwifi, but perhaps we can find an acceptible
> solution.
I'm just thinking that having both would make it have a bigger delay or
so. Since mac80211 can't really know our device's internal state (even
the driver can't really keep track easily) we couldn't remove the
iwlwifi pieces.
> Actually the support already present for regulatory beacon hints would
> probably suit this purpose fairly well, and in fact it already does seem
> to work for some channels. But for reasons I don't understand the beacon
> hints are only processed for channels with IEEE80211_CHAN_RADAR cleared,
> making it ineffective for most of the 5 GHz band. If this was changed to
> at least give the driver some indication that a beacon has been seen on
> the channel (even just setting chan->beacon_found) then drivers should
> be able to use it to know when tx can be enabled on passive channels.
RADAR channels have specific time requirements, the beacon hints are
used for something like "geography detection".
johannes
Arend van Spriel wrote:
> On 05/09/2012 11:41 AM, Jonathan Nieder wrote:
>> Any news? If there's a patch that goes in the right direction with
>> known problems I'd still be interested in it, among other reasons
>> because it would make the bug more concrete and make it easier to
>> think about possible fixes.
>
> Well, there is the short term fix, which is already upstream and moved
> to stable. The long term fix for which Seth Forshee (Canonical) did a
> great job is reviewed over here, but it involves regulatory related code
> so it needs discussions with our compliance team and supervisor. So that
> causes some lag time.
>
> If you are using a kernel with the short term fix included please sent
> any logging information if the problem still persists.
Thanks for explaining. That makes sense.
Is the short term fix badc4f07622f ("brcm80211: smac: resume transmit
fifo upon receiving frames", 2012-04-11)?
Thanks,
Jonathan
On Wed, 2012-05-09 at 20:01 +0200, Arend van Spriel wrote:
> As part of the discussion over here I am proposing to get rid of the tx
> muting in brcmsmac as mac80211 already has that behaviour for passive
> channels if I am not mistaken (is this true, Johannes?).
Arend, I haven't really followed this discussion, can you elaborate?
On passive channels, when scanning, mac80211 will send a probe only
after receiving a frame on that channel. When associating, it has no
such behaviour, at least not directly, but I suppose it could be
implemented (waiting for the beacon)
johannes
On 05/09/2012 11:41 AM, Jonathan Nieder wrote:
> Hi Arend,
>
> Arend van Spriel wrote, about a month ago[1]:
>
>> I sent the patch to Camaleón to test it before sending out the
>> patch. So the answer it definitely no. I wanted to get it into rc1,
>> but we missed that.
>
> Any news? If there's a patch that goes in the right direction with
> known problems I'd still be interested in it, among other reasons
> because it would make the bug more concrete and make it easier to
> think about possible fixes.
Well, there is the short term fix, which is already upstream and moved
to stable. The long term fix for which Seth Forshee (Canonical) did a
great job is reviewed over here, but it involves regulatory related code
so it needs discussions with our compliance team and supervisor. So that
causes some lag time.
If you are using a kernel with the short term fix included please sent
any logging information if the problem still persists.
Gr. AvS
On Wed, May 09, 2012 at 08:10:54PM +0200, Johannes Berg wrote:
> On Wed, 2012-05-09 at 20:01 +0200, Arend van Spriel wrote:
>
> > As part of the discussion over here I am proposing to get rid of the tx
> > muting in brcmsmac as mac80211 already has that behaviour for passive
> > channels if I am not mistaken (is this true, Johannes?).
>
> Arend, I haven't really followed this discussion, can you elaborate?
>
> On passive channels, when scanning, mac80211 will send a probe only
> after receiving a frame on that channel. When associating, it has no
> such behaviour, at least not directly, but I suppose it could be
> implemented (waiting for the beacon)
The background is that brcmsmac contains a bunch of code for regulatory
support that is either duplicated (and in conflict) with the
protocol-level support or else it would better be handled there. This is
causing problems on pretty much any channel that isn't part of the
default world regulatory domain.
I've sent RFC patches that strip out the vast majority of this code in
favor of better integration with the protocol-level regulatory support.
The piece that's under discussion here is a behavior I maintained in my
changes, which mutes tx on passive scan channels until data is received
on a given channel. But in my opinion, if this sort of behavior is
desired it ought to be implemented at the protocol level instead of in
the driver, so I'd really prefer to see it removed from brcmsmac.
Seth
Hi Arend,
Arend van Spriel wrote, about a month ago[1]:
> I sent the patch to Camaleón to test it before sending out the
> patch. So the answer it definitely no. I wanted to get it into rc1,
> but we missed that.
Any news? If there's a patch that goes in the right direction with
known problems I'd still be interested in it, among other reasons
because it would make the bug more concrete and make it easier to
think about possible fixes.
Thanks,
Jonathan
[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/87873/focus=88279
On 05/09/2012 12:29 PM, Jonathan Nieder wrote:
>
> Thanks for explaining. That makes sense.
>
> Is the short term fix badc4f07622f ("brcm80211: smac: resume transmit
> fifo upon receiving frames", 2012-04-11)?
>
> Thanks,
> Jonathan
>
Yep. I remember because the SHA1 start with 'bad', which felt like a
certain kind of omen to me ;-)
Gr. AvS