2.6.24, mac80211 and b/g switching

2.6.24, mac80211 and b/g switching

[Vladimir Koutny]

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

Hi,

I'm writing a driver using mac80211 under 2.6.24.x kernels (some custom
hw, and very small chance of using anything newer than 2.6.24.x), and it
seems that switching between 11b and 11g in mac80211 doesn't work at all.

I'm registering 2 hwmodes - MODE_IEEE80211B and MODE_IEEE80211G; only
STA mode (no ap, no ad-hoc (yet)).

Depending on the order of hwmodes registration, mac80211 sticks to
either b or g mode, with several implications:
 - unable to set all g-rates when connected to g-AP in MODE_IEEE80211B
 - able to set g-rates when connected to b-AP in MODE_IEEE80211G
 - wrong cw_min set via conf_tx (the code which sets this looks fine,
   just the phymode is not set correctly)

It doesn't matter if I set the phymode to b or g for received frames,
the behaviour is always the same.

I did some tests with iwl3945 (and rt2500usb, but that wasn't able to
associate), under 2.6.24.3 and 2.6.25-rc4; the same behaviour as for my
driver. Non-mac80211 drivers (like ipw3945 on somewhat older kernel)
behave as one would expect.

I didn't do a test with latest dev tree; based on list traffic quite a
lot is happening here, so maybe this is fixed already. However, chance
of being able to move to anything more recent than 2.6.25-rc is very
close to zero :(

Is this a known issue? (I didn't manage to find anything in ml archives
so far) Or any hints on how to solve this?

Thanks,
  Vlado


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

Re: 2.6.24, mac80211 and b/g switching

[Johannes Berg]

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


> Is this a known issue? (I didn't manage to find anything in ml archives
> so far) Or any hints on how to solve this?

You want to develop against a non-ancient kernel that has all the HW
mode foo removed.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: 2.6.24, mac80211 and b/g switching

[Vladimir Koutny]

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

Johannes Berg wrote:
>> Is this a known issue? (I didn't manage to find anything in ml archives
>> so far) Or any hints on how to solve this?
> 
> You want to develop against a non-ancient kernel that has all the HW
> mode foo removed.

Well, the question is not what version I would like to develop for, but
what version I have to :( Stable kernel releases should be those
versions you want to base real products on, right?

Do you think that taking mac80211 from wireless-2.6 (or -testing or
whatever) would cause way too many conflicts when merged back to 2.6.24?
  Or am I on my own to fix this somehow in 2.6.24?

Regards,
  Vlado

> 
> johannes



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

Re: 2.6.24, mac80211 and b/g switching

[Michael Buesch]

On Friday 07 March 2008 18:43:59 Vladimir Koutny wrote:
> Johannes Berg wrote:
> >> Is this a known issue? (I didn't manage to find anything in ml archives
> >> so far) Or any hints on how to solve this?
> > 
> > You want to develop against a non-ancient kernel that has all the HW
> > mode foo removed.
> 
> Well, the question is not what version I would like to develop for, but
> what version I have to :( Stable kernel releases should be those
> versions you want to base real products on, right?
> 
> Do you think that taking mac80211 from wireless-2.6 (or -testing or
> whatever) would cause way too many conflicts when merged back to 2.6.24?
>   Or am I on my own to fix this somehow in 2.6.24?

OpenWRT ported a rather recent mac80211 back to 2.6.23. So it shouldn't be too hard.

-- 
Greetings Michael.

Re: 2.6.24, mac80211 and b/g switching

[John W. Linville]

On Fri, Mar 07, 2008 at 07:16:28PM +0100, Michael Buesch wrote:
> On Friday 07 March 2008 18:43:59 Vladimir Koutny wrote:

> > Do you think that taking mac80211 from wireless-2.6 (or -testing or
> > whatever) would cause way too many conflicts when merged back to 2.6.24?
> >   Or am I on my own to fix this somehow in 2.6.24?
> 
> OpenWRT ported a rather recent mac80211 back to 2.6.23. So it shouldn't be too hard.

Current 2.6.24-based Fedora kernels take current mac80211 bits fairly easily.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: 2.6.24, mac80211 and b/g switching

[Luis R. Rodriguez]

On Fri, Mar 7, 2008 at 1:16 PM, Michael Buesch <mb@bu3sch.de> wrote:
>
> On Friday 07 March 2008 18:43:59 Vladimir Koutny wrote:
>  > Johannes Berg wrote:
>  > >> Is this a known issue? (I didn't manage to find anything in ml archives
>  > >> so far) Or any hints on how to solve this?
>  > >
>  > > You want to develop against a non-ancient kernel that has all the HW
>  > > mode foo removed.
>  >
>  > Well, the question is not what version I would like to develop for, but
>  > what version I have to :( Stable kernel releases should be those
>  > versions you want to base real products on, right?
>  >
>  > Do you think that taking mac80211 from wireless-2.6 (or -testing or
>  > whatever) would cause way too many conflicts when merged back to 2.6.24?
>  >   Or am I on my own to fix this somehow in 2.6.24?
>
>  OpenWRT ported a rather recent mac80211 back to 2.6.23. So it shouldn't be too hard.

If you want to work with the latest wireless subsystem on older
kernels you can also use compat-wireless-2.6 package. It supports
kernels >= 2.6.21. Only thing left to do on 2.6.21 is to test PCI and
add any needed backports there.

http://linuxwireless.org/en/users/Download

  Luis

Re: 2.6.24, mac80211 and b/g switching

[Vladimir Koutny]

John W. Linville wrote:
>>> Do you think that taking mac80211 from wireless-2.6 (or -testing or
>>> whatever) would cause way too many conflicts when merged back to 2.6.24?
>>>   Or am I on my own to fix this somehow in 2.6.24?
>> OpenWRT ported a rather recent mac80211 back to 2.6.23. So it shouldn't be too hard.
> 
> Current 2.6.24-based Fedora kernels take current mac80211 bits fairly easily.

Ok, thanks for this info, I might change my plans then. I'll try this
way first, or (if that fails) the compat-wireless-2.6 path suggested by
Luis.

Thanks,
 Vlado

> 
> John

Re: 2.6.24, mac80211 and b/g switching

[Vladimir Koutny]

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

Hi,

> Ok, thanks for this info, I might change my plans then. I'll try this
> way first, or (if that fails) the compat-wireless-2.6 path suggested by
> Luis.

So I've opted for compat-wireless-2.6 way, and as my first concern was
to see if cw_min is being set correctly I've immediately come across an
issue here:

conf_tx (called from ieee80211_sta_set_ssid) is being called before
IEEE80211_SDATA_OPERATING_GMODE flag is set/cleared (which is done in
ieee80211_rx_mgmt_assoc_resp). That means conf_tx will use cw_min
parameters from previous association, so when you switch between B and G
APs, you will end up with wrong cw_min.

Shouldn't conf_tx better be called only/also after association finishes?
 Or should the IEEE80211_SDATA_OPERATING_GMODE flag be set prior to
auth/assoc based on previous beacon/probe response info?

Regards,
 Vlado


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

Re: 2.6.24, mac80211 and b/g switching

[Johannes Berg]

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

Hi Vladimir,

> So I've opted for compat-wireless-2.6 way, and as my first concern was
> to see if cw_min is being set correctly I've immediately come across an
> issue here:
> 
> conf_tx (called from ieee80211_sta_set_ssid) is being called before
> IEEE80211_SDATA_OPERATING_GMODE flag is set/cleared (which is done in
> ieee80211_rx_mgmt_assoc_resp). That means conf_tx will use cw_min
> parameters from previous association, so when you switch between B and G
> APs, you will end up with wrong cw_min.
> 
> Shouldn't conf_tx better be called only/also after association finishes?
>  Or should the IEEE80211_SDATA_OPERATING_GMODE flag be set prior to
> auth/assoc based on previous beacon/probe response info?

Good question. I think it should probably be set once we have decided
which network we will associate with as, in theory, we could send out
management frames with RTS/CTS protection too.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]