All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Koutny <vlado@work.ksp.sk>
To: bruno randolf <bruno@thinktube.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC] WARNING: at net/mac80211/ieee80211_rate.h:159 rate_lowest_index()
Date: Wed, 30 Apr 2008 17:03:25 +0200	[thread overview]
Message-ID: <48188A3D.70707@work.ksp.sk> (raw)
In-Reply-To: <200804292042.20500.bruno@thinktube.com>

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

>> [...]
>>
>> The question is how sta->supp_rates should be initialized:
>>
>> - we could initialize it to our sta's rates, but then we could
>>   probably transmit to a station at unsupported rate
> 
> isn't this what is done right now, and the rateset is zero sometimes and then 
> we get the warning?

Yes, kind-of. It is initialized to the rateset of an ibss we are part of,
which is the one of ibss we are joining to, or our supported rateset if we
create a new one. However, it is 0 before one of those 2 actions happen, and
then we get the warning.

> this might be wrong anyways: as you said it could make us send frames at an 
> unsupported rate.

Actually, this can happen even now:
- we join an g-ibss, thus setting the rateset to 1-54
- we receive a data frame from a b-only station -> we assign all 1-54 rates to it
- we send something to this station
Probably not a big issue, as a) we will update the sta-rateset on its beacon,
and b) I would expect that such an ibss would adapt to 1-11 only in the
presence of b-only station..

> 
>> - add new ibss station only on received beacon, not on a data frame;
>>   currently, beacons are ignored for this purpose (they just update
>>   the bss list later on)
> 
> i think stations should be added on reception of both beacons and data frames.

Or, do we need this information _before_ joining/creating a new ibss?
Couldn't we just ignore all STAs around until we have a reason not to?

> 
>> - something else (like 1Mbps only)?
> 
> what about the rate of the currently received data frame (and maybe any other 
> rates we could safely deduce from that)?

Yes, that would be a reasonable option - providing that we have the rate
(which we should - there is a WARN_ON(1) in rx-path if it is not set correctly)

As I think about that, I would suggest:
- no sta info is being collected prior to join/create
- sta entry is added/updated on each beacon with reported rateset
- sta entry is added/updated on data frames with just the received-rate

Vlado

> 
> bruno


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 370 bytes --]

  reply	other threads:[~2008-04-30 15:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29 16:01 [RFC] WARNING: at net/mac80211/ieee80211_rate.h:159 rate_lowest_index() Vladimir Koutny
2008-04-29 18:42 ` bruno randolf
2008-04-30 15:03   ` Vladimir Koutny [this message]
2008-04-30 15:05     ` Johannes Berg
2008-04-30 15:46       ` Vladimir Koutny
2008-04-30 14:20 ` 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=48188A3D.70707@work.ksp.sk \
    --to=vlado@work.ksp.sk \
    --cc=bruno@thinktube.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /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.