Created attachment 107093 [details] IEEE80211_HT_PARAM.patch on the current mainline the wireless does not connect. network manager just spins and asks for network key password. I have done the bisect(attached)which points to: 30eb1dc2c43039e0fe278e6f3a288de9f216d70d is the first bad commit reverting this does fix the problem. unfortunately reverting on the mainline is to big to do. going through and playing around I found: mlme.c /* check 40 MHz support, if we have it */ if (sband->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) { switch (ht_oper->ht_param & IEEE80211_HT_PARAM_CHA_SEC_OFFSET) { case IEEE80211_HT_PARAM_CHA_SEC_ABOVE: chandef->width = NL80211_CHAN_WIDTH_40; chandef->center_freq1 += 10; break; case IEEE80211_HT_PARAM_CHA_SEC_BELOW: chandef->width = NL80211_CHAN_WIDTH_40; chandef->center_freq1 -= 10; break; seems to be the trigger point for my issues over here. changing -= 10; to 15 or 20 on IEEE80211_HT_PARAM_CHA_SEC_BELOW: gets the wireless to work but causes a debug message to appear. after doing some more messing around I found changing: IEEE80211_HT_PARAM_CHA_SEC_BELOW 0x03 to IEEE80211_HT_PARAM_CHA_SEC_BELOW 0x02 gets the wireless working without causing a debug message to appear.(patch attached) as for what is right for this, im not sure.. guess the pro's will have to look at this and make all the changes. let me know and I can try a patch if need be.
Created attachment 107094 [details] bisect log attached is the bisect log for this issue.
Might be a duplicate of this? https://bugzilla.redhat.com/show_bug.cgi?id=981445
yeah they are hitting the same spot with the bisect. my guess is it is the same bug. if this is going to be pushed upstream I can wait, if not I will apply this to see.
Fixes should be in -rc6
okay.. just built.. wpa_supplicant is responding the way it should. so Id say fixed! will let you know if I see anything. thanks!