From: Nicolas Cavallari <Nicolas.Cavallari@green-communications.fr>
To: Ben Greear <greearb@candelatech.com>,
"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 10:13:30 +0200 [thread overview]
Message-ID: <560B99AA.5060401@green-communications.fr> (raw)
In-Reply-To: <5605D228.7050609@candelatech.com>
On 26/09/2015 01:00, 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?
Given that all it takes for an IBSS station to be added as a neighbor
is to see a frame from an unknown station with the same BSSID
(ieee80211_ibss_rx_no_sta(), just 10 lines below), your ath10k chip
will consider all stations for neighboring IBSS to be part of this BSS.
If RSN is used, or any other protocol/program that watches the list of
neighbors, then your station will try to communicate with them. Good
(those who don't ignore bssid checks) neighbors will normally drop the
frames. But if you deploy several machines ignoring the bssid check,
then they cannot run two concurrent IBSS networks.
Also, if there is a limit on how much stations the ath10k hardware can
handle, then that limit have a higher chance of being reached.
prev parent reply other threads:[~2015-09-30 8:13 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
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 [this message]
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=560B99AA.5060401@green-communications.fr \
--to=nicolas.cavallari@green-communications.fr \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
--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).