При переходе от одной точки доступа к другой таблица перенаправления MAC-адресов для WiFi-клиента должна маршрутизироваться через правильную точку доступа по её сетевому кабелю, чтобы коммутаторы на пути могли отправить кадр на порт, подключённый к этой точке. Обычно это происходит, когда клиент отправляет кадр со своего MAC-адреса. Если этот кадр направлен на конкретный MAC-адрес, он не обязательно попадёт на каждое устройство в сети, так как коммутаторы отправят его только на нужный кабель, если уже знают этот MAC-адрес назначения. Старая точка доступа может не получить обновлённый MAC-адрес и потенциально считать, что устройство с этим MAC всё ещё у неё. Эти записи в таблицах должны сбрасываться по тайм-ауту, но у многих устройств с большим аптаймом есть странные баги, когда размер таймеров не хватает битов для учёта длительных значений аптайма. Где-то какой-то коммутатор или точка доступа может неправильно обновлять эту таблицу. Вдобавок, если конечное устройство настроено на рандомизацию своего MAC-адреса, таблица ARP, сопоставляющая IP-адрес с MAC, тоже может вызвать проблему, но протоколы для предотвращения дублирования IP-адресов должны это допускать. Сложно сказать, у какого устройства проблема, но я бы предположил, что это UDM — к такому выводу вы и пришли. Однако я не уверен, как работают два разных коммутатора, подключённых к UDM, так как UDM всё равно должен обновлять, какой порт коммутатора обслуживает MAC-адрес, когда клиент переходит к точке доступа, подключённой к другому порту. Похоже, что всё подключено к отдельному коммутатору через один порт к UDM, когда система работает. Я пришёл к этому, потому что мой ноутбук на Windows столкнулся с той же проблемой прошлой ночью, но у меня не было никаких проблем с миграцией на Android-телефоне или iPad.

ок, прикрепил со второй попытки

обновление до последней версии AP EA ничего не изменило, думаю, пора переходить на udmpse

AP или udmpse?