From: Jouni Malinen <j@w1.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Mattias Nissler <mattias.nissler@gmx.de>,
Ivo van Doorn <ivdoorn@gmail.com>,
rt2400-devel <rt2400-devel@lists.sourceforge.net>,
linux-wireless <linux-wireless@vger.kernel.org>,
Stefano Brivio <stefano.brivio@polimi.it>
Subject: Re: tx_status reporting of RTS/CTS frames
Date: Thu, 13 Dec 2007 21:20:46 -0800 [thread overview]
Message-ID: <20071214052046.GF5698@jm.kir.nu> (raw)
In-Reply-To: <1197479702.6558.125.camel@johannes.berg>
On Wed, Dec 12, 2007 at 06:15:02PM +0100, Johannes Berg wrote:
> > rt2x00 devices can't generate rts/cts frames themselves, but rely on the
> > driver to generate them. Also, the hardware reports tx status back for
> > those frames. Now the question is whether these frames should be
> > reported back to mac80211 using ieee80211_tx_status[_irqsafe]. AFAIK,
> > this has some subtle effects, e.g. they won't show up on monitor
> > interfaces if we don't report them.
>
> They never show up on monitor interfaces for all other hardware because
> there the hardware handles them. How is it that rt2x00 cannot handle
> rts? It has to at least know that an RTS was sent and to send the frame
> only after the CTS, and that needs to be a MAC function and cannot be
> implemented in host software.
>
> So, I'd think they shouldn't be reported at all.
I'm not sure I understood the comment about monitor interface correctly.
If the driver is configured in monitor mode (or whatever you would call
a mode where it receives all frames), I do expect to see ACK and RTS/CTS
frames in mac80211 (and in the monitor interface in user space for that
matter). I hope that this won't be changed.
It sounds perfectly reasonable to not indicate these control frame
subtypes when in normal (non-monitor) mode since they are most likely
processed in hardware/microcode/firmware. However, if they provide
additional information (say, signal strength), it could be useful to
send them to mac80211 anyway to provide more information for TX rate
control.
--
Jouni Malinen PGP id EFC895FA
next prev parent reply other threads:[~2007-12-14 5:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-11 22:42 tx_status reporting of RTS/CTS frames Mattias Nissler
2007-12-12 17:15 ` Johannes Berg
2007-12-12 19:49 ` Mattias Nissler
2007-12-13 11:34 ` Johannes Berg
2007-12-13 18:56 ` Mattias Nissler
2007-12-13 19:14 ` Johannes Berg
2007-12-23 21:18 ` Ivo van Doorn
2007-12-14 5:20 ` Jouni Malinen [this message]
2007-12-14 12:10 ` Johannes Berg
2007-12-23 21:17 ` Ivo van Doorn
2007-12-23 21:29 ` Johannes Berg
2007-12-23 21:50 ` Ivo van Doorn
2007-12-23 21:54 ` Johannes Berg
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=20071214052046.GF5698@jm.kir.nu \
--to=j@w1.fi \
--cc=ivdoorn@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mattias.nissler@gmx.de \
--cc=rt2400-devel@lists.sourceforge.net \
--cc=stefano.brivio@polimi.it \
/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.