On 09/30/2015 08:17 AM, Johannes Berg wrote:
On Wed, 2015-09-30 at 08:07 -0700, Ben Greear wrote:
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?
That seems reasonable.
Any idea how this could be done in the stack instead of the driver?
The problem is that this is a receiver-side issue, so even if I manage
to hack the ath10k firmware or driver rx logic, it would not fix any other
IBSS peer connected to ath10k peer.
Thanks,
Ben
Its not clear to me whether the rest of the AMPDU frames could
somehow be interleaved with frames from a different BSSID?
They can't be, at least not without some very strange hacks on the
transmitter.
johannes
--
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
--
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
