[PATCH 1/1] mac80211: sends HT IE to user level through wext

[PATCH 1/1] mac80211: sends HT IE to user level through wext

[Tomas Winkler]

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This patch adds HT IE in the scan list that is returned to user level
through wext. This is useful to let wpa_supplicant if a bss supports 11n or
not: WEP and TKIP are not supported in 11n.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 net/mac80211/mlme.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index fd42ffd..dec67ff 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -4131,6 +4131,14 @@ ieee80211_sta_scan_result(struct net_device *dev,
 						  bss->rsn_ie);
 	}
 
+	if (bss && bss->ht_ie) {
+		memset(&iwe, 0, sizeof(iwe));
+		iwe.cmd = IWEVGENIE;
+		iwe.u.data.length = bss->ht_ie_len;
+		current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe,
+						  bss->ht_ie);
+	}
+
 	if (bss && bss->supp_rates_len > 0) {
 		/* display all supported rates in readable format */
 		char *p = current_ev + IW_EV_LCP_LEN;
-- 
1.5.4.1

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 1/1] mac80211: sends HT IE to user level through wext

[Johannes Berg]

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


> +	if (bss && bss->ht_ie) {
> +		memset(&iwe, 0, sizeof(iwe));
> +		iwe.cmd = IWEVGENIE;
> +		iwe.u.data.length = bss->ht_ie_len;
> +		current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe,
> +						  bss->ht_ie);

I'm fine with this, but I'm wondering if maybe we should just pass out
the whole IE area of the beacon/probe response?

johannes

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

Re: [PATCH 1/1] mac80211: sends HT IE to user level through wext

[Jouni Malinen]

On Tue, May 27, 2008 at 07:04:52PM +0200, Johannes Berg wrote:

> I'm fine with this, but I'm wondering if maybe we should just pass out
> the whole IE area of the beacon/probe response?

I would prefer to get all IEs in one blob (assuming WEXT does not have
length limits on this data that could be up to about 2250 bytes long).
This would avoid need to add new IEs one by one in the future (e.g., for
IEEE 802.11r).

wpa_supplicant should be able to combine multiple IEs (or even multiple
IE groups) together, so I'm not too concerned of this being done
separately, but in general, it would be simpler to just pass all IEs as
a single blob. It might even be worthwhile to start storing the IEs as a
single buffer and have helper functions to fetch pointer to the
beginning of whatever IE is needed in the MLME code (this is how the
current wpa_supplicant processes IEs from scan results).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH 1/1] mac80211: sends HT IE to user level through wext

[Johannes Berg]

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


> I would prefer to get all IEs in one blob (assuming WEXT does not have
> length limits on this data that could be up to about 2250 bytes long).

Good point. That should actually be doable quite easily.

> This would avoid need to add new IEs one by one in the future (e.g., for
> IEEE 802.11r).

Yeah, precisely.

> wpa_supplicant should be able to combine multiple IEs (or even multiple
> IE groups) together, so I'm not too concerned of this being done
> separately, but in general, it would be simpler to just pass all IEs as
> a single blob. It might even be worthwhile to start storing the IEs as a
> single buffer and have helper functions to fetch pointer to the
> beginning of whatever IE is needed in the MLME code (this is how the
> current wpa_supplicant processes IEs from scan results).

Actually, we do store them in one blob and then hand out pointers to the
various parts.

johannes

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

Re: [PATCH 1/1] mac80211: sends HT IE to user level through wext

[Tomas Winkler]

On Tue, May 27, 2008 at 8:24 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>> I would prefer to get all IEs in one blob (assuming WEXT does not have
>> length limits on this data that could be up to about 2250 bytes long).
>
> Good point. That should actually be doable quite easily.
>
>> This would avoid need to add new IEs one by one in the future (e.g., for
>> IEEE 802.11r).
>
> Yeah, precisely.
>
>> wpa_supplicant should be able to combine multiple IEs (or even multiple
>> IE groups) together, so I'm not too concerned of this being done
>> separately, but in general, it would be simpler to just pass all IEs as
>> a single blob. It might even be worthwhile to start storing the IEs as a
>> single buffer and have helper functions to fetch pointer to the
>> beginning of whatever IE is needed in the MLME code (this is how the
>> current wpa_supplicant processes IEs from scan results).
>
> Actually, we do store them in one blob and then hand out pointers to the
> various parts.
>
> johannes
>

Would this work with current and older version of  wpa_supplicant?.
I'm concern with backward compatibility,

Thanks
Tomas

Re: [PATCH 1/1] mac80211: sends HT IE to user level through wext

[Johannes Berg]

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


> >> I would prefer to get all IEs in one blob (assuming WEXT does not have
> >> length limits on this data that could be up to about 2250 bytes long).

> Would this work with current and older version of  wpa_supplicant?.
> I'm concern with backward compatibility,

Yes, even iwlist handles that fine. In fact, wpa_supplicant simply
concatenates all of them internally, and iwlist just prints each IE it
finds in each GENIE item.

johannes

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

Re: [PATCH 1/1] mac80211: sends HT IE to user level through wext

[Tomas Winkler]

On Wed, May 28, 2008 at 4:14 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>> >> I would prefer to get all IEs in one blob (assuming WEXT does not have
>> >> length limits on this data that could be up to about 2250 bytes long).
>
>> Would this work with current and older version of  wpa_supplicant?.
>> I'm concern with backward compatibility,
>
> Yes, even iwlist handles that fine. In fact, wpa_supplicant simply
> concatenates all of them internally, and iwlist just prints each IE it
> finds in each GENIE item.

One more obstacle

> Actually, we do store them in one blob and then hand out pointers to the
> various parts.

we don't store them as one block we allocate each one separately
(ieee80211_sta_bss) so there will be some bigger rewrite of the code
than this patch, which I'm a bit reluctant to do...time...bugs etc
so what more arguments we have to convince me :)

Thanks
Tomas


>
> johannes
>

Re: [PATCH 1/1] mac80211: sends HT IE to user level through wext

[Johannes Berg]

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


> > Actually, we do store them in one blob and then hand out pointers to the
> > various parts.
> 
> we don't store them as one block we allocate each one separately
> (ieee80211_sta_bss) so there will be some bigger rewrite of the code
> than this patch, which I'm a bit reluctant to do...time...bugs etc
> so what more arguments we have to convince me :)

Oh, you're right, I thought we just stored the frame. That might be good
though because right now we kmalloc a whole bunch of things.

Anyway, we can also clean it up later.

johannes

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