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]> 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]> 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]> 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]>
>>> [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
>>>>
>>>>
>>>
>>>
>>
>>
>

Reply via email to