wpa_supplicant fails to use a correct network block, but succeeds when forced by wpa_cli.

[Dan Williams]

On Wed, 2009-06-17 at 15:51 -0700, Par Holmstrom wrote:
> >
> > Can you post some -dddt debug output for the run here?
> >
> > Dan
> >
> 
> ops..  wasn't allowed to post >25k...
> Attaching the gzipped log instead.
> 
> PS. This behavior only occurs when I use ap_scan=2 and a hidden ssid.
> wpa_supplicant have no problem switching network blocks and using them
> correctly @ ap_scan=1 with the same setup.

It's important to note the difference between ap_scan 1 & 2, and that's
why ap_scan sucks.  It's confusing.  Is there some reason you can't
simply use ap_scan=1 and scan_ssid=1 to probe-request the network you
want?

ap_scan=1 lets the driver probe-request the AP, and then the supplicant
will figure out the correct intersection of capabilities for the
connection.

ap_scan=2 just blasts the settings you've set to the card, and assumes
the card can handle the association with those specific settings.  If
you don't get the settings *just* right, it won't work.

Thus, I recommend you use ap_scan=1 + scan_ssid=1 since that almost
always works better.  If the driver has problems with probe-requests,
then the driver needs to get fixed.

1245251079.611135: Association request to the driver failed

that's part of your problem, the driver didn't like some parameter that
the supplicant sent.  Sometimes that's simply advisory as not all
drivers support all parameters.  I'd try bumping up the auth timeout to
10 or 15 seconds in the code just for testing, and if that works, we can
figure out what to do next there.  If that doesn't work, then we need
logging output from the driver about why it doesn't like the settings
the supplicant passed.

Dan