When user requests for survey dump data, driver is providing wrong survey
information. This information we sent is the survey data that we have
collected during previous user request.
This issue occurs because we request survey dump for wrong channel. With
this change, we correctly display the
On Thu, Sep 1, 2016 at 12:03 PM, Toke Høiland-Jørgensen wrote:
> @@ -1481,33 +1506,57 @@ struct sk_buff *ieee80211_tx_dequeue(struct
> ieee80211_hw *hw,
> {
> struct ieee80211_local *local = hw_to_local(hw);
> struct txq_info *txqi = container_of(txq, struct
> If someone has any idea of why this patch might trigger it, please
> let me know.
> I'll keep digging in the meantime...
>
> Revert "mac80211: don't advertise NL80211_FEATURE_FULL_AP_CLIENT_STATE"
>
With a sufficiently recent hostapd/wpa_supplicant, the patch will cause
a station entry
A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup
led_pin initial") that broken the WLAN status led on my laptop with
AR9287 after suspending and resuming.
Steps to reproduce:
* Suspend (laptop)
* Resume (laptop)
* Observe that the WLAN led no longer turns ON/OFF depending on
> To avoid having to deal with fragmentation on dequeue, the split is
> set to be after the fragmentation handler. This means that some
> reordering of TX handlers is necessary, and some handlers had to be
> made aware of fragmentation due to this reordering.
Come to think of it, that's actually
On 09/01/2016 11:53 AM, Johannes Berg wrote:
On Thu, 2016-09-01 at 11:23 -0700, Ben Greear wrote:
Could easily be that others are corrupted too, but since probe resp
is bad, the association will not proceed.
makes sense.
Heh, I spent 4 days tracking this down, so I wanted to be precise in
On Thu, 2016-09-01 at 11:23 -0700, Ben Greear wrote:
>
> Could easily be that others are corrupted too, but since probe resp
> is bad, the association will not proceed.
makes sense.
> Heh, I spent 4 days tracking this down, so I wanted to be precise in
> my bug report :)
Ahrg, ouch. Sorry
On Thu, 2016-09-01 at 20:30 +0200, Toke Høiland-Jørgensen wrote:
> > seq=1,frag=0
> > seq=2,frag=0
> > seq=2,frag=1
> > seq=2,frag=1
> >
> > if reordering happened?
>
> (assuming the last line was supposed to read 'seq=1,frag=1')
I did actually mean seq=2,frag=1, since the seqno assignment
Johannes Berg writes:
>> To avoid having to deal with fragmentation on dequeue, the split is
>> set to be after the fragmentation handler. This means that some
>> reordering of TX handlers is necessary, and some handlers had to be
>> made aware of fragmentation due to
On 09/01/2016 11:53 AM, Johannes Berg wrote:
On Thu, 2016-09-01 at 11:23 -0700, Ben Greear wrote:
Could easily be that others are corrupted too, but since probe resp
is bad, the association will not proceed.
makes sense.
Heh, I spent 4 days tracking this down, so I wanted to be precise in
On 09/01/2016 11:01 AM, Johannes Berg wrote:
If someone has any idea of why this patch might trigger it, please
let me know.
I'll keep digging in the meantime...
Revert "mac80211: don't advertise NL80211_FEATURE_FULL_AP_CLIENT_STATE"
With a sufficiently recent hostapd/wpa_supplicant,
Hi Kalle,
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Thursday, September 01, 2016 8:23 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org
> Subject: Re: [PATCH] mwifiex: handle edmac vendor command
>
> Amitkumar Karwar writes:
>
> >> From: Kalle
I have a variant of the ath10k 10.1 firmware that puts all frames, including
management,
over the normal htt packet transport. This has worked fine for many kernels,
but
for reasons that currently escape me, the patch below breaks this firmware.
On air, I see corrupted probe responses, seems
Mimi Zohar writes:
> There weren't any problems on linux-4.7 kernels. I'm getting the
> following traceback on linux-4.8-rc1/-rc4 kernels. Let me know if you
> need any additional information.
>
> [ 64.006529] WARNING: CPU: 3 PID: 94 at
>
From: Mohammed Shafi Shajakhan
The error assigned does not seems to be used anywhere,
fixes nothing just a small cleanup
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath10k/wmi.c | 1 -
1 file changed, 1 deletion(-)
The TXQ intermediate queues can cause packet reordering when more than
one flow is active to a single station. Since some of the wifi-specific
packet handling (notably sequence number and encryption handling) is
sensitive to re-ordering, things break if they are applied before the
TXQ.
This
On Wed, Aug 31, 2016 at 09:32:56PM +0200, Matthias Beyer wrote:
> Pinging here as nobody responded yet.
>
> Maybe this was overlooked.
Nope, it was only a week, staging patches are at the bottom of my queue,
please give me time to get to them, I process them usually ever few
weeks...
thanks,
On Sat, Aug 27, 2016 at 02:40:44PM +0200, Luca Ceresoli wrote:
> Signed-off-by: Luca Ceresoli
> Cc: Larry Finger
> Cc: Jes Sorensen
> Cc: Greg Kroah-Hartman
> Cc:
Amitkumar Karwar writes:
>> From: Kalle Valo [mailto:kv...@codeaurora.org]
>> Sent: Tuesday, May 24, 2016 1:53 AM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org
>> Subject: Re: [PATCH] mwifiex: handle edmac vendor command
>>
>> Amitkumar Karwar
Using the software based channel scan mechanism from mac80211 keeps us
offline for 10-15 second, we should instead issue a start_scan/end_scan
on each channel reducing this time.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
channel, as such it should be a SMD client. This patch makes this
transition, now that we have the necessary frameworks available.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Correct the
Luca Coelho writes:
> This is a v2 of my pull request with the potential below array bounds
> access, reported by kbuild bot, fixed.
>
>> Another pull request, this time intended for 4.9. I have a lot of
>> patches to send, but I'll send smaller batches this time. :)
>>
>>
Luca Coelho writes:
> Here are 4 patches intended for 4.8. They are all very small and low
> risk, but fix some actual issues. More details in the tag description.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit
Johannes Berg writes:
>> Yeah, was going to do that anyway. But since I'm touching the code
>> anyway, this might be an opportunity to avoid constructs like this:
>>
>> if (!invoke_tx_handlers(tx))
>> /* continue sending the packet */
>>
>> Most other succeed/fail
> Yeah, was going to do that anyway. But since I'm touching the code
> anyway, this might be an opportunity to avoid constructs like this:
>
> if (!invoke_tx_handlers(tx))
> /* continue sending the packet */
>
> Most other succeed/fail functions seem to be of type bool, so it
> would help
Johannes Berg writes:
>> > They have three possible values ... :)
>>
>> Ah, no, not the handlers themselves. Meant the invoke_tx_handlers()
>> function (or all three of them after my patch; hence the plural). To
>> avoid the "0 means true" confusion you alluded to :)
> > They have three possible values ... :)
>
> Ah, no, not the handlers themselves. Meant the invoke_tx_handlers()
> function (or all three of them after my patch; hence the plural). To
> avoid the "0 means true" confusion you alluded to :)
>
Ah. Actually, even I got confused and thought the
Johannes Berg writes:
>> > > +static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
>> > > +{
>> > > +return invoke_tx_handlers_early(tx) ||
>> > > invoke_tx_handlers_late(tx);
>> > > +}
>> >
>> > Ugh, please, no, don't be tricky where it's not
> > > +static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
> > > +{
> > > + return invoke_tx_handlers_early(tx) ||
> > > invoke_tx_handlers_late(tx);
> > > +}
> >
> > Ugh, please, no, don't be tricky where it's not necessary. Now
> > every
> > person reading this has to first look up the
Johannes Berg writes:
>> +static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
>> +{
>> +return invoke_tx_handlers_early(tx) ||
>> invoke_tx_handlers_late(tx);
>> +}
>
> Ugh, please, no, don't be tricky where it's not necessary. Now every
> person reading
30 matches
Mail list logo