diff options
author | Jouni Malinen <jouni.malinen@atheros.com> | 2008-08-19 10:54:32 +0300 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2008-08-26 20:06:32 -0400 |
commit | 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c (patch) | |
tree | 4fec52d3c6628184bb5d6ac417fa5409f04d22e6 /drivers | |
parent | 988b02f1bf5b608ef91a9d98c7170d037d0f12e3 (diff) | |
download | linux-087d833e5a9f67ba933cb32eaf5a2279c1a5b47c.tar.gz linux-087d833e5a9f67ba933cb32eaf5a2279c1a5b47c.tar.bz2 linux-087d833e5a9f67ba933cb32eaf5a2279c1a5b47c.zip |
mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
The previous code was using IWEVCUSTOM to report IEs from AssocReq and
AssocResp frames into user space. This can easily hit the 256 byte
limit (IW_CUSTOM_MAX) with APs that include number of vendor IEs in
AssocResp. This results in the event message not being sent and dmesg
showing "wlan0 (WE) : Wireless Event too big (366)" type of errors.
Convert mac80211 to use IWEVASSOCREQIE/IWEVASSOCRESPIE to avoid the
issue of being unable to send association IEs as wireless events. These
newer event types use binary encoding and larger maximum size
(IW_GENERIC_IE_MAX = 1024), so the likelyhood of not being able to send
the IEs is much smaller than with IWEVCUSTOM. As an extra benefit, the
code is also quite a bit simpler since there is no need to allocate an
extra buffer for hex encoding.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions