Stupid things meaning SMs losing session randomly. SMs failing to
register and getting stuck 'out of range'. APs reporting no sync when
clearly there's sync and all SMs are still registered. Sync drifting.
And then DFS/LBT madness. Never had an AP go MIA though.
Do you have any other Canopy radios co-located with your problem AP? On
the same L2 segment? If you see it again, check the Layer 2 Neighbors
list and see if your vanished AP is still spitting out LLDP messages.
You have a SyncInjector powering the AP? Does anything look different
with that port's current consumption? Before, during, after? Compared to
other radios?
Let us know if it happens again on 14.1.2. This is really interesting to
me. If it's a software crash, then obviously the hardware watchdog
should reset it... unless it developed a h/w issue. Cap, resistor or
diode took a surge maybe? Like the stuck in default plug mode that the
older FSK radios are infamous for.
On 7/6/2016 9:09 PM, Ken Hohhof wrote:
Well, “stupid things start happening” seems apt. Maybe it just didn’t
cause a watchdog reset. Like the stupid people who still manage to
dress themselves, drive cars, vote, and generally defy Darwin.
Power cycling it via the Packetflux POE would briefly bring it back,
but only until SMs started registering. If we logged in during that
timeframe and changed the config so that SMs would not register, then
it would stay up.
This same AP screwed up last Sunday morning for a couple hours,
intermittently up and down until it started working again on its own.
*From:* George Skorup <mailto:geo...@cbcast.com>
*Sent:* Wednesday, July 06, 2016 8:40 PM
*To:* af@afmug.com <mailto:af@afmug.com>
*Subject:* Re: [AFMUG] 450 AP intermittently nonresponsive, doesn't
happen if no SM sessions
It could be related to the 13.x FPGA memory controller bug, but I
haven't seen this specific problem on dozens of APs. I definitely know
the memory bug when I see it because stupid things start happening and
the AP has to be rebooted. But the AP becoming completely unresponsive
while the ethernet statistics all look fine is not one of them.
Anything is possible though.
If it happens again even on 14.1.2, I would try to bounce the ethernet
link and see if that does anything. I have seen a lot of that
especially with MikroTik + Canopy. Fairly frequent with P9 and P10 FSK
APs. Chuck's surge suppressors seem to add to the problem, but I can
live with that.
Also, I know that I'm getting about 20 volts at the radios on a couple
clusters that are on ~300 feet of cable, SyncInjector fed by a 24v
regulated power supply with the pot set at 25 volts (due to UBNT
radios on shorter runs). The 450 APs seem to handle it fine.
On 7/6/2016 8:15 PM, Rhys Cuff (Latrobe I.T) wrote:
I’d also make sure you have enough power getting up the cable to
drive it.
*From:*Af [mailto:af-boun...@afmug.com] *On Behalf Of *Ken Hohhof
*Sent:* Thursday, July 7, 2016 9:34 AM
*To:* af@afmug.com
*Subject:* Re: [AFMUG] 450 AP intermittently nonresponsive,doesn't
happen if no SM sessions
OK, I just upgraded the AP to 14.1.2 and so far, so good. SMs next.
*From:*Sean Heskett <mailto:af...@zirkel.us>
*Sent:*Wednesday, July 06, 2016 5:08 PM
*To:*af@afmug.com <mailto:af@afmug.com>
*Subject:*Re: [AFMUG] 450 AP intermittently nonresponsive, doesn't
happen if no SM sessions
i would upgrade the AP and all SMs to 14.1.2 (it's a very stable
release)
if it exhibits these issues once SMs start to register are you sure
that you are not somehow creating a network loop through an SM, or
some client is launching a DDoS and the subject of a DDoS attack?
On Wed, Jul 6, 2016 at 3:51 PM, Ken Hohhof <af...@kwisp.com> wrote:
Does this sound like any kind of a known issue?
I have a 450 AP that has been in service for about a year that has
started intermittently becoming nonresponsive from the Ethernet side
(can't access GUI, doesn't pass traffic). I thought Ethernet
problem, but neither the AP nor the switch shows any errors or
events. It is more like the CPU is going to sleep or something, but
the Ethernet chip is still active. I don't see anything in the Event
Log though.
We missed applying the Lite to Full license key on this AP and I
thought maybe that was the problem since it was at 10 SMs, but I
applied the license key and still see the problem.
The weird thing is, if I set the Freq to None, or set the color code
to something we don't use, the AP doesn't seem to exhibit the
problem. Only once SMs start registering.
I'm thinking it's maybe a power starvation issue, that the AP uses
more power when actively talking to SMs, and maybe it's not getting
enough voltage.
But I also see the firmware is still on 13.2.1.3, and I see Cambium
finally released 14.1.2 official. I am hesitant to upgrade the
firmware though, unless there is some reason to believe what I am
seeing is a firmware bug. Otherwise I am just adding to the confusion.
