#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 [EMAIL PROTECTED]):
Well, I'm still puzzled, although the mystery is a bit different now.
In looking into the association-failure problem, I inferred from the logs
that an authorization/association request to an AP is something akin to a
scan, and that cancelling a scan when the VAP is trying to authenticate
with its chosen AP might be responsible for the association failure.
I rewrote my cancel-active-scan code, in the form of a subroutine which
can perform a "graceful" cancellation of an existing active scan. It
accepts two parameters - a "grace time" during which it'll wait for an
existing active scan to terminate before the scan is cancelled, and a
"timeout" which limits the amount of time it'll wait for the cancellation
to take effect. In the start-scan ioctl, I call this with 100 msec for
both timeouts.
This change, applied against this afternoon's subversion code, appears to
fix the inability to associate. The VAP associates with the AP just
fine...
... and the disassociates a few seconds later and starts scanning again.
Lather, rinse, repeat - it won't stay associated.
The dissociation appears to be triggered by the tx_timeout routine.
Apparently, the driver tried to send a management frame at some point, and
this transmit never took place or its status was lost or the timeout
wasn't properly cancelled. The tx_timeout routine resets the VAP status
back to SCANNING, and the whole cycle repeats.
I haven't been able to figure out which management frame is timing out, or
why. I don't know whether the loss of this frame is caused by the
cancellation of an active scan, or whether it's due to some other change
in the driver recently and is unrelated to my change.
I'll attach the current version of my patch. If we can figure out the
cause of the problem, then possibly the "graceful cancel" routine could be
used by #228 as well.
--
Ticket URL: <http://madwifi.org/ticket/275>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity
