> If we know about this issue before release and documented it in the release > notes, it could have been spun as > a "feature", but that opportunity is gone now :) > > The concern is how long it takes the SM to scan for the AP on each boot up, > right? How about a flag that tell that > SM that when it is rebooted, it should first try to connect with the AP it > was connected to prior to reboot, and to initiate > the scan only if that fails? Or do you need a button that says "turn off all > 2.5 center frequencies"?
Not so sure on this. We use same color code on all AP's currently. Occasionally an SM will get on a non-ideal signal AP in the cluster etc and stick there. To fix this every night a perl script scans all SM's in the system and logs signal strength etc. If the MAC of the AP an SM is registered too has changed it reboots the SM and waits for it to register again and records the MAC of the AP it registered too. It sure would be nice if there was a SNMP command to trigger a new AP Eval scan instead of reboot but there is not. Would sure also be nice if there was SNMP command to trigger a link test from the SM rather then just the AP. I see a better solution as a primary scan list and a secondary scan list. Primary list is the small list of frequencies and channel sizes we use 95 percent of time. The secondary list is the full list we scan when we try X seconds and cannot connect. Such as the situation when interference moves in and we can only find a couple 5mhz channel remotely clean. > Not promising to make any enhancements as we try to make a bugfix release for > the 13.2 issues, > but definitely looking for feedback on the best way(s) to reduce the scan > time.
