Discussion:
Setting HT capabilities in net80211
(too old to reply)
Alexander Egorenkov
2010-03-05 07:48:04 UTC
Permalink
Currently there is no possibility to set some HT capabilities in e.g. an
association request frame.
The function ieee80211_add_htcap_body in ieee80211_ht.c simply sets some HT
capabilities to zero.
For example, there is no way to set HT extended capabilities which i need
for my 802.11n device driver.
I could of course patch the function on my system and recompile the kernel
but it would be really nice
to have official support of extended HT capabilities (and all other HT caps)
in net80211. The header file
ieee80211.h defines the necessary HT capability constants but they are not
used in net80211 to
set extended HT capabilities in association request frames.
Sam Leffler
2010-03-07 00:16:23 UTC
Permalink
Post by Alexander Egorenkov
Currently there is no possibility to set some HT capabilities in e.g. an
association request frame.
The function ieee80211_add_htcap_body in ieee80211_ht.c simply sets some HT
capabilities to zero.
For example, there is no way to set HT extended capabilities which i need
for my 802.11n device driver.
I could of course patch the function on my system and recompile the kernel
but it would be really nice
to have official support of extended HT capabilities (and all other HT caps)
in net80211. The header file
ieee80211.h defines the necessary HT capability constants but they are not
used in net80211 to
set extended HT capabilities in association request frames.
Can you be more specific? The current code dynamically sets those
capabilities that can be changed and the others are fixed according to
the capabilities of the hw/driver. Of course patches are always
welcome; what's there reflects what was needed for the projects I worked on.

Sam
Alexander Egorenkov
2010-03-07 08:04:02 UTC
Permalink
OK, here is an example.

There is no way to set MCS feedback capability in the filed hc_extcap of the
struct ieee80211_ie_htcap
because the function ieee80211_add_htcap_body always sets it to 0. And my
Ralink device supports MCS feedback
according to Linux device driver code. The same problem is with HTC+ and RDR
capabilities.
Post by Sam Leffler
Post by Alexander Egorenkov
Currently there is no possibility to set some HT capabilities in e.g. an
association request frame.
The function ieee80211_add_htcap_body in ieee80211_ht.c simply sets some HT
capabilities to zero.
For example, there is no way to set HT extended capabilities which i need
for my 802.11n device driver.
I could of course patch the function on my system and recompile the kernel
but it would be really nice
to have official support of extended HT capabilities (and all other HT caps)
in net80211. The header file
ieee80211.h defines the necessary HT capability constants but they are not
used in net80211 to
set extended HT capabilities in association request frames.
Can you be more specific? The current code dynamically sets those
capabilities that can be changed and the others are fixed according to the
capabilities of the hw/driver. Of course patches are always welcome; what's
there reflects what was needed for the projects I worked on.
Sam
Alexander Egorenkov
2010-03-11 07:32:32 UTC
Permalink
There are already constants defined in iee80211.h.
E.g. IEEE80211_HTCAP_MCSFBACK_UNSOL.

But the problem is that e.g. IEEE80211_HTCAP_MCSFBACK_UNSOL is equal to
0x0200
and the capabilty constant IEEE80211_HTCAP_RXSTBC_2STREAM has the same
value.
So we cannot use ic_htcap field for both capabilities because they will
overwrite each other.

But we can add a new field to ieee80211com struct like ic_htextcaps where
all the extended
HT capabilities can be set. And this new field can be checked in function
ieee80211_add_htcap_body.

Another option is to change the value of IEEE80211_HTCAP_MCSFBACK_UNSOL and
all other extended capability constant which conflict with normal HT
capability constants.

Or do you have any other ideas ?
Post by Alexander Egorenkov
OK, here is an example.
Post by Alexander Egorenkov
There is no way to set MCS feedback capability in the filed hc_extcap of the
struct ieee80211_ie_htcap
because the function ieee80211_add_htcap_body always sets it to 0. And my
Ralink device supports MCS feedback
according to Linux device driver code. The same problem is with HTC+ and RDR
capabilities.
Just add another driver HT bit flag and patch the function to honor that
flag. Then send us the patch. :-)
--
Rui Paulo
Rui Paulo
2010-03-11 07:44:22 UTC
Permalink
Post by Alexander Egorenkov
There are already constants defined in iee80211.h.
E.g. IEEE80211_HTCAP_MCSFBACK_UNSOL.
But the problem is that e.g. IEEE80211_HTCAP_MCSFBACK_UNSOL is equal
to 0x0200
and the capabilty constant IEEE80211_HTCAP_RXSTBC_2STREAM has the
same value.
So we cannot use ic_htcap field for both capabilities because they
will overwrite each other.
But we can add a new field to ieee80211com struct like ic_htextcaps
where all the extended
HT capabilities can be set. And this new field can be checked in
function ieee80211_add_htcap_body.
I'm okay with this route.
Post by Alexander Egorenkov
Another option is to change the value of
IEEE80211_HTCAP_MCSFBACK_UNSOL and all other extended capability
constant which conflict with normal HT capability constants.
I think you don't want to do this because sooner or later you'll need
ic_htextcaps.

--
Rui Paulo
Rui Paulo
2010-03-23 12:03:30 UTC
Permalink
I have finally patched net80211 on my system and added HT extended capabilities support.
Here are the patches.
I added a new variable to ieee80211com struct.
It seems that only the lowest 16 bit of ic_htcaps are used, an alternative to a new variable would be to use the highest 16 bit of ic_htcaps.
ic->ic_htextcaps = IEEE80211_HTCAP_MCSFBACK_UNSOL |
IEEE80211_HTCAP_HTC |
IEEE80211_HTCAP_RDR;
I also captured an association process with 802.11n AP and it seems the capabilities were set right.
Thanks, I've committed this.

--
Rui Paulo
Alexander Egorenkov
2010-03-23 13:23:47 UTC
Permalink
We also need to set/update/delete these capabilities for nodes, e.g. after a
beacon or
a (re)association frame is received from a node. I mean the field ni_flags
in struct ieee80211_node. And ifconfig support would be nice to have in
order to be able to enable/disable these features dynamically.
I have finally patched net80211 on my system and added HT extended
capabilities support.
Here are the patches.
I added a new variable to ieee80211com struct.
It seems that only the lowest 16 bit of ic_htcaps are used, an
alternative to a new variable would be to use the highest 16 bit of
ic_htcaps.
ic->ic_htextcaps = IEEE80211_HTCAP_MCSFBACK_UNSOL |
IEEE80211_HTCAP_HTC |
IEEE80211_HTCAP_RDR;
I also captured an association process with 802.11n AP and it seems the
capabilities were set right.
Thanks, I've committed this.
--
Rui Paulo
Rui Paulo
2010-03-23 13:25:29 UTC
Permalink
We also need to set/update/delete these capabilities for nodes, e.g. after a beacon or
a (re)association frame is received from a node. I mean the field ni_flags in struct ieee80211_node. And ifconfig support would be nice to have in order to be able to enable/disable these features dynamically.
I'm happy to review and commit patches.

--
Rui Paulo

Loading...