http://defect.opensolaris.org/bz/show_bug.cgi?id=4993
amaguire <alan.maguire at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ACCEPTED |FIXINPROGRESS
--- Comment #6 from amaguire <alan.maguire at sun.com> 2009-05-07 03:41:38 ---
(In reply to comment #5)
> All sounds good Alan...
>
> So when the scan is initiated, is it assumed that the WLAN connection is
> failed
> at that point, or do we wait until after the scan has completed. I ask since
> it's always possible that the drop in signal is just a blip - e.g. a truck
> passing between you and the AP if you're in the park...
>
> It would seem to make sense to not totally fail the connection until the scan
> has completed and we can do one of several things:
>
> 1) The AP is in the scan, and the signal looks fine now, double check the
> existing
> connection again...
>
> 2) The AP is in the scan, but another AP with the same ESSID exists, try
> switching
> to the stronger AP with the same ESSID
>
> 3) The AP doesn't even appear in the scan - drop it and look for alternative.
>
> Does this make sense, or am I being just too paranoid?
The nice thing about the current solution is that it just re-initiates
a standard scan if the signal drops below threshold. The standard scan
takes care of 1, 2 and 3 since:
- if the signal has recovered, it won't switch (1)
- if another AP with the same ESSID and better signal strength appears, it'll
switch (provided 1 is not true) (2)
- if the AP is gone, find another visited one, appealing to the user
if none is found in scan results (3)
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
