please vote and discuss at http://community.cambiumnetworks.com/t5/Your-Ideas/Options-to-reduce-PMP-SM-scan-time/idi-p/36500. (yes, it is a plug for the new forum, but it does help to have all the discussion on one page than emails).
Rajesh Vijayakumar Cambium Networks On Mon, Nov 17, 2014 at 2:35 PM, Matt via Af <[email protected]> wrote: > > 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. >
