date:20150909

Re: [AFMUG] Canopy 13.4 Watchdog Reset

2015-09-09 Thread Bill Prince


Is this just happening on APs, or is it an issue on SMs too?

Reason I ask, is that I was just looking at an SM that has been on 13.4 
for about a month, and shows several watchdog/stack dumps since that 
time. It's been running clean for the last 10 days though...


bp


On 9/9/2015 8: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  on behalf of George Skorup 
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  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.

Re: [AFMUG] Canopy 13.4 Watchdog Reset

2015-09-09 Thread Sean Heskett

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

Re: [AFMUG] Canopy 13.4 Watchdog Reset

2015-09-09 Thread George Skorup

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 > 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  on behalf of George Skorup

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

Re: [AFMUG] Field Service Bulletin - PMP 450 SM

2015-09-09 Thread George Skorup

I think the FSB is very specific to a set of radios that were identified
as improperly assembled. I had one 5GHz 450 SM show the ADI
communication failure. And a 3.6GHz SM show RF calibration failure. Both
rebooted with ADI force resets. Both not on the list. Cambium RMA'd them
without too many questions.

FYI. Maybe it's related, maybe not. I found some new SMs that had a few
solder balls rattling around in the cases, but they work fine.

On 9/9/2015 9:21 PM, Ken Hohhof wrote:
I have seen 2 out of around 100 suddenly exhibit the ADI
Communications Failure after about a month in service, neither was on
the serial number list. So a 2 day burn-in may help but you won’t be
bullet-proof. We’ve only seen it on 5 GHz SMs, but we use a lot more
5 GHz than 3.65 GHz, and no 2.4 GHz. No apparent correlation with any
environmental conditions like hot or stormy weather that could have
precipitated it.
Worst case will be it fails intermittently and the new customer just
thinks your service is really unreliable. One of the 2 failures we
saw was intermittent, rebooting for several hours, then registered for
several hours, then rebooting again, no rhyme or reason. At least if
it fails hard, they will call.

*From:* Tushar Patel
*Sent:* Wednesday, September 09, 2015 8:48 PM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] Field Service Bulletin - PMP 450 SM
We had 9 failures in 50 we ordered, those were not listed in the unit
serial numbers.
What we are doing now is running radios in the office for at least two
days before we send out and we are seeing these failures in the office.
Even after doing that today we had one fail which was 1 hr drive from
the office and it was new customer too, installed last week. This
gives us bad reputation and cost us lot too.
So whatever the root cause mentioned in the email, if it was
identified but did not include the batch we got, so something is not
adding up still.

I really hope cambium gets to the bottom of these quickly.
Tushar

On Sep 9, 2015, at 8:22 PM, Steve D > wrote:

Just a bump... was this ever sorted out? Contained to just one batch
of 5.8 radios as listed? I know I've seen reports in other
frequencies but seemed less widespread? No mention from anyone in a
while... Just want to know before our next order...

1 2 >

1 - 100 of 136 matches

Mail list logo