From mboxrd@z Thu Jan 1 00:00:00 1970 From: Larry Finger Subject: Re: Problem authenticating using WPA with bcm43xx-softmac Date: Wed, 07 Jun 2006 13:12:51 -0500 Message-ID: <44871723.3040803@lwfinger.net> References: <4485D66B.7080108@lwfinger.net> <1149682213.3999.14.camel@johannes> <4486F513.5050906@lwfinger.net> <1149695470.3925.7.camel@johannes> <1149695859.3925.11.camel@johannes> <1149701352.2625.20.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Johannes Berg , netdev@vger.kernel.org, Jouni Malinen Return-path: Received: from mtiwmhc13.worldnet.att.net ([204.127.131.117]:65432 "EHLO mtiwmhc13.worldnet.att.net") by vger.kernel.org with ESMTP id S1751194AbWFGSM5 (ORCPT ); Wed, 7 Jun 2006 14:12:57 -0400 To: Dan Williams In-Reply-To: <1149701352.2625.20.camel@localhost.localdomain> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Dan Williams wrote: > On Wed, 2006-06-07 at 17:57 +0200, Johannes Berg wrote: >> On Wed, 2006-06-07 at 17:51 +0200, Johannes Berg wrote: >> >>> Well, it should be shown in the 802.11i spec too. >> I suppose that it is the association request, and needs to contain the >> RSN described in 7.3.2.25 as per 7.2.3.4 in 802.11i. This is, afaik, the >> 'generic IE' that is added with the wext. Now, it looks like the RSN >> isn't included but the WPA2 info or something? Also, the genIE in your >> log doesn't look correct to me, starting with ffffff?? Jouni, do you >> have any idea what might be going on? > > I believe that wpa_supplicant tells the driver what genie to use through > the SIOCSIWGENIE wext call. The IEs match between what the driver > appears to be reporting, and what wpa_supplicant says from the logs. > wpa_supplicant is almost certainly writing the correct IE to the driver > through wext, so I think the debug output from softmac must be > formatting the string incorrectly when printing it out to the logs. > > Looking at it further: > > struct ieee80211softmac_wpa { > char *IE; > int IElen; > int IEbuflen; > }; > > from ieee80211softmac_wx.c: ieee80211softmac_wx_set_genie() > > memcpy(mac->wpa.IE, extra, wrqu->data.length); > dprintk(KERN_INFO PFX "generic IE set to "); > for (i=0;idata.length;i++) > dprintk("%.2x", mac->wpa.IE[i]); > dprintk("\n"); > > the dprintk code isn't doing the right thing here, given an array of > bytes. You probably want: > > dprintk("%.2hhx", mac->wpa.IE[i]); > > (ie, add the "hh" before the x to tell the print that it's a char) > That doesn't work - the result is %hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx%hx I changed the line to cast the output byte as a u8 as follows: dprintk("%.2x", (u8)mac->wpa.IE[i]); This produces the line generic IE set to dd160050f20101000050f20201000050f20201000050f202 This is the WPA IE supplied by wpa_supplicant and it matches the one used in the ndiswrapper case. One mystery solved, but why doesn't it work? Johannes - should I submit the patch to fix this printout, or would you like to do it? Larry