Yup, I've seen the out of range thing quite a bit.
On 1/27/2016 5:35 PM, Sean Heskett wrote:
so I gave up, our network and clients can't put up with all the memory
stack dumps, false DFS hits and registration failures that state "out
of range".
I downgraded the APs to 13.2.1 and everything is stable once again.
I look forward to a stable release of 14.1.1 for all the speed
improvements and the frame utilization stats etc. but I can't have our
network and clients suffer through buggy software anymore.
2 cents
-Sean
On Tue, Jan 26, 2016 at 5:41 PM, George Skorup <[email protected]
<mailto:[email protected]>> wrote:
Yuck. 3.6 does the same kind of stuff. If a sector reboots, it can
cause an LBT hit. It'll boot up and not quite be on the correct
timing. Usually fine after a few seconds. Known issue though. DFS
is different with the 30 minute timeout. THAT really sucks.
I have faith in the software guys though. They'll get the stack
dumps and resets figured out. Because I'm sure they're really
tired of hearing us bitch about it already. :)
On 1/26/2016 6:27 PM, Sean Heskett wrote:
yeah I saw the notes about the frame alignment. I set them all
to "on mode1" which didn't seem to help.
after watching this for a couple more days it seems like what is
happening is one AP on the tower will have a stack dump which
causes other APs on the tower to register a DFS hit.
then sometimes the DFS hit causes a stack dump in that AP.
14.1.1 has a lot of speed improvements but all the DFS hits that
are now happening that didn't happen on 13.2.1 are causing issues.
-Sean
On Sun, Jan 24, 2016 at 5:02 PM, George Skorup <[email protected]
<mailto:[email protected]>> wrote:
Did you read release notes regarding the frame alignment
thing? If you didn't upgrade any 430 and 100 in the area,
then you need to put the 450 frame alignment into legacy
mode. It shouldn't cause that many issues non-colocated, but
since you're still seeing some DFS hits here and there, that
could be the issue.
And are you absolutely sure those APs could get sync over
power before the upgrade? That seems really odd to just lose
that ability... unless they changed something with power port
pulse detection, which is entirely possible.
On 1/24/2016 2:58 PM, Sean Heskett wrote:
alright so after digging into this and making some
adjustments I think i've got the DFS events settled down now.
*1. Issue:* The 14.1.1 upgrade on PMP450 APs using the 5.4
band will delete "Alternate Frequency Carrier 1" and
"Alternate Frequency Carrier 2".
*Fix:* I had to log into each AP and manually add the 2
alternate channels back into the APs. This way when we have
a DFS event the AP will move to another channel. Since the
upgrade had deleted the 2 alternates the AP would shutdown
for 30min.
*2. Issue: *The tower that was having the most DFS issues
has 11 PMP450 APs and It's a commercial tower with a lot of
FM stations etc. All APs are connected to a CTM2 however
after the upgrade half the APs were getting sync from the
CTM2 over the power port and half didn't see any sync on the
power port.
*Fix: *after reading other reports of the 450s having weird
sync issues (causing other issues besides DFS events) I
decided to force all 11 APs to use the onboard GPS and I
turned off the power port timing and timing port timing to
achieve this. So now all APs at this tower are receiving
sync from the onboard GPS.
*3. Issue:* Somewhere along the line (13.x) cambium made it
so that a 450AP in the 5.4 band couldn't be set to more than
75% downlink. We originally had them set for 85% downlink
and they were timed with our 430 APs. Well when cambium
forced the change without any notification suddenly our 450
APs were out of time with our 430 APs. The area that this
problem tower is located we had removed all the 430 APs and
moved them to smaller towers at the edge of our network so I
didn't think we'd have any timing issues since there were
mountains blocking the signals. However there was one tower
with 430s still on it that was ~7 miles from this problem tower.
*Fix:* I changed the 430 timing to match the 450 timing at
the problem tower.
after running this weekend with the new settings I've only
had 1 DFS event where as before these fixes the were a
couple APs having DFS events 2-5 times a day.
In conclusion it seems like 14.1.1 is WAY more sensitive in
regards to timing sources. Also 14.1.1 doesn't seem to
reliably receive sync over power. Again when were were on
13.2.1 we didn't have any of these issues. 14.1.1
introduced some timing and DFS issues but they are somewhat
manageable (i really hate turning off a sync source because
it'd be nice to have it as a backup). It seems like if a
nearby AP is out of sync that will trigger a DFS event.
2 cents. I'll report again in a few days to see if these
fixes have eliminated the DFS events.
-Sean
On Wed, Jan 20, 2016 at 5:41 PM, Sean Heskett
<[email protected] <mailto:[email protected]>> wrote:
I will be opening a ticket with cambium but I wanted to
let everyone know this issues we just came across.
I updated all our 450 APs to 14.1.1 yesterday. On our
5Ghz 450s we use the 5.4 band. On all these APs the
"Alternate Frequency Carrier 1" and "Alternate Frequency
Carrier 2" were reset to "none". when I go and set them
back to what they should be, save and reboot they still
come back as "none".
Because of this if we experience a DFS event we have no
other frequency to hop to.
Additionally we have a couple APs that after the upgrade
are now seeing DFS events when previously they
experienced no events...ever. We live in the middle of
the rocky mtns. so there really shouldn't be any events
because of all the granite clouds in the way ;-)
anyway, DFS seems to be broken on 14.1.1 and I wanted to
let everyone know before they apply the upgrade incase
you need DFS to work properly.
-Sean
