WS-6-MINI Dropping UBNT Powerbeam

[DolphinComms]

Hello,
We are experiencing a strange issue with our WS-6-Mini. It is setup like this:

Switch
Port 1 - Nothing Plugged In
Port 2 - Nothing Plugged In
Port 3 - Providing PoE to a PowerBeam AC M5 - Issue with pair number 2 - this will be fixed: Provides the inbound internet connection
Port 4 - Providing PoE to a Rocket AC Prism - No problems
Port 5 - Providing PoE tp PowerBeam AC M5 - This is the problem
Port 6 - Nothing Plugged In

Randomly (although daily) The device plugged into Port 5 becomes unreachable and the link goes down to another WS-6-Mini (no problems) and we lose that of the network.

Port Bounce on Port 5 resolves the problem, until the next time. I can't see anything obvious in the Log.

The log mentions that Port 5 goes up and down for approximately 6 repitions.

The log below is from the PowerBeam


Nov 24 09:08:38 init: Run: /bin/lighttpd -D -f /etc/lighttpd.conf
Nov 24 09:08:38 init: starting pid 647, tty '/dev/null': '/bin/lighttpd -D -f /etc/lighttpd.conf'
Nov 24 09:08:38 wireless: ath0 Set Mode:Master
Nov 24 09:08:38 dropbear[646]: Not backgrounding
Nov 24 09:08:38 init: Run: /bin/ubntspecd -t -a -i wifi1 -j airview1
Nov 24 09:08:38 init: starting pid 648, tty '/dev/null': '/bin/ubntspecd -t -a -i wifi1 -j airview1'
Nov 24 09:08:39 init: Run: /bin/ulogger
Nov 24 09:08:39 init: starting pid 649, tty '/dev/null': '/bin/ulogger'
Nov 24 09:08:39 init: Run: /sbin/getty -L ttyS0 115200 vt100
Nov 24 09:08:39 wireless: ath0 Channel Availability Check started on freq 5745
Nov 24 09:08:43 FileSystem: End check.
Nov 24 09:08:47 zcip: config br0 169.254.137.129
Nov 24 09:09:46 wireless: ath0 Channel Availability Check stopped on freq 5745
Nov 24 09:10:43 wireless: ath0 Authenticated Station 44:d9:e7:7e:0a:a9 (Successful)
Nov 24 09:10:43 wireless: ath0 Registered node:44:D9:E7:7E:0A:A9
Nov 24 09:10:43 hostapd: ath0: STA 44:d9:e7:7e:0a:a9 IEEE 802.11: associated
Nov 24 09:10:43 hostapd: ath0: STA 44:d9:e7:7e:0a:a9 WPA: pairwise key handshake completed (RSN)
Nov 24 14:10:31 init: reloading /etc/inittab
Nov 24 14:10:31 system: Stop
Nov 24 14:10:31 dropbear[646]: Early exit: Terminated by signal
Nov 24 14:10:32 init: process '/sbin/ntpclient -n -s -c 0 -l -h 0.uk.pool.ntp.org' (pid 645) exited. Scheduling for restart.
Nov 24 14:10:32 init: process '/bin/dropbear -F -d /etc/persistent/dropbear_dss_host_key -r /etc/persistent/dropbear_rsa_host_key -p 22 ' (pid 646)
Nov 24 14:10:32 init: process '/bin/ubntspecd -t -a -i wifi1 -j airview1' (pid 648) exited. Scheduling for restart.
Nov 24 14:10:32 init: process '/bin/ulogger' (pid 649) exited. Scheduling for restart.
Nov 24 14:10:33 init: process '/bin/hostapd /etc/aaa1.cfg' (pid 641) exited. Scheduling for restart.
Nov 24 14:10:33 init: process '/bin/lighttpd -D -f /etc/lighttpd.conf' (pid 647) exited. Scheduling for restart.
Nov 24 14:10:34 syslogd exiting
Nov 24 14:10:56 system: Start
Nov 24 14:10:56 syslogd started: BusyBox v1.19.4
Nov 24 14:10:56 init: starting pid 19623, tty '/dev/null': '/bin/ulogger'
Nov 24 14:10:57 wireless: ath0 Set Mode:Master
Nov 24 14:10:57 dropbear[19620]: Not backgrounding
Nov 24 14:10:57 wireless: ath0 Channel Availability Check started on freq 5745
Nov 24 14:11:05 zcip: config br0 169.254.137.129
Nov 24 14:12:04 wireless: ath0 Channel Availability Check stopped on freq 5745
Nov 24 14:12:31 wireless: ath0 Authenticated Station 44:d9:e7:7e:0a:a9 (Successful)
Nov 24 14:12:31 wireless: ath0 Registered node:44:D9:E7:7E:0A:A9
Nov 24 14:12:31 hostapd: ath0: STA 44:d9:e7:7e:0a:a9 IEEE 802.11: associated
Nov 24 14:12:31 hostapd: ath0: STA 44:d9:e7:7e:0a:a9 WPA: pairwise key handshake completed (RSN)
Any help would be gratefully appreciated.

[sirhc]

I would guess bad cabling or a bad radio???

To verify it is not the switch port simply move cable from port 5 to port 6

[DolphinComms]

I moved the cable as suggested, the connection seems more stable however we are still receiving the following messages, granted one was us Port Bouncing.

Nov 24 15:22:03 Port: link state changed to 'up' (100M-F) on port 2

Nov 24 15:33:17 Port: link state changed to 'down' on port 4

Nov 24 15:33:33 Port: link state changed to 'up' (100M-F) on port 4

Nov 24 16:44:06 Port: link state changed to 'down' on port 6

Nov 24 16:44:08 Port: link state changed to 'up' (1G) on port 6

Nov 24 16:44:13 Port: link state changed to 'down' on port 6

Nov 24 16:44:15 Port: link state changed to 'up' (100M-F) on port 6

Nov 24 16:44:38 Port: link state changed to 'down' on port 6

Nov 24 16:44:41 Port: link state changed to 'up' (1G) on port 6

Nov 24 16:44:42 Port: link state changed to 'down' on port 6

Nov 24 16:44:44 Port: link state changed to 'up' (1G) on port 6

Nov 24 17:33:56 Port: link state changed to 'down' on port 6

Nov 24 17:33:59 Port: link state changed to 'up' (1G) on port 6

Nov 24 17:34:03 Port: link state changed to 'down' on port 6

Nov 24 17:34:06 Port: link state changed to 'up' (100M-F) on port 6

Nov 24 17:34:29 Port: link state changed to 'down' on port 6

Nov 24 17:34:31 Port: link state changed to 'up' (1G) on port 6

Nov 24 17:34:32 Port: link state changed to 'down' on port 6

Nov 24 17:34:35 Port: link state changed to 'up' (1G) on port 6

Nov 24 21:49:55 Port: link state changed to 'down' on port 6

Nov 24 21:49:57 Port: link state changed to 'up' (1G) on port 6

Nov 24 21:50:02 Port: link state changed to 'down' on port 6

Nov 24 21:50:04 Port: link state changed to 'up' (100M-F) on port 6

Nov 24 21:50:27 Port: link state changed to 'down' on port 6

Nov 24 21:50:29 Port: link state changed to 'up' (1G) on port 6

Nov 24 21:50:31 Port: link state changed to 'down' on port 6

Nov 24 21:50:33 Port: link state changed to 'up' (1G) on port 6

Nov 25 11:40:33 Port: link state changed to 'down' on port 6

Nov 25 11:40:36 Port: link state changed to 'up' (1G) on port 6

Nov 25 11:40:40 Port: link state changed to 'down' on port 6

Nov 25 11:40:42 Port: link state changed to 'up' (100M-F) on port 6

Nov 25 11:41:06 Port: link state changed to 'down' on port 6

Nov 25 11:41:08 Port: link state changed to 'up' (1G) on port 6

Nov 25 11:41:09 Port: link state changed to 'down' on port 6

Nov 25 11:41:12 Port: link state changed to 'up' (1G) on port 6

[sirhc]

So it has to be one of the following:
Bad cabling or End
Bad Radio
Bad switch port or bad switch

So you moved cable from port 5 to 6 and issue remains so not the switch port.
Can be bad radio
Can be bad cable or End

I assume you have verified the radio is not rebooting by checking radio uptime?
If the radio is not rebooting that means the radio is not losing power just the Ethernet communications is dropping.
I assume you do not have the port speed forced to a speed and that all port speeds are set to Auto.

[DolphinComms]

I have run a cable test on from the switch and it is reporting the same length of cable and no clear issues

There are no Errors on the Port Detail page

This is is the status of the radio.

DEVICE
Device Model: PowerBeam 5AC 300
Device Name: 1002M
FCC ID: SWX-NBEM5AC
Version: v7.2.4( WA)
Date: ‎25‎/‎11‎/‎2016‎ ‎16‎:‎30‎:‎25
Network Mode: Bridge
Memory: 65%
CPU: 10%
LAN Speed: 1000Mbps-Full
Cable Length: < 20 m
Cable SNR: +30 dB
Isolated Capacity TX / RX: 177 Mbps / 168 Mbps
airTime: 0.1%
Uptime: 04:49:56
TX/RX Bytes: 255M / 19.3M
WIRELESS
Wireless Mode: Access Point PTP
SSID: 1002
WLAN0 MAC: 44:D9:E7:72:89:81
Security: WPA2
Distance: 1.0 miles (1.7 km)
TX/RX Bytes: 255M / 19.3M
TX Power: 6 dBm
Frequency: 5745 [5735 - 5775] MHz (DFS)
Channel Width: 40 MHz
RX Signal: -69 dBm
Noise Floor: -89 dBm
RX Chain 0 / 1: -72 dBm / -73 dBm
TX Rate: 6x (64QAM 2x2)
RX Rate: 6x (64QAM 2x2)
WIRELESS REMOTE DETAILS
Device Model: PowerBeam 5AC 300
Device Name: 1002S
Version: v7.2.4
MAC Address: 44:D9:E7:7E:0A:A9
Last IP: 192.168.1.64
RX Signal: -69 dBm
RX Chain 0 / 1: -73 dBm / -72 dBm
Noise Floor: -91 dBm
Latency: 0 ms
TX Power: 6 dBm
Connection Time: 04:47:35
Isolated Capacity TX / RX: 168 Mbps / 177 Mbps
airTime TX/RX: 0.0 / 0.1
I am open to the idea that the radio could be faulty as when the connection does go down, i can't see the radio from the LAN.

[sirhc]

The Cable Diagnostics is a crude tool not a multi thousand dollar Fluke tester and if the cable wire or end is bad in such as way that the wire moves and drops a connection on a pin or a wire it could drop the link, this is the wiggle test.

Make sure neither the radio nor the switch is hard coded speed/duplex but set to AUTO.

If you replace the radio and the problem still exists you can replace the switch and if the problem still exists you are down to the cable again as since there are 25,000+ switches out there powering tens of thousands of UBNT radios it is not a design issue so you would be back to an intermittent bad cable or end or interference around 100 Mhz interfering with Ethernet communications?

Ethernet cable running parallel to AC power wires can cause this as well as FM transmissions.

[DolphinComms]

I will replace the cable as the next the next step then the radio.
I did enable Flow Control on the radio and both ends were on Auto for Link Speed and Duplex.

I will update you on the progress in the week.

[DolphinComms]

Apologies for the delay, I replaced the cable with a new one. Tested and passed with a network tester before installation.

The issue remains, I believe it is a radio problem as today i upgraded to v8 firmware and it reported a crash. I have a new radio on its way, so i will replace it next week and let you know.

[sirhc]

Thanks for the update, let us know.