I've only noticed this since upgrading to 2.6 on the AP and SM but it may have been going on before. At the same time the firmware was upgraded, the AP channel was changed as well - from a clean UN-II-1 channel to a noisier UN-II-3 channel. The channel change had to be made to add a temporary SM at ~13 miles and move a backhaul. Sector tilt isn't ideal for the SM's but that shouldn't be a factor here.
Overall stats look good, however this SM is dropping from the AP many times per day as shown in the log below:
Jan 16 10:57:15 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 11:12:21 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 12:11:24 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 12:57:15 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 13:33:19 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 13:38:14 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 13:38:49 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 14:11:46 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 14:50:51 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 14:51:25 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 15:10:03 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 15:10:24 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 15:39:36 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 17:11:29 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 17:37:29 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 18:52:25 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
Jan 16 22:51:32 hc-vdl-sw5C kernel: SM[00:04:56:cf:9b:9e] aid=8 disassociated. Reason: COMMUNICATION LOST
The only other SM that disconnects at any time other than AP reboots is the long-distance one. This doesn't surprise me as the shot is across a very noisy mountain top. The close-in one dropping though doesn't make sense.
I've run spectrum analysis from the AP and the affected SM and things look about the same on both sides for the channel in use. eDetect also doesn't see anything at all.
This wouldn't be an issue typically, but this specific customer runs a VOIP across the link and the disconnects are becoming too annoying to deal with. Any deeper diagnostic suggestions from Cambium folk?
that CPE has your poorest downlink quality. I would check the customers router channel. if they start to use it, and the link tanks thier own router is the problem. otherwise a quick visit to the customers home, put the unit in regular wifi mode, 20 mhz, scan for networks and you'll see the offending router and you can track it down, or the offending link else where.
you can also add a passive reflector if this is the integrated unit to help it deal with noise as well. if the customers router is making the link drop, a reflector may not resolve the problem.
The sub's router is 2.4 only. I agree it looks like local noise but many of the other subs see MUCH higher local noise. These aren't home connections, mostly business, and in a noisy part of town. All are Force 110 units. I've only deployed one integrated unit and it is ~75' from the tower.
Local noise could have changed, however, I can't yet rule that out. Local noise should also impact some of the other SM's though, due to topography.
the force 110 dishes are very focused, it very well can be local noise and be missed by the other force 110s you've got deployed. that also makes them good to use to dodge noise.
if edetect doesn't show anything, go onsite and put it in wifi mode, and check for an overlap from a router or other device. tilting the force 110 a little more skyward could get you enough of an SNR change to stop the disconnects if is a near by router if you've got some height to use to your advantage .
with the drop in link % relative to your other units, its extremely likely its local interference to that CPE
I was having the same issue. I would look at he wireless stats in the Ap and always see a few that had recently disconnected. Then i noticed that they were actually rebooting and only when using a decent amount of traffic. I also noticed they were all 00:04:56:cf:xx:xx Mac addresses. Just for the heck of it i but the new 2.6.1 RC1 firmware on it and have not had an issue since. This firmware was released for the cold weather issues we were having on our aps and ptps. We have been running them for a week now with no reboots.
Unfortunately in this instance the SM isn't rebooting, it currently has an uptime of ~14 days. I'm thinking that the local noise theory might hold the most weight and plann on running the specrum analyzer on the SM tomorrow for a few minutes to confirm.
My own SM at home reboots under load from time to time though, I'll give the beta firmware a try to see if it helps.
