linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mattias Nissler <mattias.nissler@gmx.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "Mikko Virkkilä" <mikko.virkkila@bluegiga.com>,
	"Ivo van Doorn" <ivdoorn@gmail.com>,
	rt2400-devel@lists.sourceforge.net,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	dsd@gentoo.org, kune@deine-taler.de
Subject: Re: ACK matching [was: TX status reporting with help of an ack queue]
Date: Fri, 19 Sep 2008 12:19:39 +0200	[thread overview]
Message-ID: <1221819579.4491.34.camel@localhost> (raw)
In-Reply-To: <1221818057.10419.58.camel@johannes.berg>

On Fri, 2008-09-19 at 11:54 +0200, Johannes Berg wrote:
> On Fri, 2008-09-19 at 11:46 +0200, Mattias Nissler wrote:
> 
> > This brings up the question whether we can do without tx status
> > reporting. Does anyone know why hostapd requires the tx status? As far
> > as I understand, mac80211 only uses the tx status reporting only for the
> > tx rate control. Rate control algos that don't use tx status are
> > definitely feasible (and in fact we'll need one for rt73).
> 
> mac80211 also uses it for reporting the sent frame to userspace on
> monitor interfaces.

Yeah, that's what hostapd relies on. But mac80211 really does not care
to much how userspace uses the information.

> 
> > I'll look into hostapd to figure out whether the tx status reporting is
> > really required when I find some time.
> 
> hostapd requires this because it needs to know whether a station
> acknowledged a frame or not to proceed its state machine, it's just how
> it has to work. If the hardware can't deal with that I guess you can't
> implement AP mode properly.

Well, maybe we can work around this requirement? I still need to learn
about the details, but what happens for example if the STA sends the ACK
and then resets due to a crash? I guess the AP is able to cope with
that, no? So maybe we can relax the rules a bit (unless we become really
incompliant with the standard of course).

Mattias


  reply	other threads:[~2008-09-19 10:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1221494693.14102.22.camel@virkkmi-linux>
2008-09-15 17:11 ` [RFC][PATCH] TX status reporting with help of an ack queue Ivo van Doorn
2008-09-15 17:56   ` Mattias Nissler
2008-09-15 18:03     ` Johannes Berg
2008-09-15 19:00       ` Mattias Nissler
2008-09-15 19:21         ` Johannes Berg
2008-09-15 19:39           ` Mattias Nissler
2008-09-15 19:46             ` Johannes Berg
2008-09-15 20:20               ` Mattias Nissler
2008-09-15 20:33                 ` Johannes Berg
2008-09-15 21:01                   ` Mattias Nissler
2008-09-24  0:59                     ` John W. Linville
2008-09-24  7:40                       ` Mattias Nissler
2008-09-24  8:34                         ` Johannes Berg
2008-09-15 21:28                   ` Ivo van Doorn
2008-09-15 21:41                     ` Mattias Nissler
2008-09-16 18:17                       ` Ivo van Doorn
2008-09-17 23:08                         ` Mattias Nissler
2008-09-16  6:24                   ` Mikko Virkkilä
2008-09-16  4:58         ` Mikko Virkkilä
2008-09-16 18:18           ` Ivo van Doorn
2008-09-18 20:37             ` Mattias Nissler
2008-09-18 22:29               ` ACK matching [was: TX status reporting with help of an ack queue] Mattias Nissler
2008-09-19  9:08                 ` Mikko Virkkilä
2008-09-19  9:46                   ` Mattias Nissler
2008-09-19  9:54                     ` Johannes Berg
2008-09-19 10:19                       ` Mattias Nissler [this message]
2008-09-19 10:31                         ` Johannes Berg
2008-09-19 13:51                           ` Mattias Nissler
2008-09-19 13:55                             ` Johannes Berg
2008-09-19 14:20                             ` Mikko Virkkilä
2008-09-19 17:50                               ` Jouni Malinen
2008-09-23  6:09                                 ` Mikko Virkkilä
2008-09-23  7:05                                   ` Mattias Nissler
2008-09-19 18:30                     ` Ivo van Doorn
2008-10-19  5:49                 ` Daniel Drake

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=1221819579.4491.34.camel@localhost \
    --to=mattias.nissler@gmx.de \
    --cc=dsd@gentoo.org \
    --cc=ivdoorn@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=kune@deine-taler.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mikko.virkkila@bluegiga.com \
    --cc=rt2400-devel@lists.sourceforge.net \
    /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).