And +1 to the newer radios appearing to being more stable. Not all, but
most.
On 1/27/2016 6:04 PM, Sean Heskett wrote:
also for what it's worth the APs that seem to have the most problems
with the 14.1.1 software are the original APs from a few years ago
with the FSK port on them.
The newer APs and particularly the ones with the GLONASS GPS chip had
the least if any problems.
On Wed, Jan 27, 2016 at 4:35 PM, Sean Heskett <[email protected]
<mailto:[email protected]>> 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
