All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruno Randolf <br1@einfach.org>
To: Jouni Malinen <j@w1.fi>
Cc: linville@tuxdriver.com, ath5k-devel@venema.h4ckr.net,
	linux-wireless@vger.kernel.org, netrolller.3d@gmail.com,
	benoit.papillault@free.fr
Subject: Re: [PATCH v2] ath5k: fix injection in monitor mode
Date: Wed, 3 Mar 2010 10:10:49 +0900	[thread overview]
Message-ID: <201003031010.49887.br1@einfach.org> (raw)
In-Reply-To: <20100302094238.GA24391@jm.kir.nu>

On Tuesday 02 March 2010 18:42:38 Jouni Malinen wrote:
> On Tue, Mar 02, 2010 at 11:51:58AM +0900, Bruno Randolf wrote:
> > injected frames have to use AR5K_PKT_TYPE_NORMAL, otherwise the hardware
> > thinks it can mess with the contents of the frame - e.g. update the TSF
> > of an injected beacon. injected frames should be sent as they are
> > provided.
> 
> Why would we never want the hardware to update fields in injected
> frames? Unless I missed something, this seems to break hostapd use cases
> where the hardware is indeed expected to update the timestamp in Probe
> Response frames and set up seq# and duration etc. as appropriate for the
> frames (the latter may be driver/mac80211 work; the timestamp needs to
> come from hardware/firmware).

ok, i see.

> If we want to have an option to prevent hardware from touching the frame
> payload, that really should be an option (a radiotap and TX control
> flags, etc.), not default functionality for monitor interface. The use
> case for this seems to be some kind of testing purpose and that should
> not really break more common functionality.

yes, we use it for testing IBSS mode (merging, TSF updates) by injecting 
custom beacons. i guess other packet injectors would also assume that their 
packets go out untouched.

so what would be a way to support that properly?
what about a monitor mode flag?

bruno

  parent reply	other threads:[~2010-03-03  1:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-02  2:51 [PATCH v2] ath5k: fix injection in monitor mode Bruno Randolf
2010-03-02  9:42 ` Jouni Malinen
2010-03-02 10:02   ` Gábor Stefanik
2010-03-03  1:10   ` Bruno Randolf [this message]
2010-03-03  8:18     ` Jouni Malinen
2010-03-03  8:42       ` Gábor Stefanik

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=201003031010.49887.br1@einfach.org \
    --to=br1@einfach.org \
    --cc=ath5k-devel@venema.h4ckr.net \
    --cc=benoit.papillault@free.fr \
    --cc=j@w1.fi \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netrolller.3d@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.