Jason,
Question: Does your radio profile allow background scanning?
As I think the reason you do not see a lot from the show acsp neighbor command when using static channels is the APs seldom go off channel to scan for surroundings when ACSP is disabled (static channel). So you should see BSSIDs from neighbor APs that occupy the same channel space that the AP is currently set to but may not see others. Enabling background scanning may help this a but, but I can't remember to what extent or if at all.
A few things. The major ACSP enhancements were in the 8.x release of HiveOS. I doubt that Aerohive retrofitted the 6.x code train with said changes. One quick way to look is to do a show acsp channel-info.
If you do not see the DFS channels in there, that'd be one problem. If you do see them, but they all have a higher than ideal cost (16ish was the default value that was applied to all DFS channels IIRC way back when), then I'd say it's safe to say that the ACSP enhancements where one thing was to remove the buffer weight value on the DFS channels was removed never made their way to the 6.x code train.
You do have a few options though - while neither are pretty, both could allow your APs to use some of the DFS spectrum.
My approach to tackling it would be to use the CLI Supplement on a set of APs (scattered throughout your facilities) and to do the channel exclusion command (int wifi1 radio channel exclude <channel #>) on a large portion or all of the non-DFS channels. As that command sets the weight value of a channel to the max value (32765 IIRC or it will remove it from the output of the show acsp channel-info command).
Another approach would be to statically set DFS channels on certain APs and see about enabling the option for the radio profile to revert back to the DFS channel in the event that it changes after the DFS lockout period expires. Again, a CLI Supplement may be needed to do this. The command is: radio profile <RP name> dfs static-channel
Hope this helps!
Brian
