From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
ath10k <ath10k@lists.infradead.org>
Subject: Re: Can we ignore frames with invalid BSSID in IBSS mode?
Date: Wed, 30 Sep 2015 08:07:40 -0700 [thread overview]
Message-ID: <560BFABC.8090504@candelatech.com> (raw)
In-Reply-To: <1443595615.1859.2.camel@sipsolutions.net>
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@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2015-09-30 15:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 23:00 Can we ignore frames with invalid BSSID in IBSS mode? Ben Greear
2015-09-30 6:46 ` Johannes Berg
2015-09-30 15:07 ` Ben Greear [this message]
2015-09-30 15:17 ` Johannes Berg
2015-09-30 15:44 ` Ben Greear
2015-09-30 17:14 ` Johannes Berg
2015-09-30 17:20 ` Ben Greear
2015-09-30 18:30 ` Johannes Berg
2015-09-30 18:34 ` Ben Greear
2015-09-30 19:04 ` Felix Fietkau
2015-09-30 8:13 ` Nicolas Cavallari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=560BFABC.8090504@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).