On 09/29/2015 11:46 PM, Johannes Berg wrote:
On Fri, 2015-09-25 at 16:00 -0700, Ben Greear wrote:
It seems that ath10k ar988X hardware has a bug where the BSSID
for IBSS AMSDU frames is all zeros. The 'main' 636 ath10k firmware
does not seem to use AMSDUs for IBSS, and when I enable it in my CT
firmware, then I see the breakage. So, I suspect it is not
just a simple software/firmware bug.
If I simply ignore the bssid_match check in ieee80211_accept_frame,
then it seems everything runs fine.
So, I'm curious if anyone knows what sorts of bad things could happen
if the bssid_match check is ignored? Maybe bcast/mcast frames could
be accepted when they shouldn't be in certain cases?
You could end up accepting multicast frames from a different,
overlapping, BSS? Seems like a bad idea.
It's definitely not a great idea.
In my testing, I always see the first frame of the AMPDU have
a proper IBSS BSSID. Any idea if it would be OK (and even possible)
for the driver or stack to detect this and save the BSSID aside
for the subsequent frames?
Its not clear to me whether the rest of the AMPDU frames could
somehow be interleaved with frames from a different BSSID?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
