From: John W. Linville <[email protected]>
The association response IEs are sent to userland with an IWEVCUSTOM
event, which unfortunately is limited to a little more than 100 bytes
of IE information with the encoding used. Many APs send so much
IE information that this message overflows. When the IWEVCUSTOM
event is too large, the kernel doesn't send it to userland anyway --
better just not to send it.
An attempt was made by Jouni Malinen to correct this issue by
converting to use IWEVASSOCREQIE and IWEVASSOCRESPIE messages instead
("mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM"). Unfortunately,
that caused a problem due to 32-/64-bit interactions on some systems and
was reverted after the 'userland ABI' rule was invoked. That leaves
us with this option instead of a proper fix, at least until we move
to a cfg80211-based solution.
Signed-off-by: John W. Linville <[email protected]>
---
net/mac80211/mlme.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 902cac1..7a8f0a8 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -518,9 +518,11 @@ static void ieee80211_sta_send_associnfo(struct net_device *dev,
}
}
- memset(&wrqu, 0, sizeof(wrqu));
- wrqu.data.length = len;
- wireless_send_event(dev, IWEVCUSTOM, &wrqu, buf);
+ if (len <= IW_CUSTOM_MAX) {
+ memset(&wrqu, 0, sizeof(wrqu));
+ wrqu.data.length = len;
+ wireless_send_event(dev, IWEVCUSTOM, &wrqu, buf);
+ }
kfree(buf);
}
--
1.5.5.1
On Thu, Oct 02, 2008 at 10:24:47PM +0100, Dave wrote:
> John W. Linville wrote:
>> An attempt was made by Jouni Malinen to correct this issue by
>> converting to use IWEVASSOCREQIE and IWEVASSOCRESPIE messages instead
>> ("mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM"). Unfortunately,
>> that caused a problem due to 32-/64-bit interactions on some systems and
>> was reverted after the 'userland ABI' rule was invoked.
>
> I was unaware of this, and used IWEVASSOCREQIE and IWEVASSOCRESPIE in the
> orinoco wpa updates since the events were available in linux/wireless.h.
>
> Should I post a patch to use IWEVCUSTOM instead?
Honestly, I don't know. I think we would prefer not to use the
IWEVCUSTOM method, but my memory is not 100% clear on what triggered
the 32-/64-bit problem. Perhaps Jouni can comment?
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Mon, Oct 06, 2008 at 01:53:57PM -0400, John W. Linville wrote:
> Honestly, I don't know. I think we would prefer not to use the
> IWEVCUSTOM method, but my memory is not 100% clear on what triggered
> the 32-/64-bit problem. Perhaps Jouni can comment?
IWEVCUSTOM is the wrong way of doing this. However, the problem here is
that IWEVASSOCREQIE and IWEVASSOCRESPIE can trigger wpa_supplicant to
behave incorrectly in 64-bit kernel, 32-bit userspace case (64/64 and
32/32 work fine). This is worked around in the current 0.6.x devel
branch, but not in any of the released versions.
--
Jouni Malinen PGP id EFC895FA
John W. Linville wrote:
> An attempt was made by Jouni Malinen to correct this issue by
> converting to use IWEVASSOCREQIE and IWEVASSOCRESPIE messages instead
> ("mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM"). Unfortunately,
> that caused a problem due to 32-/64-bit interactions on some systems and
> was reverted after the 'userland ABI' rule was invoked.
I was unaware of this, and used IWEVASSOCREQIE and IWEVASSOCRESPIE in the
orinoco wpa updates since the events were available in linux/wireless.h.
Should I post a patch to use IWEVCUSTOM instead?
Thanks,
Dave.