I started working on WPA extension for the Linux wireless extensions based on our earlier discussion. This patch file for V16 shows my current work version. It is not yet ready to be merged into any
Thanks a lot for that, Jouni ! Actually, I don't like the extension of SIOC*IWENCODE. This ioctl is already messy/complex enough as it is, and I think we would benefit greatly in separating the two c
-- -- I wonder how this definition let you differentiate between the unicast cipher and the group cipher? Moreover there is two information that are needed 1) the authentication model, which is PSK
Yes : PAIRWISE vs. GROUP. Those things are in Jouni's original proposal, and I don't intend to drop them. I quoted only a small snipset, to clarify, please refer to his e-mail to get the full picture
OK. Yes, there are other parameters that may be useful at some point. Actually, IEEE 802.11 specifies this list as parameters to MLME-SCAN.request and I changed struct iw_scan_req to include all the
Hi Jouni Thinking about access point we need a way to set more than one cipher suite for the pairwise cipher list (for example mixed mode, which have both TKIP and CCMP users. Another aspect is an AP
These both can use the generic IE mechanism (SIOCSIWGENIE) to configure whatever mode is needed. I'm more used to doing the policy decision in user space (e.g., validating WPA/RSN IE in AssocReq), so
This depend where the AP implementation is as well as the management is handled -- who will send the association failure or success, will you divide the verification of the association between user
You missed the other part of the API : +/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095) + * (IW_AUTH_INDEX mask in struct iw_param flags; this is the index of the + * parameter that is being set/ge
I started working on WPA extension for the Linux wireless extensions based on our earlier discussion. This patch file for V16 shows my current work version. It is not yet ready to be merged into any
Thanks a lot for that, Jouni ! Actually, I don't like the extension of SIOC*IWENCODE. This ioctl is already messy/complex enough as it is, and I think we would benefit greatly in separating the two c
-- -- -- I wonder how this definition let you differentiate between the unicast cipher and the group cipher? Moreover there is two information that are needed 1) the authentication model, which is P
Yes : PAIRWISE vs. GROUP. Those things are in Jouni's original proposal, and I don't intend to drop them. I quoted only a small snipset, to clarify, please refer to his e-mail to get the full picture
OK. Yes, there are other parameters that may be useful at some point. Actually, IEEE 802.11 specifies this list as parameters to MLME-SCAN.request and I changed struct iw_scan_req to include all the
Hi Jouni Thinking about access point we need a way to set more than one cipher suite for the pairwise cipher list (for example mixed mode, which have both TKIP and CCMP users. Another aspect is an AP
These both can use the generic IE mechanism (SIOCSIWGENIE) to configure whatever mode is needed. I'm more used to doing the policy decision in user space (e.g., validating WPA/RSN IE in AssocReq), so
configure This depend where the AP implementation is as well as the management is handled -- who will send the association failure or success, will you divide the verification of the association bet
You missed the other part of the API : +/* SIOCSIWAUTH/SIOCGIWAUTH parameters (0 .. 4095) + * (IW_AUTH_INDEX mask in struct iw_param flags; this is the index of the + * parameter that is being set/ge