У меня довольно крупное развертывание UniFi (в данный момент 42 точки доступа, и время от времени подключаются ещё), в основном UAP-AC-Pro (2 UAP IW и 1 AC-LR, остальные — AC-Pro). Как это иногда бывало в прошлом с некоторыми комбинациями ПО (и однажды, когда mongo начал «глючить» из-за неудачного эксперимента с использованием флеш-карты на cloudkey), часть точек доступа, как кажется случайно, снова уходит в состояние «lost heartbeat» и периодически «disconnected». Скриншот в конце поста. Пока что 2 IW и 1 LR вроде не затронуты, но это может быть из-за маленькой выборки.

Connectivity monitor отключён. L2 discovery тоже отключён (они в любом случае не в одной подсети с контроллером). Поддерживается L3 adoption через DNS и option 43 DHCP.

Общий симптом: при подключении по SSH к проблемным устройствам (тем, что в статусе disconnected) команда «info» ничего не выводит (а так быть не должно). Принудительный ребут с CLI временно «реанимирует» точку, но это очень неудобно и делать приходится слишком часто, чтобы это было приемлемо.

Логи сообщений (как я видел в прошлых случаях с этим багом на других версиях прошивки и ПО контроллера) часто ругаются на невозможность подключения к mcad:  
Oct 27 08:26:11 kirkby-top-left daemon.info init: starting pid 29427, tty '/dev/null': '/bin/mca-monitor'  
Oct 27 08:26:12 kirkby-top-left daemon.info init: process '/bin/reset-handler' (pid 29424) exited. Scheduling for restart.  
Oct 27 08:26:12 kirkby-top-left daemon.info init: starting pid 29429, tty '/dev/null': '/bin/reset-handler'  
Oct 27 08:26:21 kirkby-top-left user.err syslog: mca-client.service(): Failed sending request to '/tmp/.mcad' - 'Connection refused'  
Oct 27 08:26:21 kirkby-top-left user.info syslog: mca-monitor.do_monitor(): mcad.checkin is 326 ago (max=200)  
Oct 27 08:26:21 kirkby-top-left user.notice syswrapper: kill-mcad. reason: mcad not responding  
Oct 27 08:26:21 kirkby-top-left daemon.info init: process '/bin/mca-monitor' (pid 29427) exited. Scheduling for restart.  
Oct 27 08:26:21 kirkby-top-left daemon.info init: starting pid 29437, tty '/dev/null': '/bin/mca-monitor'  
Oct 27 08:26:22 kirkby-top-left daemon.info init: process '/bin/reset-handler' (pid 29429) exited. Scheduling for restart.  
Oct 27 08:26:22 kirkby-top-left daemon.info init: starting pid 29439, tty '/dev/null': '/bin/reset-handler'

На AP с «потерей пульса» проблема, кажется, тоже связана с MCAD:  
Oct 27 08:30:23 evv-stable daemon.info init: process '/bin/mca-monitor' (pid 29302) exited. Scheduling for restart.  
Oct 27 08:30:23 evv-stable daemon.info init: starting pid 29303, tty '/dev/null': '/bin/reset-handler'  
Oct 27 08:30:23 evv-stable daemon.info init: starting pid 29304, tty '/dev/null': '/bin/mcad'  
Oct 27 08:30:23 evv-stable daemon.info init: starting pid 29305, tty '/dev/null': '/bin/mca-monitor'  
Oct 27 08:30:23 evv-stable user.info syslog: ace_reporter.reporter_reload_config(): authkey=2620C890516513D63EF0860D36C1D4FD  
Oct 27 08:30:23 evv-stable user.info syslog: ace_reporter.reporter_reload(): [MCAD] Self-Run Beaconing enabled !
Oct 27 08:30:23 evv-stable user.info syslog: ace_reporter.reporter_reload(): [MCAD] Discovery Response disbled !
Oct 27 08:30:23 evv-stable user.info syslog: ace_reporter.reporter_set_managed(): [STATE] enter MANAGED

Версия 3.7.17.5220 казалась более стабильной, хотя приходилось время от времени перезагружать точки для поддержания работоспособности.

Для диагностики я перешёл с аппаратного cloud key первой версии, который явно не для такого объёма даже в небольшой компании, на платформу контроллера на базе Ubuntu. Переход на более мощную платформу, увы, не помог.

Я всерьёз подумываю откатиться на прошивки AP 3.7.17 или 3.7.14 — они не были идеальными, но 3.7.21, несмотря на обещанные исправления, кажется (намного) хуже.