I would expect SSH to get hit worse than telnet. From: Steve D Sent: Wednesday, March 11, 2015 12:04 AM To: af Subject: Re: [AFMUG] SM crashes are getting really old - enough with thedeadbeef already
Can't speak for the ePmp because we have none, (and I don't know if 450 is afflicted because ours is managed in private network only) but FSK and public IP do not mix unless you set the ACL to your NOC or block telnet at head of your network. Script kiddies just hammer telnet trying to break in and the FSK don't handle it well and just stack dump and reboot, typically on a ten minute basis or thereabouts. Firmware version doesn't matter. I never saw the wireshark dump from the guys troubleshooting it, but I was told the telnet requests hitting the things were staggering. The next beta for the 450's has a no telnet, ssh only option if I recall. Whether that definitively fixes the problem or not though is yet to be seen - not holding our breath for it to trickle to FSK anyway. I don't have any event logs handy to compare, and it's the only thing similar to Mark's problem I've seen that has "recently" started causing radios to do this for us. I dunno, maybe it's a 13.2.1 thing too. /shrug -Steve D On Tue, Mar 10, 2015 at 8:15 PM, John Woodfield <[email protected]> wrote: Like this one? http://208.74.35.70/ John Woodfield, President Delmarva WiFi Inc. 410-870-WiFi -----Original Message----- From: "Steve D" <[email protected]> Sent: Tuesday, March 10, 2015 10:43pm To: "af" <[email protected]> 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" <[email protected]> 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 Sent: Tuesday, March 10, 2015 8:26 PM To: [email protected] 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 [email protected] 419.837.5015 x 1021
