Can we ignore frames with invalid BSSID in IBSS mode?

[Johannes Berg]

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.

> 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