У меня открыты заявки на поддержку у Ubiquiti и Meross по этому поводу, но мне не удалось сдвинуться с места, поэтому решил поделиться своими наблюдениями здесь — вдруг кто-то тоже сталкивается с похожими проблемами. У меня дома стоят два AP: UAP-AC-Lite и UAP-AC-LR. После обновления до версии 6.6.55 у обоих иногда возникают проблемы, но на UAP-AC-Lite это происходит намного чаще. Обычно разрывы соединения случаются через несколько часов после перезагрузки у UAP-AC-Lite, а на UAP-AC-LR всё нормально работает неделями, пока устройства Meross не сбрасываются. Если появляются проблемы, помогает только перезагрузка AP. Иногда устройства сами переподключаются, но стабильности нет, и я вижу много таймаутов пинга.
Проблемы возникают с Meross-устройствами, которые работают с Homekit, и только с некоторыми из них. Другие Meross-устройства на том же SSID и AP работают нормально. У меня настроен отдельный VLAN для IoT-устройств с SSID, который вещает только на 2.4GHz, и эти устройства подключены к нему.
Устройства, с которыми у меня проблемы:
MSG200
MSS550x
MSS510x
Интересно, что у меня есть несколько MSS510xr, и они продолжают работать без проблем, в то время как MSS510x перестают работать. В службе поддержки Meross сказали, что все проблемные устройства используют один и тот же чипсет.
Я сделал тест: пингу на каждое проблемное устройство и пару других на том же SSID и AP в качестве контроля, включил логирование на AP, чтобы видеть, когда начинаются сбои. И вижу, что как только у Meross-устройств появляются таймауты пинга, в логе AP появляется такое сообщение:
UAP-AC-Lite-6.6.55+15189: kernel: [ 777.359582] ar9300_handle_radar_bb_panic: BB status=0x04008009 rifs=1 - disable
UAP-AC-Lite-6.6.55+15189: kernel: [ 777.359617] ar9300_abort_tx_dma[937]: ar9300_stop_dma_receive failed
UAP-AC-Lite-6.6.55+15189: kernel: [ 777.359910] ar9300_reset[5888]: ar9300_stop_dma_receive failed
После этого приходится перезагружать AP, чтобы устройства Meross снова заработали.
Я поставил ноутбук рядом с AP в режиме мониторинга на канале 11 (тот же 2.4GHz канал, что и у AP) и захватывал весь трафик. Зафиксировал момент, когда в логе AP появляются эти сообщения, а Meross-устройства перестают отвечать на пинг.
В записи видно, что пинги до проблемы проходят успешно. После появления этой строки в логе приходит кадр с пинг-запросом от AP к устройству, и оно его подтверждает. Затем идут повторяющиеся ответы от устройства к AP, но AP их не подтверждает, и ответ не приходит к пингу.
Похоже, что что-то происходит с AP, из-за чего он перестаёт видеть трафик от Meross-устройств после появления этой ошибки в логе. Иногда AP подтверждает кадр от устройства, но это очень редко, и устройству приходится слать много ответов, прежде чем один будет принят.
Я живу рядом с аэропортом, так что возможно AP действительно ловит какие-то сигналы погодного радара. Но у меня на AP не выбраны DFS-каналы для 5GHz, и весь этот трафик идёт на 2.4GHz. Единственное, что помогает стабильно держать эти устройства онлайн — откат прошивки UAP-AC-Lite до версии 4.3.28.
Кому-то ещё у кого проблемы с устройствами Meross: интересно, видите ли вы подобные строки в логах AP перед тем, как начинаются сбои?
Проблемы возникают с Meross-устройствами, которые работают с Homekit, и только с некоторыми из них. Другие Meross-устройства на том же SSID и AP работают нормально. У меня настроен отдельный VLAN для IoT-устройств с SSID, который вещает только на 2.4GHz, и эти устройства подключены к нему.
Устройства, с которыми у меня проблемы:
MSG200
MSS550x
MSS510x
Интересно, что у меня есть несколько MSS510xr, и они продолжают работать без проблем, в то время как MSS510x перестают работать. В службе поддержки Meross сказали, что все проблемные устройства используют один и тот же чипсет.
Я сделал тест: пингу на каждое проблемное устройство и пару других на том же SSID и AP в качестве контроля, включил логирование на AP, чтобы видеть, когда начинаются сбои. И вижу, что как только у Meross-устройств появляются таймауты пинга, в логе AP появляется такое сообщение:
UAP-AC-Lite-6.6.55+15189: kernel: [ 777.359582] ar9300_handle_radar_bb_panic: BB status=0x04008009 rifs=1 - disable
UAP-AC-Lite-6.6.55+15189: kernel: [ 777.359617] ar9300_abort_tx_dma[937]: ar9300_stop_dma_receive failed
UAP-AC-Lite-6.6.55+15189: kernel: [ 777.359910] ar9300_reset[5888]: ar9300_stop_dma_receive failed
После этого приходится перезагружать AP, чтобы устройства Meross снова заработали.
Я поставил ноутбук рядом с AP в режиме мониторинга на канале 11 (тот же 2.4GHz канал, что и у AP) и захватывал весь трафик. Зафиксировал момент, когда в логе AP появляются эти сообщения, а Meross-устройства перестают отвечать на пинг.
В записи видно, что пинги до проблемы проходят успешно. После появления этой строки в логе приходит кадр с пинг-запросом от AP к устройству, и оно его подтверждает. Затем идут повторяющиеся ответы от устройства к AP, но AP их не подтверждает, и ответ не приходит к пингу.
Похоже, что что-то происходит с AP, из-за чего он перестаёт видеть трафик от Meross-устройств после появления этой ошибки в логе. Иногда AP подтверждает кадр от устройства, но это очень редко, и устройству приходится слать много ответов, прежде чем один будет принят.
Я живу рядом с аэропортом, так что возможно AP действительно ловит какие-то сигналы погодного радара. Но у меня на AP не выбраны DFS-каналы для 5GHz, и весь этот трафик идёт на 2.4GHz. Единственное, что помогает стабильно держать эти устройства онлайн — откат прошивки UAP-AC-Lite до версии 4.3.28.
Кому-то ещё у кого проблемы с устройствами Meross: интересно, видите ли вы подобные строки в логах AP перед тем, как начинаются сбои?