The initial rate for STA's using rc80211_simple is set to the last
rate in the rate table. For situations for which the signal is weak,
the rate may be too high for authentication and association. Although
the rc80211_simple module will adjust the speed, the response may not
be fast enough for a successful connection. This modification sets the
initial rate to the lowest supported value.
Signed-off-by: Larry Finger <[email protected]>
---
Index: wireless-dev/net/mac80211/rc80211_simple.c
===================================================================
--- wireless-dev.orig/net/mac80211/rc80211_simple.c
+++ wireless-dev/net/mac80211/rc80211_simple.c
@@ -283,14 +283,15 @@ static void rate_control_simple_rate_ini
int i;
sta->txrate = 0;
mode = local->oper_hw_mode;
- /* TODO: what is a good starting rate for STA? About middle? Maybe not
- * the lowest or the highest rate.. Could consider using RSSI from
- * previous packets? Need to have IEEE 802.1X auth succeed immediately
- * after assoc.. */
+ /* TODO: This routine should consider using RSSI from previous packets
+ * as we need to have IEEE 802.1X auth succeed immediately after assoc..
+ * Until that method is implemented, we will use the lowest supported rate
+ * as a workaround, */
for (i = 0; i < mode->num_rates; i++) {
if ((sta->supp_rates & BIT(i)) &&
(mode->rates[i].flags & IEEE80211_RATE_SUPPORTED))
sta->txrate = i;
+ break;
}
}
On Thursday 07 June 2007 20:49, Larry Finger wrote:
> Does mode->rates[0].flags automatically have IEEE80211_RATE_SUPPORTED set?
> That wasn't clear to me.
>
Yes. (see ieee80211_prepare_rates)
-Michael Wu
On 6/8/07, Jouni Malinen <[email protected]> wrote:
> On Fri, Jun 08, 2007 at 11:21:46AM +0200, Jiri Benc wrote:
> > On Thu, 7 Jun 2007 22:05:21 -0700, Michael Wu wrote:
> > > On Thursday 07 June 2007 20:49, Larry Finger wrote:
> > > > Does mode->rates[0].flags automatically have IEEE80211_RATE_SUPPORTED set?
> > > > That wasn't clear to me.
> > > >
> > > Yes. (see ieee80211_prepare_rates)
> >
> > No :-) In theory, you can use PRISM2_HOSTAPD_SET_RATE_SETS ioctl to
> > disable the lowest available rate. Yes, that's deprecated and bad thing
> > to do; but unfortunately, it can be done with the current code.
>
> There are some odd cases, where disabling the lowest supported rate may
> even be required due to regulatory rules..
Just curious -- are you aware of a regulatory domain where this is the
case? Who defines those rules? For example, AFAICT FCC only talk about
power, and spectrum ranges. Where would I even look for these type of
restrictions?
Luis
On Fri, Jun 08, 2007 at 02:12:57PM -0400, Luis R. Rodriguez wrote:
> On 6/8/07, Jouni Malinen <[email protected]> wrote:
> >There are some odd cases, where disabling the lowest supported rate may
> >even be required due to regulatory rules..
> Just curious -- are you aware of a regulatory domain where this is the
> case? Who defines those rules? For example, AFAICT FCC only talk about
> power, and spectrum ranges. Where would I even look for these type of
> restrictions?
I don't remember all the details, but one case I've heard of was about
a rule that specified high bandwidth wireless operations and what
exactly would be high enough to be acceptable. And no, this was not
from FCC. Unfortunately, I do not have any good pointers for where to
look for this type of restrictions in an easy to use form (as in
something that I could easily understand ;-).
One related issue is the requirement for not transmitting continuously
for longer than a quite short time period before sensing the medium
again (this is from Japan). This may require at least fragmentation
based on TX rate (i.e., if low rate is used, fragmentation threshold
needs to be set lower) and in some cases, it may just be easier to drop
the lowest TX rates completely to avoid frames that may take long time
to transmit.
--
Jouni Malinen PGP id EFC895FA
On Fri, Jun 08, 2007 at 11:21:46AM +0200, Jiri Benc wrote:
> On Thu, 7 Jun 2007 22:05:21 -0700, Michael Wu wrote:
> > On Thursday 07 June 2007 20:49, Larry Finger wrote:
> > > Does mode->rates[0].flags automatically have IEEE80211_RATE_SUPPORTED set?
> > > That wasn't clear to me.
> > >
> > Yes. (see ieee80211_prepare_rates)
>
> No :-) In theory, you can use PRISM2_HOSTAPD_SET_RATE_SETS ioctl to
> disable the lowest available rate. Yes, that's deprecated and bad thing
> to do; but unfortunately, it can be done with the current code.
There are some odd cases, where disabling the lowest supported rate may
even be required due to regulatory rules.. Regardless of whether it is
considered bad thing or not in general, I would hope that this
functionality remains and all rate control algorithms prepare to handle
such an anomaly.
> Larry's patch is IMHO correct.
Agreed.
--
Jouni Malinen PGP id EFC895FA
On Friday 08 June 2007 02:21, Jiri Benc wrote:
> No :-) In theory, you can use PRISM2_HOSTAPD_SET_RATE_SETS ioctl to
> disable the lowest available rate. Yes, that's deprecated and bad thing
> to do; but unfortunately, it can be done with the current code.
>
Oh, nevermind, I didn't notice the [0] index.
> Larry's patch is IMHO correct.
>
I was pointing out the fact that the loop now unconditionally stops after the
first iteration, which does not seem like what was intended given the
indentation level of the break. mode->rates[0].flags has nothing to do with
my comment though I answered that question (wrongly) anyway. :)
-Michael Wu
On Thu, Jun 07, 2007 at 08:38:27PM -0700, Michael Wu wrote:
> On Thursday 07 June 2007 20:03, Larry Finger wrote:
> > for (i = 0; i < mode->num_rates; i++) {
> > if ((sta->supp_rates & BIT(i)) &&
> > (mode->rates[i].flags & IEEE80211_RATE_SUPPORTED))
> > sta->txrate = i;
> > + break;
> > }
> Uh, what's the point of having a loop if you're gonna do that? ;)
How about "I think you forgot some curly braces"? Until Johannes
posted his patch (which you could have done just as easily) I had no
idea what you were talking about here...
John
--
John W. Linville
[email protected]
On Mon, Jun 11, 2007 at 11:11:07AM -0700, Michael Wu wrote:
> On Monday 11 June 2007 10:31, John W. Linville wrote:
> > How about "I think you forgot some curly braces"? Until Johannes
> > posted his patch (which you could have done just as easily) I had no
> > idea what you were talking about here...
> >
> Well, I did end up explaining it later after it was obvious that Larry Finger
> didn't understand what I mean.
Nothing says it like a patch...
> As for posting a patch to fix it? I figured Larry Finger would post a fixed
> patch after I explained the comment. I didn't think you were going to merge
> it.
I put it in wireless-dev -- I might ask to be forgiven, if I thought
that was a problem.
Are you satisfied with that patch as it stands now (i.e. w/ the
proper braces)? Or do you want to peck at it some more?
John
--
John W. Linville
[email protected]
On Monday 11 June 2007 11:43, John W. Linville wrote:
> Are you satisfied with that patch as it stands now (i.e. w/ the
> proper braces)? Or do you want to peck at it some more?
>
It's fine.
Thanks,
-Michael Wu
On Thu, 7 Jun 2007 22:05:21 -0700, Michael Wu wrote:
> On Thursday 07 June 2007 20:49, Larry Finger wrote:
> > Does mode->rates[0].flags automatically have IEEE80211_RATE_SUPPORTED set?
> > That wasn't clear to me.
> >
> Yes. (see ieee80211_prepare_rates)
No :-) In theory, you can use PRISM2_HOSTAPD_SET_RATE_SETS ioctl to
disable the lowest available rate. Yes, that's deprecated and bad thing
to do; but unfortunately, it can be done with the current code.
Larry's patch is IMHO correct.
Jiri
--
Jiri Benc
SUSE Labs
On Fri, Jun 08, 2007 at 04:10:10PM -0400, Luis R. Rodriguez wrote:
> On 6/8/07, Jouni Malinen <[email protected]> wrote:
> >One related issue is the requirement for not transmitting continuously
> >for longer than a quite short time period before sensing the medium
> >again (this is from Japan).
> Wow, aren't those regulatory requirements breaking the spec? I wonder
> if loading a different rate algorithm depending on regdomain would do
> the job in a case like this.
What do you mean by breaking the spec? Local regulations come first and
whatever is to be used to transmit better comply with those no matter
what the IEEE 802.11 standard says. Just using a different rate
algorithm may not be enough to handle this kind of cases. There needs
to be a way to enforce some rules like the maximum continuous
transmission at a lower layer and somehow adjust the parameters if
needed.
This particular rule may not be too much of an issue for now since it
came up in a case where non-standard TX rate were used (i.e., something
below the minimum used in 802.11a). Anyway, we should try to be able to
handle whatever rules comes up now or in the future. Of course, one way
of handling limitations is not to allow transmissions at all, but that
may not always be the ideal solution.
--
Jouni Malinen PGP id EFC895FA
On 6/8/07, Jouni Malinen <[email protected]> wrote:
> On Fri, Jun 08, 2007 at 02:12:57PM -0400, Luis R. Rodriguez wrote:
> > On 6/8/07, Jouni Malinen <[email protected]> wrote:
> > >There are some odd cases, where disabling the lowest supported rate may
> > >even be required due to regulatory rules..
>
> > Just curious -- are you aware of a regulatory domain where this is the
> > case? Who defines those rules? For example, AFAICT FCC only talk about
> > power, and spectrum ranges. Where would I even look for these type of
> > restrictions?
>
> I don't remember all the details, but one case I've heard of was about
> a rule that specified high bandwidth wireless operations and what
> exactly would be high enough to be acceptable. And no, this was not
> from FCC. Unfortunately, I do not have any good pointers for where to
> look for this type of restrictions in an easy to use form (as in
> something that I could easily understand ;-).
:( We'll have to just start capturing and documenting these type of
weird regulatory anomalies on the wiki.
> One related issue is the requirement for not transmitting continuously
> for longer than a quite short time period before sensing the medium
> again (this is from Japan). This may require at least fragmentation
> based on TX rate (i.e., if low rate is used, fragmentation threshold
> needs to be set lower) and in some cases, it may just be easier to drop
> the lowest TX rates completely to avoid frames that may take long time
> to transmit.
Wow, aren't those regulatory requirements breaking the spec? I wonder
if loading a different rate algorithm depending on regdomain would do
the job in a case like this.
Luis
On Monday 11 June 2007 10:31, John W. Linville wrote:
> How about "I think you forgot some curly braces"? Until Johannes
> posted his patch (which you could have done just as easily) I had no
> idea what you were talking about here...
>
Well, I did end up explaining it later after it was obvious that Larry Finger
didn't understand what I mean.
As for posting a patch to fix it? I figured Larry Finger would post a fixed
patch after I explained the comment. I didn't think you were going to merge
it.
-Michael Wu
On Thursday 07 June 2007 20:03, Larry Finger wrote:
> for (i = 0; i < mode->num_rates; i++) {
> if ((sta->supp_rates & BIT(i)) &&
> (mode->rates[i].flags & IEEE80211_RATE_SUPPORTED))
> sta->txrate = i;
> + break;
> }
Uh, what's the point of having a loop if you're gonna do that? ;)
-Michael Wu
Michael Wu wrote:
> On Thursday 07 June 2007 20:03, Larry Finger wrote:
>> for (i = 0; i < mode->num_rates; i++) {
>> if ((sta->supp_rates & BIT(i)) &&
>> (mode->rates[i].flags & IEEE80211_RATE_SUPPORTED))
>> sta->txrate = i;
>> + break;
>> }
> Uh, what's the point of having a loop if you're gonna do that? ;)
Does mode->rates[0].flags automatically have IEEE80211_RATE_SUPPORTED set? That wasn't clear to me.
Larry