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