> In most cases, the pairwise cipher is selected during association, not > during 4-way handshake. Consequently, the driver/firmware should refuse > to send an (Re)Association Request that requests TKIP as the pairwise > cipher when using .11n. So to do this we should look at the associate IE(s) we get from userspace for association, right? > The exact mechanism depends on whether ap_scan=1 or ap_scan=2 is being > used, i.e., whether wpa_supplicant is responsible for selecting a BSS > from scan results or not. > > In ap_scan=1, I would say that it would be useful for wpa_supplicant to > know whether the BSS (and the local wlan driver/hardware for that > matter!) supports .11n. If the scan results indicate this in some > reliable way (e.g., all IEs are delivered to wpa_supplicant), the AP's > support for 11n can be figured out. The local side support would need to > be added, e.g., to driver capabilities reporting. > > In ap_scaqn=2, wpa_supplicant requests the driver to select a BSS based > on configuration (SSID, security policy, including a specific cipher > suite), i.e., the driver would be told about TKIP use before > association and the driver would be responsible for not trying to use > 11n in that case. The corner case of AP/Authenticator requesting another > pairwise cipher would still be possible here, but not really something > that I would consider a real problem that needs to be solved. I'd think we can also just include the HT IE in the scan result. Or, why not just include all of them, parsers must be able to tell them apart anyway and NM could display an HT icon for example then. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
