Have you experienced any LBT or DFS hits? With only one channel in the config I believe the ap would stop transmitting for 30min. Knock on wood, I've never had a DFS or LBT hit but we are in a pretty rural mountainous area.
A 2.5mhz secondary channel offset seems to keep the aps on my network happy. YMMV -sean On Wednesday, September 9, 2015, George Skorup <geo...@cbcast.com> wrote: > Yeah, but 2.5MHz doesn't help if it's a real LBT or DFS hit. Too many > interference issues if I let APs roam free. Would cause more harm than good. > > On 9/9/2015 11:07 PM, Sean Heskett wrote: > > You can choose a LBT or DFS secondary channel 2.5mhz away from the primary > channel...you don't have choose a secondary that is 20mhz away. Unless > of course you are in an area that would trigger a lot of DFS or LBT > events. > > -sean > > On Wednesday, September 9, 2015, George Skorup < > <javascript:_e(%7B%7D,'cvml','geo...@cbcast.com');>geo...@cbcast.com > <javascript:_e(%7B%7D,'cvml','geo...@cbcast.com');>> wrote: > >> Nope, no authentication at all. >> >> Next time it happens, I will try to get the logs. It's impossible to know >> when or where it will strike, so retrieving the SM's side of the logs is >> very unlikely while this is occurring. Maybe I can get my house moved over >> to a 3.6 450 on Friday or some time next week and wait for it to happen. >> >> I have never seen this issue on 5GHz or the one lonely 2.4GHz 450 we have >> up. Something with the 3.6GHz 450 is just... different. The only thing that >> comes to mind is LBT which I understand is modified DFS. Maybe the thing is >> that I don't have any alternate frequencies configured on any of the 3.6 >> 450 sectors. There's simply no alternate channels to have a sector move to >> in a cluster. Many of these are co-located with UBNT 3.65 running in the >> lower half of the band while we're migrating customers to the 450. >> >> On 9/9/2015 10:28 PM, Chitrang Srivastava wrote: >> >>> Hi George, >>> >>> For your other issues where SM fails to register and you have to reboot >>> AP. >>> Please send AP logs , on AP goto 'logs - SM sessions' and then select >>> luid of SM which has problem, after submitting you will get the logs, >>> >>> Further if it is possible to reach SM please get similar logs 'logs - AP >>> session ' >>> >>> We are working on a similar issue but with RADIUS authentication for SM, >>> for you SM authentication is radius as well? >>> >>> Thanks >>> Chitrang Srivastava >>> ________________________________________ >>> From: Af <af-boun...@afmug.com> on behalf of George Skorup < >>> geo...@cbcast.com> >>> Sent: 29 August 2015 09:30:14 >>> To: af@afmug.com >>> Subject: Re: [AFMUG] Canopy 13.4 Watchdog Reset >>> >>> What does FreeRun have to do with it? >>> >>> I have a couple 450 test sites on 13.4 and haven't seen any watchdog >>> resets. Granted, that's only two APs. Definitely still see it on 13.2.1. >>> It's not a daily thing, but yeah, annoying. >>> >>> One thing I'm seeing on the 3.6 450 with 13.2.1 is the APs getting into >>> a state where they say there's no sync pulse. Then it says receiving >>> sync, no sync... over and over every few seconds until they are >>> rebooted. All the while the SyncInjector says nothing is wrong. Tracking >>> 8+ sats. No increment for the 1PPS Active counter. I understand this had >>> something to do with the FreeRun stuck issue, which was apparently >>> resolved with 13.4, but I'm waiting on 13.4.1 so some other issues get >>> fixed before I can update the entire network. >>> >>> Anyway, if I leave the APs alone for a while (say it happens in the >>> middle of the night while I'm sleeping), they mysteriously return to >>> normal after anywhere from 3 to 20 minutes. Then if any SM loses >>> registration (or if I force an SM to rescan), it fails to register for >>> no reason at all. Reboot the AP, everything works again. I have no >>> freakin idea what this is about. >>> >>> On 8/28/2015 9:54 PM, Mark Radabaugh wrote: >>> >>>> We have been seeing this across 200+ AP's >>>> >>>> It's getting truly annoying. Cambium tech support has helpful >>>> suggestions like'just put them in free run'. Um.... Thanks for the help, >>>> but no. >>>> >>>> Mark Radabaugh >>>> Amplex >>>> 27800 Lemoyne, Ste F >>>> Millbury, OH 43447 >>>> 419-261-5996 >>>> >>>> On Aug 28, 2015, at 4:56 PM, Brian Sullivan <installe...@foxvalley.net >>>>> <javascript:_e(%7B%7D,'cvml','installe...@foxvalley.net');>> wrote: >>>>> >>>>> Last week we rolled out 13.4 to 450 AP's after testing in-house for a >>>>> while. While running 13.2 we would see an AP here or there reboot on >>>>> occasion by itself. The only message in the Event Log mentions Watchdog >>>>> Reset. This is one of the bugs that Cambium noted was fixed in the 13.4 >>>>> release notes. >>>>> >>>>> Since we upgraded the network to 13.4 we are now seeing at least 4 >>>>> AP's out there rebooting several times per day. On one of these AP's we >>>>> are also seeing SM's (all 17 registered) reboot along with the AP. The >>>>> site has UPS backup so I know it's not a power grid problem. I am >>>>> planning >>>>> to roll the affected AP's back to 13.2 this evening. >>>>> >>>>> Anyone else having Watchdog issues with the 13.4 release? >>>>> >>>>> ******System Startup****** >>>>> System Reset Exception -- Watchdog Reset >>>>> Software Version : CANOPY 13.4 AP-DES >>>>> Board Type : P12 >>>>> Device Setting : 5.7GHz MIMO OFDM - Access Point - 0a-00-3e-a0-08-e5 - >>>>> 5760.0 MHz - 20.0 MHz - 1/16 - CC 85 - 2.5 ms >>>>> FPGA Version : 040715 >>>>> FPGA Features : DES, Sched, US/ETSI; >>>>> 08/28/2015 : 14:11:42 CST : :Time Set >>>>> 08/28/2015 : 14:11:58 CST : Acquired sync pulse from Power Port. >>>>> >>>>> >>>>> >> >
