Hi Johannes, > -----Original Message----- > From: Johannes Berg [mailto:johannes@xxxxxxxxxxxxxxxx] > Sent: Sunday, April 03, 2011 1:37 AM > To: Bing Zhao > Cc: linux-wireless@xxxxxxxxxxxxxxx; John W. Linville; Amitkumar Karwar; Kiran Divekar; Yogesh Powar; > Marc Yang; Frank Huang; Jouni Malinen > Subject: Re: [PATCH 1/2] mwifiex: return success in set_default_key for WPA/WPA2 > > On Sun, 2011-04-03 at 10:02 +0200, Johannes Berg wrote: > > On Fri, 2011-04-01 at 18:36 -0700, Bing Zhao wrote: > > > From: Amitkumar Karwar <akarwar@xxxxxxxxxxx> > > > > > > When testing wpa_supplicant with 'nl80211' driver to connect > > > to an AP with WPA/WPA2 security, we notice the followings: > > > > > > 1) add_key is called firstly with the key from cfg80211 > > > 2) set_defaut_key is called next > > > > > > set_default_key() is specific to WEP keys and should not be > > > called in case of WPA/WPA2 security. The set_default_key() > > > won't be called if wpa_supplicant uses "-Dwext" option, > > > but it's been called if "-Dnl80211" option is specified. > > > > > > We can fix this issue by adding a check to return from > > > set_default_key() if WEP key is not configured. > > > > Hmmm. Yeah this seems like it shouldn't be happening, but maybe checking > > should be in cfg80211 and it should reject the supplicant's call? In wext-compat.c, set_default_key() is called only in WEP security. In nl80211.c, there isn't such checking. > > Ok Jouni and I just discussed this briefly, and it looks like there is > indeed a special case where the GTK is also set as the default TX key: > this case is when the station requested "no pairwise" or when the AP did > the same thing in the configuration. From the wpa_supplicant debug log generated by Amit, it seems that set_default_key() is called while installing PTK to the driver. Is it expected? WPA: Installing PTK to the driver. WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 wpa_driver_nl80211_set_key: ifindex=12 alg=2 addr=0x80a7168 key_idx=0 set_tx=1 seq_len=6 key_len=32 addr=00:1b:2f:55:79:7e The complete log file is attached for your reference. > > Is it possible that this just happens to be the case in your tests? It > looks like that would be rather strange, but that's a corner case where > the supplicant would possibly set the GTK as the default key. Not the same corner case. In our test both pairwise and groupwise are configured. > > In any case, this patch seems wrong in that you should never return > success if the operation actually failed. Could you please advise how we should resolve this? Thanks, Bing
Attachment:
wpa_supplicant-nl80211.log
Description: wpa_supplicant-nl80211.log
