From: Christian Lamparter <chunkeey@googlemail.com>
To: Richard Farina <sidhayn@gmail.com>
Cc: linux-wireless@vger.kernel.org, scchen@qca.qualcomm.com,
linville@tuxdriver.com, johannes@sipsolutions.net,
marco@tampabay.rr.com, janusz.dziedzic@gmail.com
Subject: Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode
Date: Wed, 12 Sep 2012 03:08:29 +0200 [thread overview]
Message-ID: <201209120308.30985.chunkeey@googlemail.com> (raw)
In-Reply-To: <504FCD39.80705@gmail.com>
On Wednesday 12 September 2012 01:46:01 Richard Farina wrote:
> On 09/11/2012 07:26 PM, Christian Lamparter wrote:
> > On Wednesday 12 September 2012 00:03:40 Richard Farina wrote:
> >> On 09/11/2012 05:18 PM, Christian Lamparter wrote:
> >>> Several people have complained about an unusual
> >>> and undocumented feature of the AR9170 hardware:
> >>>
> >>> In siffer mode, the hardware generates spurious
> >>> ACK frames for every received frame... even
> >>> broadcasts.
> >>>
> >>> The reason for this malfunction is unknown:
> >>> <http://marc.info/?l=linux-wireless&m=134517238506033>
> >>> But there's a workaround: Instead of the special
> >>> sniffer mode, the hardware will be put into
> >>> station mode and all rx filters are disabled.
> >> I am by no means an expert here but wouldn't it be better to disable
> >> ACK? Or is this not really an option?
> > Oh AFAIK there's some nifty software which emulates
> > some sort of accesspoint by (ab-)using monitor mode
> > and injection. And in this case having a device which
> > ACKs any frame destined for the semi-fake ap might be
> > a "good thing".
>
> Are you referencing airbase-ng here? Airbase-ng assumes
> the hardware does not ack in monitor mode and therefore
> does it itself. Mind you, I'm not saying it wouldn't be
> nice to have the hardware ack (VASTLY improved response
> time for one) but a monitor mode vif is assumed to not
> transmit anything at all, unless we specifically inject
> it.
>
> An ack on/off (default off) would be awesome, but baring
> that the only sane choice is off.
I'm no expert either, but isn't airbase-ng more of a client
attack tool suite than a useful softAP? No, it must have
been a different software then.
Anyway, now the hardware will only react to frames that
are "directed" (DA matches either the main, or one of
the 8 vif mac addresses) to it (is this now sane or
not?). So, the hardware ack ability is not going to just
disappear, if someone is already depending on it.
(BTW: wasn't there once some sort of a "tx ack" control
interface in mac80211 debugfs path? Does anybody know
what happend to it?)
Regards,
Chr
next prev parent reply other threads:[~2012-09-12 1:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 21:18 [PATCH] carl9170: fix spurious transmissions in sniffer mode Christian Lamparter
2012-09-11 22:03 ` Richard Farina
2012-09-11 23:26 ` Christian Lamparter
2012-09-11 23:46 ` Richard Farina
2012-09-12 1:08 ` Christian Lamparter [this message]
2012-09-12 7:09 ` Johannes Berg
2012-10-13 8:59 ` Christian Lamparter
2012-10-26 18:07 ` Christian Lamparter
2012-10-26 21:03 ` John W. Linville
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=201209120308.30985.chunkeey@googlemail.com \
--to=chunkeey@googlemail.com \
--cc=janusz.dziedzic@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marco@tampabay.rr.com \
--cc=scchen@qca.qualcomm.com \
--cc=sidhayn@gmail.com \
/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).