I've observed an undesirable change in behaviour of rt2x00 as a result of
Johannes Berg's patch 3d4803379613c763f5a7863e8249b63d190af5e6
(remove all prism2 ioctls).
It used to consistently default to 802.11g mode on g capable hardware. Because
that patch removed the lines
- /* Use next_mode as the mode preference to
- * resolve non-unique channel numbers. */
- if (set && mode->mode != local->next_mode)
- continue;
in ieee80211_set_channel it now defaults to 11b unless I change the code that
calls ieee80211_register_hwmode. (I realise that the next_mode test is no
longer "right").
This is because ieee80211_set_channel will now prefer to select whichever was
the last mode for which the driver called ieee80211_register_hwmode whereas
the previous behaviour preferred the first registered mode. It seems as
though if there was a way to avoid calling Iieee80211_set_channel then the
setting of oper_hw_mode in ieee80211_register_hwmode would still prefer the
first registered mode.
Is it intended that the order of calling ieee80211_register_hwmode should
determine which mode should be preferred when multiple modes exist on the
same channel or is there either already or planned a better option for driver
writers? If calling order should determine preference should it be first or
last registered?
Adam Baker
On Tuesday 09 October 2007, Johannes Berg wrote:
> On Tue, 2007-10-09 at 16:27 +0200, Ivo van Doorn wrote:
>
> > The IFS is also passed on as argument by mac80211 when it configures the
> > TX rings. The EIFS register is something different, all other Ralink devices
> > have only 1 value for the EIFS. I am not even sure how the device will react
> > when the same value is set for rt2500usb.
>
> Ok but IFS definitely needs to be set. EIFS I'm not entirely sure about,
> haven't looked at the timing diagrams for a long time.
Well that is my point, if the documentation is correct then rt2500usb
has 2 locations to initialize the IFS. So it would always be set and the question
would be what the impact would be to set the IFS per packet only.
But that is something I need to test with just some experiments.
> > I guess it requires some experimentation to see if initializing those
> > 2 registers differently has any effect. (And if it doesn't, then rt2500usb doesn't
> > require to know whether it is operating in B or G mode at all).
>
> That won't be easy to tell, but the IFS is different afaik so there the
> mode has an influence. But I think that this mode setting need not be
> tied to the frequency table.
Well I just had another thought about this:
Legacy driver only makes the difference when it is configured to use
802.11B it doesn't make this difference for the CCK rates.
This means that the device would be able to operate correctly for
802.11B even with the 802.11G timing initialization. Because according
to the way the legacy driver is setup, working in 802.11G while working
with the CCK rates would be possible.
This also means associating to 802.11B AP's while in 802.11G mode.
So we might be making a big deal out of something while the source
of the problem is very simple: The legacy driver code is just wrong. ;)
Ivo
Adam Baker reported that the prism2 ioctl removal changed behaviour
in that now the selection order was the other way around as before.
New API is planned but not done yet, so for now just use the first
matching channel in any mode as was previous behaviour with an unset
next_mode.
Signed-off-by: Johannes Berg <[email protected]>
---
NB: untested patch, but I'm confident it will "fix" this behaviour change.
net/mac80211/ieee80211_ioctl.c | 1 +
1 file changed, 1 insertion(+)
--- wireless-dev.orig/net/mac80211/ieee80211_ioctl.c 2007-10-08 12:19:36.565111702 +0200
+++ wireless-dev/net/mac80211/ieee80211_ioctl.c 2007-10-08 12:20:33.185111702 +0200
@@ -306,6 +306,7 @@ int ieee80211_set_channel(struct ieee802
local->oper_channel = chan;
local->oper_hw_mode = mode;
set++;
+ break;
}
}
}
On Tue, Oct 09, 2007 at 11:21:42AM +0200, Johannes Berg wrote:
> On Mon, 2007-10-08 at 10:32 -0400, Mike Kershaw wrote:
>
> > I'd vote for allowing the user to set a mode - just like they're
> > allowed to lock an AP association to a specific MAC, bypassing the
> > hardware roaming algos.
> >
> > I've hit situations in the past where a card can get a very weak 11g
> > link but a perfectly usable 11b link, and the hw did not want to drop
> > back to 11b on its own. Being able to lock to 11b only was key.
>
> Actually, what you're advocating sounds like "please let me restrict the
> bitrates to use" rather than "please lock me to a mode". And we need
> that functionality anyway for AP mode.
Not quite, I've had situations where 9mbit at OFDM (11g) performed
differently than 11mbit at CCK (11b) for whatever reason. I'm also
fairly sure several cards (I want to say Intel 2200?) limit the max tx
power differently depending on the encoding type (100mW for 11b vs.
something less I don't remember off hand for 11g).
Just seems like useful functionality that it'd be a shame to lose.
-m
--
Mike Kershaw/Dragorn <[email protected]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
There's too much blood in my caffeine system!
> > Is it intended that the order of calling ieee80211_register_hwmode should
> > determine which mode should be preferred when multiple modes exist on the
> > same channel or is there either already or planned a better option for driver
> > writers? If calling order should determine preference should it be first or
> > last registered?
>
> That's actually a can of worms. Luis is working (I hope) on resolving
> these issues with mode vs. frequency selection. However, I'm not
> entirely convinced that mode selection should be done by userspace when
> we are acting as a client. I think we should simply exploit hardware
> capabilities as much as possible and then use the set that the AP
> advertised (or rather as much as we can support of that).
>
> Hence, for these questions it'd be good to know whether the ralink
> drivers do anything different based on the selected mode, and if they do
> (I assume they do because they register B *and* G modes) what it is.
The only difference currently in rt2x00 is for rt2500usb. The initialization
of the IFS and EIFS register is different.
I haven't gone through the legacy driver to see if there aren't any further
changes. But since I believe I have extracted all register initializations
that meant something from the legacy driver, this small difference can
probably be considered as the only thing.
> It'd probably help a lot with the design of the interface if you could
> answer that. I feel that mode selection should not be necessary since in
> G mode a device needs to have the capability to talk to B-only stations
> and hence must be able to "fall back" to B mode, we should therefore be
> able to exploit that capability without the driver ever registering
> different modes.
And is mac80211 doing that correctly at this time?
If so I could drop the 802.11B mode registration if that is the preferred action.
> In fact, I think that the driver can probably simply register the
> modulations/bitrates it can support orthogonally to the frequencies it
> supports, and the frequencies consist of only information about the
> frequency and possibly hardware value used to select it. This was part
> of what I posted a while ago when Luis was posting his regulatory stuff,
> and I think should be addressed while cleaning up that whole mess.
Only registering the supported rates and channels and let mac80211 sort
out the modes itself does sound like a good idea. :)
Ivo
On Tue, 2007-10-09 at 20:18 +0200, Ivo van Doorn wrote:
> > > True, but in G mode you are compatible with B. The legacy driver doesn't
> > > switch back to B mode when the AP is in B mode. This means that it will
> > > be using the G timing values.
> >
> > That sounds wrong.
>
> Not really, this would be the same behavior that you suggested earlier,
> when you stated that a driver should perhaps not register 802.11B mode
> when also registering 802.11G mode since it is backward compatible.
Well, in that was the assumption that mac80211 tells the driver whether
to enable shortslot or not regardless of B/G mode. It is only perfectly
compatible when B slot timing is used.
johannes
On Tue, 2007-10-09 at 19:54 +0200, Ivo van Doorn wrote:
> > Well, it's not too strange that it has two places since there's the SIFS
> > too which is needed for ACK/CTS timing, these packets aren't sent from
> > the host so you can't have those timings in a per-packet descriptor.
>
> You mean things like ACK_TIMEOUT, those are all seperate registers in the Ralink hardware.
No, I'm not talking about the ack timeout, I'm thinking of the short
interframe space (SIFS) which you wait after receiving a packet before
sending the ACK.
> ButI think I should be more clearer on this, rt2500pci and rt2500usb are
> basically the same chipset but only the bus type is different.
> What is notable is that _only_ rt2500usb has this IFS register, none of the
> other Ralink chipsets (including rt2500pci) have it.
That is indeed strange.
> True, but in G mode you are compatible with B. The legacy driver doesn't
> switch back to B mode when the AP is in B mode. This means that it will
> be using the G timing values.
That sounds wrong.
johannes
On Mon, Oct 08, 2007 at 11:55:39AM +0200, Johannes Berg wrote:
> That's actually a can of worms. Luis is working (I hope) on resolving
> these issues with mode vs. frequency selection. However, I'm not
> entirely convinced that mode selection should be done by userspace when
> we are acting as a client. I think we should simply exploit hardware
> capabilities as much as possible and then use the set that the AP
> advertised (or rather as much as we can support of that).
I'd vote for allowing the user to set a mode - just like they're
allowed to lock an AP association to a specific MAC, bypassing the
hardware roaming algos.
I've hit situations in the past where a card can get a very weak 11g
link but a perfectly usable 11b link, and the hw did not want to drop
back to 11b on its own. Being able to lock to 11b only was key.
-m
--
Mike Kershaw/Dragorn <[email protected]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
"Remember the book store down the road? That then became a book and coffee
shop? Now it's a 24-hour just-coffee shop. It's like evolution, only, without
the getting better."
On Tuesday 09 October 2007, Johannes Berg wrote:
> On Tue, 2007-10-09 at 19:54 +0200, Ivo van Doorn wrote:
>
> > > Well, it's not too strange that it has two places since there's the SIFS
> > > too which is needed for ACK/CTS timing, these packets aren't sent from
> > > the host so you can't have those timings in a per-packet descriptor.
> >
> > You mean things like ACK_TIMEOUT, those are all seperate registers in the Ralink hardware.
>
> No, I'm not talking about the ack timeout, I'm thinking of the short
> interframe space (SIFS) which you wait after receiving a packet before
> sending the ACK.
ok. That means that my previous point regarding the differences between
the legacy drivers remains valid. ;)
> > ButI think I should be more clearer on this, rt2500pci and rt2500usb are
> > basically the same chipset but only the bus type is different.
> > What is notable is that _only_ rt2500usb has this IFS register, none of the
> > other Ralink chipsets (including rt2500pci) have it.
>
> That is indeed strange.
:)
> > True, but in G mode you are compatible with B. The legacy driver doesn't
> > switch back to B mode when the AP is in B mode. This means that it will
> > be using the G timing values.
>
> That sounds wrong.
Not really, this would be the same behavior that you suggested earlier,
when you stated that a driver should perhaps not register 802.11B mode
when also registering 802.11G mode since it is backward compatible.
Ivo
On Tuesday 09 October 2007, Johannes Berg wrote:
> On Mon, 2007-10-08 at 23:08 +0200, Ivo van Doorn wrote:
>
> > The only difference currently in rt2x00 is for rt2500usb. The initialization
> > of the IFS and EIFS register is different.
>
> Ok so that's something we have to do in G-mode-compatible-with-B as
> well.
Well it might not even be needed at all.
The IFS is also passed on as argument by mac80211 when it configures the
TX rings. The EIFS register is something different, all other Ralink devices
have only 1 value for the EIFS. I am not even sure how the device will react
when the same value is set for rt2500usb.
> > And is mac80211 doing that correctly at this time?
>
> I'm not entirely sure. Are you setting the IFS/EIFS from any other
> place? :) I don't think it is doing that correctly.
Well in the drivers the following is done:
rt2500pci:
- config_duration() sets EIFS in the register
- write_tx_desc() sets IFS in the package descriptor
rt2500usb:
- config_phymode() sets EIFS and IFS in the registers.
- write_tx_desc() sets IFS in the package descriptor
Note that both config_duration() and config_phymode() are called by rt2x00lib
when mac80211 uses the config() callback function.
Note that the fact that the IFS is set twice for rt2500usb might suggest the
documentation for the register is incorrect and perhaps the purpose of the
register is completely different.
I guess it requires some experimentation to see if initializing those
2 registers differently has any effect. (And if it doesn't, then rt2500usb doesn't
require to know whether it is operating in B or G mode at all).
Ivo
On Tuesday 09 October 2007, Johannes Berg wrote:
> On Tue, 2007-10-09 at 19:32 +0200, Ivo van Doorn wrote:
>
> > Well that is my point, if the documentation is correct then rt2500usb
> > has 2 locations to initialize the IFS. So it would always be set and the question
> > would be what the impact would be to set the IFS per packet only.
> > But that is something I need to test with just some experiments.
>
> Well, it's not too strange that it has two places since there's the SIFS
> too which is needed for ACK/CTS timing, these packets aren't sent from
> the host so you can't have those timings in a per-packet descriptor.
You mean things like ACK_TIMEOUT, those are all seperate registers in the Ralink hardware.
ButI think I should be more clearer on this, rt2500pci and rt2500usb are
basically the same chipset but only the bus type is different.
What is notable is that _only_ rt2500usb has this IFS register, none of the
other Ralink chipsets (including rt2500pci) have it.
> > This means that the device would be able to operate correctly for
> > 802.11B even with the 802.11G timing initialization. Because according
> > to the way the legacy driver is setup, working in 802.11G while working
> > with the CCK rates would be possible.
> > This also means associating to 802.11B AP's while in 802.11G mode.
> > So we might be making a big deal out of something while the source
> > of the problem is very simple: The legacy driver code is just wrong. ;)
>
> Well, no, if you have a pure 802.11B AP then you have to use the 11B
> slot timing, if you have a G AP then it'll tell you which timing to use
> (I think)
True, but in G mode you are compatible with B. The legacy driver doesn't
switch back to B mode when the AP is in B mode. This means that it will
be using the G timing values.
Even if the G AP is telling which timing it is using, it is ignored by the
legacy driver since the timing value is hardcoded for both B as G mode.
Ivo
On Mon, 2007-10-08 at 10:32 -0400, Mike Kershaw wrote:
> I'd vote for allowing the user to set a mode - just like they're
> allowed to lock an AP association to a specific MAC, bypassing the
> hardware roaming algos.
>
> I've hit situations in the past where a card can get a very weak 11g
> link but a perfectly usable 11b link, and the hw did not want to drop
> back to 11b on its own. Being able to lock to 11b only was key.
Actually, what you're advocating sounds like "please let me restrict the
bitrates to use" rather than "please lock me to a mode". And we need
that functionality anyway for AP mode.
johannes
On Tue, 2007-10-09 at 16:27 +0200, Ivo van Doorn wrote:
> The IFS is also passed on as argument by mac80211 when it configures the
> TX rings. The EIFS register is something different, all other Ralink devices
> have only 1 value for the EIFS. I am not even sure how the device will react
> when the same value is set for rt2500usb.
Ok but IFS definitely needs to be set. EIFS I'm not entirely sure about,
haven't looked at the timing diagrams for a long time.
> Note that the fact that the IFS is set twice for rt2500usb might suggest the
> documentation for the register is incorrect and perhaps the purpose of the
> register is completely different.
Heh.
> I guess it requires some experimentation to see if initializing those
> 2 registers differently has any effect. (And if it doesn't, then rt2500usb doesn't
> require to know whether it is operating in B or G mode at all).
That won't be easy to tell, but the IFS is different afaik so there the
mode has an influence. But I think that this mode setting need not be
tied to the frequency table.
johannes
On Tue, 2007-10-09 at 19:32 +0200, Ivo van Doorn wrote:
> Well that is my point, if the documentation is correct then rt2500usb
> has 2 locations to initialize the IFS. So it would always be set and the question
> would be what the impact would be to set the IFS per packet only.
> But that is something I need to test with just some experiments.
Well, it's not too strange that it has two places since there's the SIFS
too which is needed for ACK/CTS timing, these packets aren't sent from
the host so you can't have those timings in a per-packet descriptor.
> This means that the device would be able to operate correctly for
> 802.11B even with the 802.11G timing initialization. Because according
> to the way the legacy driver is setup, working in 802.11G while working
> with the CCK rates would be possible.
> This also means associating to 802.11B AP's while in 802.11G mode.
> So we might be making a big deal out of something while the source
> of the problem is very simple: The legacy driver code is just wrong. ;)
Well, no, if you have a pure 802.11B AP then you have to use the 11B
slot timing, if you have a G AP then it'll tell you which timing to use
(I think)
johannes
On Mon, 2007-10-08 at 23:08 +0200, Ivo van Doorn wrote:
> The only difference currently in rt2x00 is for rt2500usb. The initialization
> of the IFS and EIFS register is different.
Ok so that's something we have to do in G-mode-compatible-with-B as
well.
> And is mac80211 doing that correctly at this time?
I'm not entirely sure. Are you setting the IFS/EIFS from any other
place? :) I don't think it is doing that correctly.
> Only registering the supported rates and channels and let mac80211 sort
> out the modes itself does sound like a good idea. :)
:)
johannes
On Tue, 2007-10-09 at 09:55 -0400, Mike Kershaw wrote:
> > Actually, what you're advocating sounds like "please let me restrict the
> > bitrates to use" rather than "please lock me to a mode". And we need
> > that functionality anyway for AP mode.
>
> Not quite, I've had situations where 9mbit at OFDM (11g) performed
> differently than 11mbit at CCK (11b) for whatever reason. I'm also
> fairly sure several cards (I want to say Intel 2200?) limit the max tx
> power differently depending on the encoding type (100mW for 11b vs.
> something less I don't remember off hand for 11g).
Aha, but I'm not saying that you should be able to set a strict bitrate
limit but rather enable/disable each bitrate by itself.
johannes
On Fri, 2007-10-05 at 23:19 +0100, Adam Baker wrote:
> I've observed an undesirable change in behaviour of rt2x00 as a result of
> Johannes Berg's patch 3d4803379613c763f5a7863e8249b63d190af5e6
> (remove all prism2 ioctls).
> It used to consistently default to 802.11g mode on g capable hardware. Because
> that patch removed the lines
>
> - /* Use next_mode as the mode preference to
> - * resolve non-unique channel numbers. */
> - if (set && mode->mode != local->next_mode)
> - continue;
>
> in ieee80211_set_channel it now defaults to 11b unless I change the code that
> calls ieee80211_register_hwmode. (I realise that the next_mode test is no
> longer "right").
>
> This is because ieee80211_set_channel will now prefer to select whichever was
> the last mode for which the driver called ieee80211_register_hwmode whereas
> the previous behaviour preferred the first registered mode. It seems as
> though if there was a way to avoid calling Iieee80211_set_channel then the
> setting of oper_hw_mode in ieee80211_register_hwmode would still prefer the
> first registered mode.
Yeah, you're right, it was too much to remove the whole conditional and
the continue, I should've just removed the && mode stuff. Will post a
patch to add it back.
> Is it intended that the order of calling ieee80211_register_hwmode should
> determine which mode should be preferred when multiple modes exist on the
> same channel or is there either already or planned a better option for driver
> writers? If calling order should determine preference should it be first or
> last registered?
That's actually a can of worms. Luis is working (I hope) on resolving
these issues with mode vs. frequency selection. However, I'm not
entirely convinced that mode selection should be done by userspace when
we are acting as a client. I think we should simply exploit hardware
capabilities as much as possible and then use the set that the AP
advertised (or rather as much as we can support of that).
Hence, for these questions it'd be good to know whether the ralink
drivers do anything different based on the selected mode, and if they do
(I assume they do because they register B *and* G modes) what it is.
It'd probably help a lot with the design of the interface if you could
answer that. I feel that mode selection should not be necessary since in
G mode a device needs to have the capability to talk to B-only stations
and hence must be able to "fall back" to B mode, we should therefore be
able to exploit that capability without the driver ever registering
different modes.
In fact, I think that the driver can probably simply register the
modulations/bitrates it can support orthogonally to the frequencies it
supports, and the frequencies consist of only information about the
frequency and possibly hardware value used to select it. This was part
of what I posted a while ago when Luis was posting his regulatory stuff,
and I think should be addressed while cleaning up that whole mess.
Thanks,
johannes