wpa_supplicant failed to associate

Dan Williams dcbw at redhat.com
Sun Sep 20 10:50:24 EDT 2009


On Sun, 2009-09-20 at 10:36 +0530, Raghavendra wrote:
> Hi, 
>    Please find below answers for your queries. 
>  
> 1) What wifi driver/version, and what kernel version? 
>     Driver: TI driver, Kernel: 2.6.24-16-generic
>  
> 2) what version of wpa_supplicant?  Do you have any custom patches? 
>   I am using wpa_supplicant-0.5.11, I have following modification in
> supplicant.
>  
>   In ctrl_iface.c ----> wpa_supplicant_ctrl_iface_scan_results()
> ------>
>  
>   if(wpa_s->scan_results != NULL)
>  {
>         os_free(wpa_s->scan_results);
>         wpa_s->scan_results = NULL;
>         wpa_s->num_scan_results = 0;
>   }
>  
>   Since I wanted wpa_supplicant to always get latest scan result from
> driver. I added above check. Also I am not using wpa_supplicant for
> 'scan'. I am using it only to get 'scan_result'. For scanning I am
> using WEXT ioctl.
> 
> 3) What wpa_supplicant driver are you using, wext, a custom one, ...? 
>   I am using -Dwext.
>  
> Following is my wpa_supplicant config file for WPA-TKIP
> -----------------------------------------------------------------------------------------------------
> ctrl_interface=/var/run/wpa_supplicant
> ap_scan=2
> network={
> ssid="testap"  //ap name changed
> proto=WPA
> key_mgmt=WPA-PSK
> pairwise=TKIP  // using pairwise=TKIP CCMP for WPA-CCMP
> group=TKIP     // using group=TKIP CCMP for WPA-CCMP
> psk="testtest"
> }
> ----------------------------------------------------------------------------------------------------------

It sounds to me like the driver is more of the issue; it's not expecting
the sequence of WEXT ioctls that wpa_supplicant is issuing.  That's not
unexpected, since the WEXT interface is crap, and that's why it's
gradually getting replaced in the latest 2.6.3x kernels.  But that
doesn't help you at the moment.

I've had problems like this before in drivers that I maintain, and I'd
guess that your problem is somewhere in the handlers for SIOCSIWENCODE,
SIOCSIWENCODEEXT, and SIOCSIWAUTH.  The driver has to take precautions
to handle a number of different sequences of command issue, and many
drivers that aren't part of the upstream kernel (your TI driver is not)
haven't been fixed to do that.

The Libertas driver (for example) has a short timer so that all the
ioctl calls get batched up into a single request to the chip itself,
then are fired off all at once.  This prevents the requests from being
broken up into multiple ones like [channel, ssid] <send to chip>, [mode,
key] <send to chip> which sometimes confuses the chips.  It may be that
the TI driver is not built like this; this approach helps mitigate some
of the issues of WEXT.

You may be able to debug your problem by enabling verbose logging in the
TI driver and figuring out what sequence of commands is being sent to
it, and what the driver is internally doing.  It's probably not going to
be a 10-minute fix.

Dan


>  
> ----- Original Message ----- 
> From: "Dan Williams" <dcbw at redhat.com>
> To: "Raghavendra" <s.raghu at samsung.com>
> Cc: <hostap at lists.shmoo.com>
> Sent: Friday, September 18, 2009 10:53 PM
> Subject: Re: wpa_supplicant failed to associate
> 
> 
> > On Fri, 2009-09-18 at 21:28 +0530, Raghavendra wrote:
> >> Hi All,
> >>  
> >>    
> >>   I am getting following error while connecting to AP.
> >>  
> >>
> --------------------------------------------------------------------------------------
> >> Trying to associate with SSID 'testap'      // ap name changed
> >> 
> >> Association request to the driver failed
> >> 
> >> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> >> 
> >> Associated with 00:1d:7e:0e:3f:54
> >> 
> >> WPA: IE in 3/4 msg does not match with IE in Beacon/ProbeResp
> >> (src=00:1d:7e:0e:3f:54)
> >> 
> >> WPA: WPA IE in Beacon/ProbeResp - 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
> >> 
> >> WPA: WPA IE in 3/4 msg - hexdump(len=24): dd 16 00 50 f2 01 01 00
> 00
> >> 50 f2 04 01 00 00 50 f2 04 01 00 00 50 f2 02
> >> 
> >> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> >> 
> >> Authentication with 00:00:00:00:00:00 timed out.
> >> 
> >>
> ---------------------------------------------------------------------------------------------------------------------------------------
> >> 
> >>  
> >> 
> >> scenario:
> >> 
> >> 1. connect and disconnect with WPA-TKIP - success
> >> 
> >> 2. then try to connect with WPA-CCMP - failed
> >> 
> >> or 
> >> 
> >> 1. connect and disconnect with WPA-CCMP - success
> >> 
> >> 2. then try to connect with WPA-TKIP - failed
> > 
> > It could be many things...  a few questions first:
> > 
> > 1) What wifi driver/version, and what kernel version?
> > 
> > 2) what version of wpa_supplicant?  Do you have any custom patches?
> > 
> > 3) What wpa_supplicant driver are you using, wext, a custom
> one, ...?
> > 
> > One theory is that the kernel driver itself isn't properly resetting
> the
> > state when the new configuration for SIOCSIWENCODEEXT comes in.  The
> > message "Association request to the driver failed" *could* indicate
> a
> > driver bug, but it's also reported when the driver just doesn't
> support
> > some of the less-necessary commands.  Giving the details above will
> help
> > diagnose that.
> > 
> > Dan
> >



More information about the HostAP mailing list