linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
To: linux-wireless@vger.kernel.org
Cc: Thomas Pedersen <thomas@cozybit.com>,
	johannes@sipsolutions.net, antonio@open-mesh.com,
	marek@open-mesh.com,
	Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Subject: [RFC] design discussion: Collecting information for (non-peer) stations
Date: Fri, 15 Feb 2013 18:19:38 +0100	[thread overview]
Message-ID: <20130215171938.GA4140@pandem0nium> (raw)

[-- Attachment #1: Type: text/plain, Size: 2875 bytes --]

Hello wireless folks,

Mathias Kretschmer and me would like to bring another new feature to the kernel:
Collecting information for (non-peer) stations. As far as I know, at least
Antonio and Thomas are interested in a similar feature as well, and it seems
Antonio has already prepared some code. I'd like to present our ideas and
requirements to this feature and would like to ask Antonio and Thomas, and everyone
else interested in this feature, to do the same. Then we can hopefully come up
with a design which is acceptable for upstream kernels and useful for everyone.

We would like to gather statistics for all peers, both connected and not connected
to our current IBSS. We do the same in userspace currently using a monitor interface,
but reading every packet from this monitor interface has a huge thoughput limitation
on our routers, and is therefore not acceptable for productive use. The statistics are
then used to evaluate link quality and make some higher level decisions.

The statistics we are interested in are, per station (identified by sender MAC address), for
both peer and non-peer stations:
 * RSSI (*)
 * sequence number gap size (*) - monitors the sequence number of a 80211 packet, per queue
 * bad frame count (badFCS and such)
 * total frame count
 * bytes received
 * last seen - timestamp

Fields marked with (*) should capture min, max, avg, count, sum, sum_square. Other
statistics (stddev, rms) can then be calculated in userspace using floating point numbers.
The other fields can be normal counters. Some of the fields are already accesible for connected
peers (like RSSI, last seen -> iw station dump), some of them are new, and none of them are currently
available for non-peer stations. We probably don't need all of them integrated
in mainline as they might be only interesting for us, but this is just to give you an idea.

Regarding the kernel interface, we don't have any requirements, from nl80211 to debugfs, everything
would be fine. We will access the data with a custom program.

Commands we would like to propose are:
 * start collecting - this feature should not run by default to avoid bloating memory for users who
   don't even need this
 * stop collecting
 * read - dumps the data for all stations
 * read + reset - dump the data and reset information for all stations. This should also clean up stations,
   at least those which are not connected to the BSS, to not bloat the station table.

I guess the right position to implement this is mac80211 receive path. Our intended platform
is ath9k/ath5k, but that feature should work with any mac80211 driver. We don't care if sta_info
structs are allocated or custom structures are used, as long as we can receive a list of stations
which includes peer and non-peer stations, along with their statistics.

We are looking forward to your thoughts. :)

Cheers,
        Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2013-02-15 17:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 17:19 Simon Wunderlich [this message]
2013-02-18 14:30 ` [RFC] design discussion: Collecting information for (non-peer) stations Johannes Berg
2013-02-18 14:33   ` Johannes Berg
2013-02-18 14:46     ` Antonio Quartulli
2013-02-18 15:29       ` Johannes Berg
2013-02-18 15:38         ` Antonio Quartulli
2013-02-18 15:43           ` Johannes Berg
2013-02-18 15:49             ` Antonio Quartulli
2013-02-18 15:58               ` Johannes Berg
2013-02-18 16:07                 ` Antonio Quartulli
2013-02-18 16:51                   ` Johannes Berg
2013-02-18 19:36                     ` Mathias Kretschmer
2013-02-20 17:19                     ` Simon Wunderlich
2013-02-20 19:10                       ` Thomas Pedersen
2013-02-21 17:19                         ` Simon Wunderlich
2013-02-19  9:32 ` Thomas Hühn
2013-02-20 17:49   ` Simon Wunderlich
2013-02-20 18:04   ` Mathias Kretschmer
2013-02-22 10:07 ` Zefir Kurtisi
2013-02-22 11:43   ` Simon Wunderlich
2013-02-22 12:34     ` Zefir Kurtisi
2013-02-22 16:21 ` Felix Fietkau
2013-02-22 16:36   ` Antonio Quartulli
2013-02-22 17:03     ` Felix Fietkau
2013-02-22 17:42       ` Adrian Chadd
2013-02-25 10:28         ` Simon Wunderlich
2013-03-08 14:13           ` Simon Wunderlich
2013-03-11 12:01             ` Zefir Kurtisi
2013-03-25 14:43               ` Simon Wunderlich
2013-02-22 17:42       ` Thomas Pedersen

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=20130215171938.GA4140@pandem0nium \
    --to=simon.wunderlich@s2003.tu-chemnitz.de \
    --cc=antonio@open-mesh.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=marek@open-mesh.com \
    --cc=mathias.kretschmer@fokus.fraunhofer.de \
    --cc=thomas@cozybit.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).