linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).