#275: Scan for non-ESSID-broadcasting access point always fails
----------------------------------------+-----------------------------------
Reporter: [EMAIL PROTECTED] | Owner: mrenzmann
Type: defect | Status: assigned
Priority: minor | Milestone: version 1.0.0 - first
stable release
Component: madwifi: 802.11 stack | Version: trunk
Resolution: | Keywords:
Patch_attached: 1 |
----------------------------------------+-----------------------------------
Comment (by anonymous):
I recently entered ticket #646 that deals with wpa_suppl and scanning
results. This ticket was referenced in one of the comments...
One question I have is since scanning is asynchronous, why the worry about
cancelling a pending scan? Why not return OK? A SCAN_RESULTS event
should get fired and as I understand it will be propagated to any threads
listening for wireless events. I understand that if the 2nd scan and/or
subsequent scans are for a specific SSID, then incorrect results could be
returned. This could be handled by returning an error in the case where a
scan is pending and a new scan request is made with a different SSID. If
the SSIDs of subsequent scans are the same as the pending scan's SSID,
then just return OK.
Typically, a system will have one process in charge of scanning and
association ( eg. wpa_suppl, manual config via iwconfig, etc... ).
wpa_suppl does a pretty good job of managing it's own scan behavior. I
would argue that if two processes are running on a system and interferring
with each other's WiFi scanning, then the system in question has been
setup incorrectly.
Comments?
--
Ticket URL: <http://madwifi.org/ticket/275>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity
