On 09/02/2016 05:09 AM, Michal Kazior wrote:
On 1 September 2016 at 22:52, Ben Greear wrote:
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 no
On 1 September 2016 at 22:52, Ben Greear wrote:
> 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.
>>
>>>
> 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 t
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
m
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 about
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
m
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, t
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 t