Re: iwl3945 delayed scan results after resume



On Fri, Sep 5, 2008 at 10:15 AM, Dan Williams <dcbw redhat com> wrote:
> On Thu, 2008-09-04 at 09:50 -0700, Dan Nicholson wrote:
>>
>> This seems to fix a bug in wpa_supplicant where the scan request
>> setting was not being restored if the initial association failed. This
>> makes the reconnection much faster for me. Does this seem reasonable?
>> Should I send this to the hostap list?
>
> It can't hurt to see what Jouni says.  Thanks for taking a look at this.
> I know there are a few issues with scanning in the supplicant still when
> no networks have been configured, and this might be one of them.  I'll
> take a closer look at the patch a bit later today too.

Thanks. That patch seems to help, but I think there's still something
wrong going on. With that patch, association drops from ~30 seconds to
~15 seconds. But if I look at the debug log for wpa again, it's doing
what I want by triggering a full scan immediately, but it still
doesn't find the AP until wpa reschedules another scan 5 seconds
later.

What I'm noticing now is that with or without the patch, wpa schedules
two broadcast scans first that do nothing. It's not until the third
scan where it scans specifically for my AP.

1220546429.722841: Setting scan request: 0 sec 0 usec
1220546429.722879: State: DISCONNECTED -> SCANNING
1220546429.722924: Starting AP scan (broadcast SSID)
1220546429.722928: Trying to get current scan results first without
requesting a new scan to speed up initial association
...
1220546429.722996: Setting scan request: 0 sec 0 usec
1220546429.723006: Starting AP scan (broadcast SSID)
...
1220546433.440267: No suitable AP found.
1220546433.440275: Setting scan request: 5 sec 0 usec
...
1220546433.444180: State: SCANNING -> DISCONNECTED
...
1220546438.441164: State: DISCONNECTED -> SCANNING
1220546438.441298: Starting AP scan (specific SSID)
1220546438.441304: Scan SSID - hexdump_ascii(len=5):
     64 77 63 61 62                                    dwcab

So now that it scans for my specific AP, it finds it immediately and
starts associating. So, what's causing the two broadcast scans before
it scans for my SSID? Why isn't it trying the specific scan
immediately? I can't quite figure out what's going on in
wpa_supplicant_scan().

--
Dan

Attachment: wpa2.log
Description: Binary data



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]