Strange Disconnects on Station side of PTP Link

I have been having a problem with my PTP link randomly dropping connection on the ethernet side of the Station. The station is plugged into a cisco catalyst 3550 switch. My switch isn't showing any interface resets. My Station isn't dropping the RF. I have both sending debug loggs to my syslog server. Neither the station or the switch are reporting anything during the time of loss of connectivity.

The only thing I am getting besides timeticks is 

snmpd[25203] handle_Camb_ConfMan() cmd: json-config get wireless @wifi-iface[0] primary_freq


Nov  6 04:44:01 Cambium-Device snmpd Watchdog:Abnormal SNMPd stop occured, restarting...
Nov  6 04:44:01 Cambium-Device snmpd[25514] Private community set to: tpprizmsky
Nov  6 04:44:02 Cambium-Device snmpd[25514] ETSI Bit is <0>
Nov  6 04:44:02 Cambium-Device snmpd[25524] Board SKU updated, sku = 1, res = 0
Nov  6 04:44:02 Cambium-Device snmpd[25524] copied 48, 'U-Boot 9344_PX 1.1.4.a (Nov 8 2013 - 23:54:33)'
Nov  6 04:44:02 Cambium-Device snmpd[25524] DFS status: N/A
Nov  6 04:44:08 Cambium-Device snmpd[25514] /etc/snmp/snmpd.conf: line 16: Warning: Unknown token: exec.
Nov  6 04:44:08 Cambium-Device snmpd[25526] stats_server_thread started...
Nov  6 04:44:08 Cambium-Device snmpd[25514] NET-SNMP version

 Nothing other than timeticks occured during the outtages according to the syslog server.

Any ideas?

What are you seeing as far as the dropping ethernet?  Is it going no link, or are you dropping packets through a continuous ping?  I'm assuming you aren't using a DFS channel, and if it's a PTP are you using flexible and therefor no sync being used?  I'm not sure exactly what the issue may be that you're seeing but just thought I'd throw those couple of questions out there.  Could even be something as simple as one pair on your CAT5 is compromised, but it's not causing the radio to power cycle.

I haven't been able to log in to the unit fast enough to see the status of the ethernet connection.  This problem seems to happen mostly in the early morning hours and only lasts about a minute. U monitor the radio with PRTG and what I'm seeing is the the ethernet interface saying down. 

The link is set to PTP with no DFS channels, no sync, and using 75/25.

Cabling is possible, but not likely. New install with new cable, and we have already tested replaced and tested again the connectors. The cable is double shielded gel filled with a drainwire. We are using the 600SSH surge arrestor for the surge protection.

Have you tried to force the port speed on the device it's plugged into?  600SS are 10/100 and if you're using a GIG-E AP then maybe you're seeing a port speed issue?  I've also had a brand new box of cable just be bad before, where both ends test fine but you plug it into a 320 AP and it gives a fault light on the CMM4.  Take that cable out, and the CMM4 and 320 AP operate normal.  Just tossing around ideas for you.

we have face same type of problem. in our case when we avoide Lan speed Auto nigotiable and put the Lan speen manually 10 base FD. then we solve the issue. you can try the same method. 

I already have the speed and duplex manually set at 100/full on the AP and Station and on the ports they are plugged into on the switches.  We will replace the cable and see what happens. Thanks


From the screen shot it seems like a SNMP daemon crash which would come across as an unresponsive UI on the radio.

Any chance you could give us remote access when this happens next and we can get into it via SSH and see if we can figure something out - 

Since the logs show SNMPd crash, lets go after that problem first.



did you get remote access?  If so, what was the solution?

I'm getting the SNMPd crashes too on v 2.2.



Hi Mac, 

By SNMP crashes, are you referring to seeing the following message in syslog?

Nov  6 04:44:01 Cambium-Device snmpd Watchdog:Abnormal SNMPd stop occured, restarting...

If so, this is not the cause of what Gary is seeing. This is a different issue and will have very little impact to normal operation. The SNMP process is a low priority process and if there is a lot of activity on the radio (both user and management traffic), the SNMP process on occasion, gets starved and crashes. However the process restarts itself in under 0.5 seconds. So unless you are doing rapid and continous SNMP polling on the radio to collect data, you will not see any impact due to this. Gary's issue of the ethernet link dropping on his SM is not related to the SNMP process restarting. 



yes, same message.  It's the only messages I'm getting at the moment, so it doesn't appear to be a problem from your info.

I would say though that it sounds like device resources are very tight, tighter than one would expect in a robust design