802.11 A is easily distinguishable based on frequency, and the difference
between 802.11B/G isn't really done well in mac80211 with most 802.11G
drivers supporting only 802.11G channels and no B channels
Signed-off-by: Johannes Berg <[email protected]>
---
What reason is there anyway for distinguishing between an 802.11G and an
802.11B channel? Regulatory? In that case, well, needs lots of work.
hostapd/driver_devicescape.c | 14 --------------
1 file changed, 14 deletions(-)
--- hostap.orig/hostapd/driver_devicescape.c 2007-08-14 11:32:35.000000000 +0200
+++ hostap/hostapd/driver_devicescape.c 2007-08-14 11:32:36.000000000 +0200
@@ -367,20 +367,6 @@ static int i802_set_freq(void *priv, int
struct i802_driver_data *drv = priv;
struct iwreq iwr;
- switch (mode) {
- case HOSTAPD_MODE_IEEE80211A:
- mode = MODE_IEEE80211A;
- break;
- case HOSTAPD_MODE_IEEE80211B:
- mode = MODE_IEEE80211B;
- break;
- case HOSTAPD_MODE_IEEE80211G:
- mode = MODE_IEEE80211G;
- break;
- }
-
- hostap_ioctl_prism2param(drv, PRISM2_PARAM_NEXT_MODE, mode);
-
memset(&iwr, 0, sizeof(iwr));
os_strlcpy(iwr.ifr_name, drv->hapd->conf->iface, IFNAMSIZ);
iwr.u.freq.m = freq;
--
On Wed, 2007-08-15 at 10:29 +0300, Tomas Winkler wrote:
> Just a small example as everybody knows the major distinction is in
> modulation schema i.e. CCK vs. OFDM. 11b only devices are deaf to OFDM
> traffic so we use CTS/RTS to overcome it which in turn slows the
> traffic. Sometime B-only or even G-only (no CCK rates) environments
> are required. I've used to have laptops with 11b only cards so I've
> configured the AP to B only not slowing even more the traffic.
That's more a matter of only announcing B channels though, not a reason
for telling the hardware that a B channel was selected.
Of course, it is not inconceivable that hardware may support turning off
OFDM completely, I just haven't seen any yet :)
johannes
On Wed, Aug 15, 2007 at 12:44:42PM +0200, Johannes Berg wrote:
> Agreed as well, the plan for nl80211 was to have the tuple set together.
> I quite dislike the idea of this internal "next_mode" state but I
> suppose it's the best we have now.
I don't linke next_mode either, so if this is combined to a single
atomic operation, it would be quite a bit better way to do this.
> However, this is the reason David Woodhouse couldn't get his Broadcom
> based card to work in B mode, hostapd tried to select a B mode channel
> and b43 doesn't offer any since it offers G mode. Should the burden be
> on the driver authors here, or should we somehow select a G channel if B
> isn't available?
I would assume that the quick workaround for this would have been to
change the configuration file to use 802.11g instead of the default
i802.11b.. Anyway, the design used here does indeed assume that the
driver exports all supported mode/channel pairs and in case the hardware
card supports 802.11g, the driver would most likely claim support for
both 802.11b and 802.11g channels.
Adding code for reverting back to 802.11g version would, in theory, be
fine for most cases, but it does have some issues.. If I remember
correctly, channel 14 may only be used with 802.11b mode in Japan, so
the list of 802.11b and 802.11g channels is not the same. In this
particular case, though, the workaround of using 802.11g list would not
cause a problem (the other direction would potentially have).
--
Jouni Malinen PGP id EFC895FA
On 8/15/07, Jouni Malinen <[email protected]> wrote:
> On Tue, Aug 14, 2007 at 11:32:58AM +0200, Johannes Berg wrote:
> > 802.11 A is easily distinguishable based on frequency, and the difference
> > between 802.11B/G isn't really done well in mac80211 with most 802.11G
> > drivers supporting only 802.11G channels and no B channels
>
> Agreed on 802.11a vs. b/g as long as frequency is used for configuration
> (as is the case here; channel numbers would not have been unique).
> Dropping the b vs. g is somewhat unfortunate, though.
>
> > What reason is there anyway for distinguishing between an 802.11G and an
> > 802.11B channel? Regulatory? In that case, well, needs lots of work.
>
> The original reason for adding that was that some hardware designs have
> separate modes for 802.11b and 802.11g and there may be cases where the
> 802.11b mode would be preferred. I'm not sure about all the differences
> in hardware, but I would assume this could include power use (save power
> by being able to use slower internal frequency since there is less
> things to do and by disabling some functionality) and maybe in some
> cases just the fact of disabling all non-802.11b extensions.
>
> Furthermore, frequency may not be unique in future with additional PHY
> changes. Having option of setting both a "mode" and frequency is a pair
> is a good way of making sure the design is more future proof in this
> area.
>
Just a small example as everybody knows the major distinction is in
modulation schema i.e. CCK vs. OFDM. 11b only devices are deaf to OFDM
traffic so we use CTS/RTS to overcome it which in turn slows the
traffic. Sometime B-only or even G-only (no CCK rates) environments
are required. I've used to have laptops with 11b only cards so I've
configured the AP to B only not slowing even more the traffic.
> --
> Jouni Malinen PGP id EFC895FA
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Tue, 2007-08-14 at 19:41 -0700, Jouni Malinen wrote:
> Agreed on 802.11a vs. b/g as long as frequency is used for configuration
> (as is the case here; channel numbers would not have been unique).
> Dropping the b vs. g is somewhat unfortunate, though.
Agreed. I can live with leaving it in.
> Furthermore, frequency may not be unique in future with additional PHY
> changes. Having option of setting both a "mode" and frequency is a pair
> is a good way of making sure the design is more future proof in this
> area.
Agreed as well, the plan for nl80211 was to have the tuple set together.
I quite dislike the idea of this internal "next_mode" state but I
suppose it's the best we have now.
However, this is the reason David Woodhouse couldn't get his Broadcom
based card to work in B mode, hostapd tried to select a B mode channel
and b43 doesn't offer any since it offers G mode. Should the burden be
on the driver authors here, or should we somehow select a G channel if B
isn't available?
johannes
On Tue, Aug 14, 2007 at 11:32:58AM +0200, Johannes Berg wrote:
> 802.11 A is easily distinguishable based on frequency, and the difference
> between 802.11B/G isn't really done well in mac80211 with most 802.11G
> drivers supporting only 802.11G channels and no B channels
Agreed on 802.11a vs. b/g as long as frequency is used for configuration
(as is the case here; channel numbers would not have been unique).
Dropping the b vs. g is somewhat unfortunate, though.
> What reason is there anyway for distinguishing between an 802.11G and an
> 802.11B channel? Regulatory? In that case, well, needs lots of work.
The original reason for adding that was that some hardware designs have
separate modes for 802.11b and 802.11g and there may be cases where the
802.11b mode would be preferred. I'm not sure about all the differences
in hardware, but I would assume this could include power use (save power
by being able to use slower internal frequency since there is less
things to do and by disabling some functionality) and maybe in some
cases just the fact of disabling all non-802.11b extensions.
Furthermore, frequency may not be unique in future with additional PHY
changes. Having option of setting both a "mode" and frequency is a pair
is a good way of making sure the design is more future proof in this
area.
--
Jouni Malinen PGP id EFC895FA
On Wed, 2007-08-15 at 18:38 -0700, Jouni Malinen wrote:
> I don't linke next_mode either, so if this is combined to a single
> atomic operation, it would be quite a bit better way to do this.
Yeah, we'll have that if somebody gets around to it.
> I would assume that the quick workaround for this would have been to
> change the configuration file to use 802.11g instead of the default
> i802.11b..
Oh, it was :) But it wasn't obvious.
> Anyway, the design used here does indeed assume that the
> driver exports all supported mode/channel pairs and in case the hardware
> card supports 802.11g, the driver would most likely claim support for
> both 802.11b and 802.11g channels.
>
> Adding code for reverting back to 802.11g version would, in theory, be
> fine for most cases, but it does have some issues.. If I remember
> correctly, channel 14 may only be used with 802.11b mode in Japan, so
> the list of 802.11b and 802.11g channels is not the same. In this
> particular case, though, the workaround of using 802.11g list would not
> cause a problem (the other direction would potentially have).
Hmm. That seems like something to be integrated with the regulatory code
rather than the driver.
johannes