- 24 Jun, 2014 40 commits
-
-
Jes Sorensen authored
Signed-off-by:
Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jes Sorensen authored
Don't run rtw_validate_vendor_specific_ies() on anything but WLAN_EID_VENDOR_SPECIFIC. In addition use the proper WLAN_OUI_TYPE_MICROSOFT_* definitions. Signed-off-by:
-
Jes Sorensen authored
Another case using hard coded offsets counting on the presence of fixed beacon elements in the IEs array. Signed-off-by:
-
Jes Sorensen authored
Rewrite rtw_restruct_wmm_ie23a() using cfg80211_find_vendor_ie() Signed-off-by:
-
Jes Sorensen authored
This also eliminates another round of determine algorithm based on key length, followed by determine key length based on algorithm. Signed-off-by:
-
Jes Sorensen authored
We validate the parameters in cfg80211_rtw_add_key() so no need to do it all again in rtw_cfg80211_{ap_}set_encryption() Signed-off-by: -
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
struct ieee_parms is obsolete, so stop passing it on. Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Use key_params->cipher to determine WEP/TKIP Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
We already know which type of WEP we are using when we get here, no point trying to determine it from key_len. Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
No point checking it again in here, twice! Signed-off-by:
-
Jes Sorensen authored
staging: rtl8723au: rtw_cfg80211_ap_set_encryption(): Use key_params->cipher to determine encryption Passing strings around for something we have defines for is just silly. Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
This gets rid of the odd carrying of half the beacon frame in the IE array stored for the network. Instead we rely on the relevant fields (timestamp, beacon_interval, and capability) stored in struct wlan_bssid_ex. Carrying only half the ieee80211_mgmt header led to a number of bugs and simply obfuscated the code. I have tried catching all instances relying on these three elements in the IEs array, but missed cases may still need to be tracked down. Signed-off-by:
-
Jes Sorensen authored
We need to make sure to update the network info as well as the IE array. Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
Jes Sorensen authored
Use ieee80211_mgmt to construct the frame instead of relying on hard coded offsets. Signed-off-by:
-
Jes Sorensen authored
This should help catching all the users once we stop carrying the fixed beacon elements in the IE array. Signed-off-by:
-
Jes Sorensen authored
Beacon capability was already added to mlme_priv->cur_network before calling this function, so no need to retrieve it from the IE array again. Signed-off-by:
-
Jes Sorensen authored
Clean up and correct the beacon frame validation using a full beacon frame, and pass that to rtw_check_beacon_data23a(). Previous we went through hoops to construct the frame, minus the ieee80211_3addr header which just made it more complicated, and resulted in inconsistencies and bugs. Signed-off-by:
-
Jes Sorensen authored
Signed-off-by:
-
