Problem authenticating using WPA with bcm43xx-softmac

Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Since my Linksys WRT54G V1 died and was replaced with a V5 (Yes, I know it was a mistake.), I have 
been unable to authenticate using WPA-PSK TKIP with bcm43xx-softmac. I'm sure that my wpa_supplicant 
setup is OK as it has not been changed since the AP was changed, and the system works if I use 
ndiswrapper with the Windows driver.

The logged messages are:

Jun  6 13:34:08 larrylap kernel: bcm43xx: set security called
Jun  6 13:34:08 larrylap kernel: bcm43xx:    .level = 0
Jun  6 13:34:08 larrylap kernel: bcm43xx:    .enabled = 0
Jun  6 13:34:08 larrylap kernel: bcm43xx:    .encrypt = 0
Jun  6 13:34:09 larrylap kernel: SoftMAC: Start scanning with channel: 1
Jun  6 13:34:09 larrylap kernel: SoftMAC: Scanning 11 channels
Jun  6 13:34:09 larrylap kernel: SoftMAC: Scanning finished
Jun  6 13:34:09 larrylap kernel: SoftMAC: Associate: Scanning for networks first.
Jun  6 13:34:09 larrylap kernel: SoftMAC: Start scanning with channel: 1
Jun  6 13:34:09 larrylap kernel: SoftMAC: Scanning 11 channels
Jun  6 13:34:09 larrylap kernel: SoftMAC: Scanning finished
Jun  6 13:34:09 larrylap kernel: SoftMAC: Associate: Scanning for networks first.
Jun  6 13:34:09 larrylap kernel: SoftMAC: Start scanning with channel: 1
Jun  6 13:34:09 larrylap kernel: SoftMAC: Scanning 11 channels
Jun  6 13:34:09 larrylap kernel: SoftMAC: Associate: Scanning for networks first.
Jun  6 13:34:09 larrylap kernel: SoftMAC: Start scanning with channel: 1
Jun  6 13:34:09 larrylap kernel: SoftMAC: Scanning 11 channels
Jun  6 13:34:09 larrylap kernel: SoftMAC: Queueing Authentication Request to 00:14:bf:85:49:fa
Jun  6 13:34:09 larrylap kernel: SoftMAC: cannot associate without being authenticated, requested 
authentication
Jun  6 13:34:09 larrylap kernel: SoftMAC: Sent Authentication Request to 00:14:bf:85:49:fa.
Jun  6 13:34:10 larrylap kernel: SoftMAC: Open Authentication completed with 00:14:bf:85:49:fa
Jun  6 13:34:10 larrylap kernel: SoftMAC: sent association request!
Jun  6 13:34:10 larrylap kernel: SoftMAC: Scanning finished
Jun  6 13:34:10 larrylap kernel: SoftMAC: sent association request!
Jun  6 13:34:10 larrylap kernel: SoftMAC: generic IE set to 
ffffffdd160050fffffff20101000050fffffff20201000050fffffff20201000050fffffff202
Jun  6 13:34:10 larrylap kernel: SoftMAC: associating failed due to invalid pairwise cipher
Jun  6 13:34:10 larrylap kernel: SoftMAC: sent association request!
Jun  6 13:34:10 larrylap kernel: SoftMAC: associating failed due to invalid pairwise cipher

The debug output from wpa_supplicant is as follows:

larrylap:~ # wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -Dwext -ddd
Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'wext' ctrl_interface 'N/A'
Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf'
Reading configuration file '/etc/wpa_supplicant.conf'
ctrl_interface='/var/run/wpa_supplicant'
Line: 3 - start of a new network block
ssid - hexdump_ascii(len=6):
      6c 77 66 64 6a 66                                 lwfdjf
scan_ssid=1 (0x1)
key_mgmt: 0x2
proto: 0x1
pairwise: 0x18
group: 0x18
PSK (ASCII passphrase) - hexdump_ascii(len=27): [REMOVED]
priority=3 (0x3)
PSK (from passphrase) - hexdump(len=32): [REMOVED]
Priority group 3
    id=0 ssid='lwfdjf'
Initializing interface (2) 'wlan0'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
SIOCGIWRANGE: WE(compiled)=20 WE(source)=18 enc_capa=0xf
   capabilities: key_mgmt 0xf enc 0xf
Own MAC address: 00:06:25:40:6f:03
wpa_driver_wext_set_wpa
WEXT auth param 7 value 0x1 -
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_countermeasures
WEXT auth param 4 value 0x0 -
wpa_driver_wext_set_drop_unencrypted
WEXT auth param 5 value 0x1 -
Setting scan request: 0 sec 100000 usec
Added interface wlan0
Wireless event: cmd=0x8b06 len=8
State: DISCONNECTED -> SCANNING
Starting AP scan (specific SSID)
Scan SSID - hexdump_ascii(len=6):
      6c 77 66 64 6a 66                                 lwfdjf
Wireless event: cmd=0x8b19 len=8
Received 395 bytes of scan results (2 BSSes)
Scan results: 2
Selecting BSS from priority group 3
0: 00:14:bf:85:49:fa ssid='lwfdjf' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
    selected based on WPA IE
Trying to associate with 00:14:bf:85:49:fa (SSID='lwfdjf' freq=0 MHz)
Cancelling scan request
WPA: clearing own WPA/RSN IE
Automatic auth_alg selection: 0x1
WEXT auth param 6 value 0x1 -
WPA: using IEEE 802.11i/D3.0
WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2
WPA: set AP WPA IE - hexdump(len=26): dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 
50 f2 02 00 00
WPA: clearing AP RSN IE
WPA: using GTK TKIP
WPA: using PTK TKIP
WPA: using KEY_MGMT WPA-PSK
WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 
01 00 00 50 f2 02
No keys have been configured - skip key clearing
wpa_driver_wext_set_drop_unencrypted
WEXT auth param 5 value 0x1 -
State: SCANNING -> ASSOCIATING
wpa_driver_wext_associate
wpa_driver_wext_set_gen_ie
WEXT auth param 0 value 0x2 -
WEXT auth param 1 value 0x4 -
WEXT auth param 2 value 0x4 -
WEXT auth param 3 value 0x2 -
WEXT auth param 10 value 0x1 -
WEXT auth param 8 value 0x0 -
Setting authentication timeout: 10 sec 0 usec
EAPOL: External notification - EAP success=0
EAPOL: External notification - EAP fail=0
EAPOL: External notification - portControl=Auto
Wireless event: cmd=0x8b06 len=8
Wireless event: cmd=0x8b1a len=15
Authentication with 00:00:00:00:00:00 timed out.
Added BSSID 00:00:00:00:00:00 into blacklist
State: ASSOCIATING -> DISCONNECTED
No keys have been configured - skip key clearing
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
Setting scan request: 0 sec 0 usec
State: DISCONNECTED -> SCANNING
Starting AP scan (broadcast SSID)
Wireless event: cmd=0x8b19 len=8
Received 395 bytes of scan results (2 BSSes)
Scan results: 2
Selecting BSS from priority group 3
0: 00:14:bf:85:49:fa ssid='lwfdjf' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
    selected based on WPA IE
Trying to associate with 00:14:bf:85:49:fa (SSID='lwfdjf' freq=0 MHz)
Cancelling scan request
WPA: clearing own WPA/RSN IE
Automatic auth_alg selection: 0x1
WEXT auth param 6 value 0x1 -
WPA: using IEEE 802.11i/D3.0
WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2
WPA: set AP WPA IE - hexdump(len=26): dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 
50 f2 02 00 00
WPA: clearing AP RSN IE
WPA: using GTK TKIP
WPA: using PTK TKIP
WPA: using KEY_MGMT WPA-PSK
WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 
01 00 00 50 f2 02
No keys have been configured - skip key clearing
wpa_driver_wext_set_drop_unencrypted
WEXT auth param 5 value 0x1 -
State: SCANNING -> ASSOCIATING
wpa_driver_wext_associate
wpa_driver_wext_set_gen_ie
WEXT auth param 0 value 0x2 -
WEXT auth param 1 value 0x4 -
WEXT auth param 2 value 0x4 -
WEXT auth param 3 value 0x2 -
WEXT auth param 10 value 0x1 -
WEXT auth param 8 value 0x0 -
Setting authentication timeout: 10 sec 0 usec
EAPOL: External notification - EAP success=0
EAPOL: External notification - EAP fail=0
EAPOL: External notification - portControl=Auto
Wireless event: cmd=0x8b06 len=8
Wireless event: cmd=0x8b1a len=15
Authentication with 00:00:00:00:00:00 timed out.
BSSID 00:00:00:00:00:00 blacklist count incremented to 2
State: ASSOCIATING -> DISCONNECTED
No keys have been configured - skip key clearing
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
Setting scan request: 0 sec 0 usec
State: DISCONNECTED -> SCANNING

---repeats forever----

Why does SoftMAC set a generic IE rather than get one from wpa_supplicant? I would appreciate help 
with this problem.

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Tue, 2006-06-06 at 14:24 -0500, Larry Finger wrote:
> Jun  6 13:34:10 larrylap kernel: SoftMAC: generic IE set to 
> ffffffdd160050fffffff20101000050fffffff20201000050fffffff20201000050fffffff202

> Why does SoftMAC set a generic IE rather than get one from wpa_supplicant? I would appreciate help 
> with this problem.

generic IE is what the wext is called, it is the IE that wpa_supplicant
sets. Not sure what's going on though, I know next to nothing about wpa.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Johannes Berg wrote:
> 
> generic IE is what the wext is called, it is the IE that wpa_supplicant
> sets. Not sure what's going on though, I know next to nothing about wpa.

I have a little more information on what is happening. In IEEE Std 802.11i-2004, which defines the 
WPA protocol, Figure 11a shows the sequence of exchanges needed to associate. Both bcm43xx-softmac 
and ndiswrapper go through the "Open System Authentication" process. Where they seem to diverge is 
in the STA's "Association Request (Security Parameters)" step. With ndiswrapper, the AP responds 
with a WPA EAPOL-Key message; whereas with softmac, the AP sends back the "invalid pairwise cipher 
message" and rejects the association.

Can anyone point to a reference that states what the content of the Association Request should be to 
get the AP to respond with the EAPOL-Key message? Unfortunately, I have no possibility of 
implementing a sniffer to see what a "correct" message contains.

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Wed, 2006-06-07 at 10:47 -0500, Larry Finger wrote:

> I have a little more information on what is happening. 

Great.

> In IEEE Std 802.11i-2004, which defines the 
> WPA protocol, Figure 11a shows the sequence of exchanges needed to associate. Both bcm43xx-softmac 
> and ndiswrapper go through the "Open System Authentication" process. 

Right, you always have to do that.

> Where they seem to diverge is 
> in the STA's "Association Request (Security Parameters)" step. With ndiswrapper, the AP responds 
> with a WPA EAPOL-Key message; whereas with softmac, the AP sends back the "invalid pairwise cipher 
> message" and rejects the association.

Interesting. That's strange.

> Can anyone point to a reference that states what the content of the Association Request should be to 
> get the AP to respond with the EAPOL-Key message? Unfortunately, I have no possibility of 
> implementing a sniffer to see what a "correct" message contains.

Well, it should be shown in the 802.11i spec too.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Problem authenticating using WPA with bcm43xx-softmac

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

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?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Problem authenticating using WPA with bcm43xx-softmac

[Sam Leffler]

Johannes Berg wrote:
> On Wed, 2006-06-07 at 10:47 -0500, Larry Finger wrote:
> 
>> I have a little more information on what is happening. 
> 
> Great.
> 
>> In IEEE Std 802.11i-2004, which defines the 
>> WPA protocol, Figure 11a shows the sequence of exchanges needed to associate. Both bcm43xx-softmac 
>> and ndiswrapper go through the "Open System Authentication" process. 
> 
> Right, you always have to do that.
> 
>> Where they seem to diverge is 
>> in the STA's "Association Request (Security Parameters)" step. With ndiswrapper, the AP responds 
>> with a WPA EAPOL-Key message; whereas with softmac, the AP sends back the "invalid pairwise cipher 
>> message" and rejects the association.
> 
> Interesting. That's strange.
> 
>> Can anyone point to a reference that states what the content of the Association Request should be to 
>> get the AP to respond with the EAPOL-Key message? Unfortunately, I have no possibility of 
>> implementing a sniffer to see what a "correct" message contains.
> 
> Well, it should be shown in the 802.11i spec too.

Beware of the order of IE's in the management frames; some AP's are
touchy about this.

	Sam

Re: Problem authenticating using WPA with bcm43xx-softmac

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

On Wed, 2006-06-07 at 09:01 -0700, Sam Leffler wrote:

> Beware of the order of IE's in the management frames; some AP's are
> touchy about this.

Uh oh. I have no idea where the ieee80211 layer sticks that one,
probably at the end.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Sam Leffler wrote:
> Beware of the order of IE's in the management frames; some AP's are
> touchy about this.

That may be the cause here as the behavior when I changed AP's from the Linux-based model to one 
with VXWorks.

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Johannes Berg wrote:
> On Wed, 2006-06-07 at 09:01 -0700, Sam Leffler wrote:
> 
>> Beware of the order of IE's in the management frames; some AP's are
>> touchy about this.
> 
> Uh oh. I have no idea where the ieee80211 layer sticks that one,
> probably at the end.

I can verify that. I'm currently building a new module with a printk to verify that it is being 
added. If it is, I'll try moving it to see if it helps.

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Johannes Berg wrote:
> On Wed, 2006-06-07 at 09:01 -0700, Sam Leffler wrote:
> 
>> Beware of the order of IE's in the management frames; some AP's are
>> touchy about this.
> 
> Uh oh. I have no idea where the ieee80211 layer sticks that one,
> probably at the end.

I moved the WPA IE from the end forward without any effect. I have dumped that IE and find the 
following:

SoftMAC: Added WPA_IE of 24 bytes to association request
Contents of WPA_IE: 0xdd 0x16 0x00 0x50 0xf2 0x01 0x01 0x00 0x00 0x50
                     0xf2 0x02 0x01 0x00 0x00 0x50 0xf2 0x02 0x01 0x00
                     0x00 0x50 0xf2 0x02

I think I got the right thing, but I'm having trouble interpreting it. The dump was made by 
modifying the part of ieee80211softmac_assoc_req in ieee80211softmac_io.c where the WPA IE is added:

         /* Add WPA IE */
         if (mac->wpa.IElen && mac->wpa.IE) {
                 int i;
                 memcpy(data, mac->wpa.IE, mac->wpa.IElen);
                 data += mac->wpa.IElen;
                 printk(KERN_INFO PFX "Added WPA_IE of %d bytes to association request\n"
                         "Contents of WPA_IE: ", mac->wpa.IElen);
                 for (i=0; i<mac->wpa.IElen; i++)
                         printk("0x%02x ",mac->wpa.IE[i]);
                 printk("\n");
         }

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Dan Williams]

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;i<wrqu->data.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)

Dan

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

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;i<wrqu->data.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

Re: Problem authenticating using WPA with bcm43xx-softmac

[Dan Williams]

On Wed, 2006-06-07 at 13:12 -0500, Larry Finger wrote:
> Dan Williams wrote:
> > 
> > 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;i<wrqu->data.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

Weird, does the kernel not do something that fprintf() _does_ do here?
I tested with a short C program that mimics the behavior of this chunk
of code, and "%.2x" didn't work, but "%.2hhx" certainly did.  "hh" is
supposed to mean "A following integer conversion corresponds to a signed
char or unsigned char argument".  The original conversion was converting
stuff from la-la land after the first 4 bytes (in both softmac and my
testcase), and "hh" solved it in the testcase.  I did try casting to
char, but glibc pretty much ignored that.

Dan

> %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

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Dan Williams wrote:
> Weird, does the kernel not do something that fprintf() _does_ do here?
> I tested with a short C program that mimics the behavior of this chunk
> of code, and "%.2x" didn't work, but "%.2hhx" certainly did.  "hh" is
> supposed to mean "A following integer conversion corresponds to a signed
> char or unsigned char argument".  The original conversion was converting
> stuff from la-la land after the first 4 bytes (in both softmac and my
> testcase), and "hh" solved it in the testcase.  I did try casting to
> char, but glibc pretty much ignored that.

I also found that casting with char gave the same result as no cast, but that a u8 cast worked. I 
guess printk is _almost_ like fprintf.

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On Wed, 2006-06-07 at 13:12 -0500, Larry Finger wrote:
> > (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

Looks like the kernel doesn't support that modifier.

> 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, 

Yeah good :)

> but why doesn't it work?

No idea. If we had a dump maybe we could tell :/

> Johannes - should I submit the patch to fix this printout, or would you like to do it?

Please do.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Johannes Berg wrote:
> On Wed, 2006-06-07 at 13:12 -0500, Larry Finger wrote:
>> but why doesn't it work?
> 
> No idea. If we had a dump maybe we could tell :/

Do you mean a special dump, or is the kernel debug output and wpa_supplicant debug output sufficient?

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

On Fri, 2006-06-09 at 10:31 -0500, Larry Finger wrote:

> Do you mean a special dump, or is the kernel debug output and wpa_supplicant debug output sufficient?

I was thinking of packet dumps but earlier you said you couldn't create
any so I'm out of ideas for now.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Johannes Berg wrote:
> On Fri, 2006-06-09 at 10:31 -0500, Larry Finger wrote:
> 
>> Do you mean a special dump, or is the kernel debug output and wpa_supplicant debug output sufficient?
> 
> I was thinking of packet dumps but earlier you said you couldn't create
> any so I'm out of ideas for now.

Actually, I will be able to get packet dumps. The main disk drive in my server, which is a laptop, 
died last night. This will be an opportunity to upgrade it to a newer OS that will be able to run my 
other Wifi card. Neither one will be able to authenticate, but one can packet dump for the other. 
I'll send them when I get the server running again.

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Larry Finger]

Johannes Berg wrote:
> On Fri, 2006-06-09 at 10:31 -0500, Larry Finger wrote:
> 
>> Do you mean a special dump, or is the kernel debug output and wpa_supplicant debug output sufficient?
> 
> I was thinking of packet dumps but earlier you said you couldn't create
> any so I'm out of ideas for now.

I was finally able to get my second laptop running with bcm43xx so I could get packet dumps. When I 
analyzed them, the Association Response packet contained the following information:

"Association denied due to requesting station not supporting short preamble operation (0x0013)"

I think this is a bug in the code on my WRT54G V5 and I will report it to Linksys; however, in the 
meantime, I am able to connect using the following _ugly_ hack to softmac_assoc_req and 
softmac_reassoc_req:

diff --git a/net/ieee80211/softmac/ieee80211softmac_io.c b/net/ieee80211/softmac/ieee80211softmac_io.c
index cc6cd56..a1d0c10 100644
--- a/net/ieee80211/softmac/ieee80211softmac_io.c
+++ b/net/ieee80211/softmac/ieee80211softmac_io.c
@@ -199,6 +199,8 @@ ieee80211softmac_assoc_req(struct ieee80
         (*pkt)->capability |= mac->ieee->short_slot ?
                         cpu_to_le16(WLAN_CAPABILITY_SHORT_SLOT_TIME) : 0;
          */
+       /* add short preamble operation capability */
+       (*pkt)->capability |= cpu_to_le16(WLAN_CAPABILITY_SHORT_PREAMBLE);
         (*pkt)->capability |= mac->ieee->sec.level ? cpu_to_le16(WLAN_CAPABILITY_PRIVACY) : 0;
         /* Fill in Listen Interval (?) */
         (*pkt)->listen_interval = cpu_to_le16(10);
@@ -247,6 +249,8 @@ ieee80211softmac_reassoc_req(struct ieee
         (*pkt)->capability |= mac->ieee->short_slot ?
                         cpu_to_le16(WLAN_CAPABILITY_SHORT_SLOT_TIME) : 0;
          */
+       /* add short preamble operation capability */
+       (*pkt)->capability |= cpu_to_le16(WLAN_CAPABILITY_SHORT_PREAMBLE);
         (*pkt)->capability |= mac->ieee->sec.level ?
                         cpu_to_le16(WLAN_CAPABILITY_PRIVACY) : 0;


I expect that softmac should be listening to the driver as to whether this capability is available; 
however, I'm now up and running once again.

Larry

Re: Problem authenticating using WPA with bcm43xx-softmac

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]


> I expect that softmac should be listening to the driver as to whether this capability is available; 
> however, I'm now up and running once again.

Yeah, I think a patch was floating around too!

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]