(no subject)

[Naveen Singh]

From: Naveen Singh <nsingh@atheros.com>

The WPA-PSK association was not going through with 2.6.38
kernel. It was found that supplicant was not able to set
the PTK key. On further analysis it was found that the function
nl80211_set_key in file net/wireless/nl80211.c is returning with
code as -EOPNOTSUPP. This function has been modified to check for
the flag "WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS"in wiphy
struct. If this flag is not set in the driver init, it returns
from here thereby causing the association to fail. The solution
is to set this flag in driver init as there would be separate
default keys for unicast and multicast packets.

Signed-off-by: Naveen Singh <nsingh@atheros.com>
---
 drivers/staging/ath6kl/os/linux/cfg80211.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/ath6kl/os/linux/cfg80211.c b/drivers/staging/ath6kl/os/linux/cfg80211.c
index e87d3aa..ec22408 100644
--- a/drivers/staging/ath6kl/os/linux/cfg80211.c
+++ b/drivers/staging/ath6kl/os/linux/cfg80211.c
@@ -1455,6 +1455,11 @@ ar6k_cfg80211_init(struct device *dev)
     wdev->wiphy->cipher_suites = cipher_suites;
     wdev->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
 
+    /*Support the seprate keys for unicast and multicast packets
+     *This flag is needed because because nl80211 checks for this
+     *flag before calling cfg ops for setting the key.*/
+    wdev->wiphy->flags |= WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS;
+
     ret = wiphy_register(wdev->wiphy);
     if(ret < 0) {
         AR_DEBUG_PRINTF(ATH_DEBUG_ERR,
-- 
1.7.0.4

Re:

[Johannes Berg]

On Sat, 2011-04-30 at 19:30 -0700, Naveen Singh wrote:
> From: Naveen Singh <nsingh@atheros.com>
> 
> The WPA-PSK association was not going through with 2.6.38
> kernel. It was found that supplicant was not able to set
> the PTK key. On further analysis it was found that the function
> nl80211_set_key in file net/wireless/nl80211.c is returning with
> code as -EOPNOTSUPP. This function has been modified to check for
> the flag "WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS"in wiphy
> struct. If this flag is not set in the driver init, it returns
> from here thereby causing the association to fail. The solution
> is to set this flag in driver init as there would be separate
> default keys for unicast and multicast packets.

We were discussing this before ... and I think the bug is in the
supplicant actually asking for the GTK to be set as the default key or
something like that.

In any case, this doesn't seem right unless you actually do support
separate unicast keys. Are you sure you fully understand what you're
doing here, and not just randomly hacking in a workaround?

johannes

Re: set key and separate default keys

[Jouni Malinen]

On Sun, May 01, 2011 at 11:29:46AM +0200, Johannes Berg wrote:
> On Sat, 2011-04-30 at 19:30 -0700, Naveen Singh wrote:
> > The WPA-PSK association was not going through with 2.6.38
> > kernel. It was found that supplicant was not able to set
> > the PTK key. On further analysis it was found that the function
> > nl80211_set_key in file net/wireless/nl80211.c is returning with
> > code as -EOPNOTSUPP. This function has been modified to check for
> > the flag "WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS"in wiphy
> > struct. If this flag is not set in the driver init, it returns
> > from here thereby causing the association to fail. The solution
> > is to set this flag in driver init as there would be separate
> > default keys for unicast and multicast packets.

> We were discussing this before ... and I think the bug is in the
> supplicant actually asking for the GTK to be set as the default key or
> something like that.

Well, I'm not sure I would call it a bug, but more like a no-op
currently as far as PTK is concerned (that's the one that was failing in
this particular case). I don't remember whether the earlier discussion
was on PTK or GTK, but if it was for GTK, that would be more or less
pointless operation for RX-only key. In addition, the requirements
depend of which operation mode is used (STA/IBSS/AP) and change with
things like multiple PTK support in the future.

> In any case, this doesn't seem right unless you actually do support
> separate unicast keys. Are you sure you fully understand what you're
> doing here, and not just randomly hacking in a workaround?

Going through this was actually an interesting process.. A single flag
may not actually cover all the cases since some of these are quite
obviously separate default keys (e.g., AP mode and GTK) and for the
driver to be able to get that working, it looks like it has to set this
flag. However, that may not be the same situation in station mode.

As an immediate fix for the regression, I think it would be useful to
apply this patch in the driver. It is correct at least for AP mode and
somewhat irrelevant for station mode. I did not verify IBSS case yet.

For a more complete solution, we may want to consider splitting this
capability flag per mode or some other way of avoiding parts of the
extra validation that causes a regression with the deployed
wpa_supplicant versions.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: set key and separate default keys

[Jouni Malinen]

On Tue, May 03, 2011 at 04:28:43AM +0300, Jouni Malinen wrote:
> On Sun, May 01, 2011 at 11:29:46AM +0200, Johannes Berg wrote:
> > On Sat, 2011-04-30 at 19:30 -0700, Naveen Singh wrote:
> > > nl80211_set_key in file net/wireless/nl80211.c is returning with
> > > code as -EOPNOTSUPP. This function has been modified to check for
> > > the flag "WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS"in wiphy

> As an immediate fix for the regression, I think it would be useful to
> apply this patch in the driver. It is correct at least for AP mode and
> somewhat irrelevant for station mode. I did not verify IBSS case yet.

After some offline discussion on this, it sounds like the better
approach would be to just remove the check from set_key to fix the
regression. After that, the separate default keys flags becomes unused
and can be removed and as such, this patch should not be needed in
ath6kl (and would cause a compilation error once the flag gets removed).

-- 
Jouni Malinen                                            PGP id EFC895FA