The SM's all have a private IP for management but obviously a public IP
for the WAN side of the NAT. It's the standard setup we have used for at
least 8 years if not longer.
There is a known bug where Telnet will cause the 430/450 AP's (and
possibly the SM's) to reboot when management is on a public IP. We were
able to come up with a pcap showing that happening and I believe Cambium
was able to reproduce it.
How frequent are the SM crashes? Hard to say for sure but I think we
are seeing it sporadically on about .1% of the customer radios. The
ones that do it either do it fairly repeatably on a couple hour cycle,
or sometimes every couple of minutes for a hour or two. I'm pretty
sure it's something coming from the customer side but I have not been
able to figure out what.
This is a fairly typical one:
The red hash at the top is session restart, the purple at the bottom is
the radio rebooting. Why it was crazy on the 4th? Got me.
Mark
On 3/11/15 6:34 AM, Tushar Patel wrote:
We recently did truck roll thinking there is something wrong with one
SM. I was not aware of the sm crashes.
How wide spread is this? Does it happen on NAT and on bridge SM?
Tushar
On Mar 10, 2015, at 10:15 PM, John Woodfield <john.woodfi...@jwcn.biz
<mailto:john.woodfi...@jwcn.biz>> wrote:
Like this one?
http://208.74.35.70/
John Woodfield, President
Delmarva WiFi Inc.
410-870-WiFi
-----Original Message-----
From: "Steve D" <bigd...@gmail.com <mailto:bigd...@gmail.com>>
Sent: Tuesday, March 10, 2015 10:43pm
To: "af" <af@afmug.com <mailto:af@afmug.com>>
Subject: Re: [AFMUG] SM crashes are getting really old - enough with
thedeadbeef already
Publicly accessible IP on the radio?
On Mar 10, 2015 6:50 PM, "Mark Radabaugh" <m...@amplex.net
<mailto:m...@amplex.net>> wrote:
Probably a good guess. Seems to have arrived after 13.1.3.
Affects some customers pretty regularly, others not at all.
Given that we use NAT for nearly everyone it accounts for a fair
number of customers.
Mark
On 3/10/15 9:35 PM, Ken Hohhof wrote:
I don’t know how to read the stack dumps but does “Current
context Task: NAPT” mean this only occurs when using NAT in
the SM?
*From:* Mark Radabaugh <mailto:m...@amplex.net>
*Sent:* Tuesday, March 10, 2015 8:26 PM
*To:* af@afmug.com <mailto:af@afmug.com>
*Subject:* [AFMUG] SM crashes are getting really old - enough
with thedeadbeef already
Dear Cambium,
Can we please get this SM issue fixed? It's getting really old.
System Reset Exception -- Watchdog Reset Cur ExtInt 0 Max
ExtInt 0 Cur DecInt 0 Max DecInt 0 Cur Sync 0 Max Sync 0 Cur
LED 2 Max LED 1 Cur WDOG 0 Max WDOG 1 Cur EthXcvr 0 Max
EthXcvr 1 Cur FEC 0 Max FEC 0 Cur FPGA 18 Max FPGA 1663 Cur
FrmLoc 0 Max FrmLoc 0 Cur WatchDog 33 Max WatchDog 33
RTMLogStats 0 AAState 0
Software Version : CANOPY 13.2.1 SM-DES
Board Type : P11
Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module -
0a-00-3e-a0-4c-a7
FPGA Version : 081514
FPGA Features : DES, Sched;
03/10/2015 : 15:28:31 EDT : :Timezone set to EDT;
03/10/2015 : 15:32:57 EDT : :Delete Public Entry Protocol 17
Failed
03/10/2015 : 15:32:57 EDT : :Delete Private Entry Protocol 17
Failed
03/10/2015 : 15:54:39 EDT : :Tsl Free list empty. Entries 0
03/10/2015 : 15:54:39 EDT : :FatalError()
03/10/2015 : 15:54:39 EDT :
Stack Dump information:
Current context Task: NAPT
Current Stack: 2%
Max Stack: 26%
r0: 00000000 r1: deadbeef r2: 00000002 r3: 00000000
r4: 007930a4 r5: 00000000 r6: 00000000 r7: fffffffe
r8: 00bc3380 r9: 00000006 r10: 00000000 r11: 00000001
r12: 00bf1380 r13: 00000000 r14: 96904e99 r15: 08001b3c
r16: 00000000 r17: 0236080e r18: 02360800 r19: 45acd86f
r20: 00bc3380 r21: 02360822 r22: 02360822 r23: 00000000
r24: 009eb434 r25: deadbeef r26: 004f2370 r27: 009ee000
r28: 00000000 r29: 000981e0 r30: deadbeef r31: 00029a64
Task Stack Dump:
0x009edf18: 0000001d 000981e0 0000001e deadbeef
Mark
-- Mark Radabaugh Amplex m...@amplex.net <mailto:m...@amplex.net>
419.837.5015 x 1021 <tel:419.837.5015%20x%201021>
--
Mark Radabaugh
Amplex
m...@amplex.net 419.837.5015 x 1021
