Привет, Эрик, я, пожалуй, с тобой соглашусь и действительно проверил кучу всего... порты и прочее. Но всё равно прихожу к одному и тому же выводу — старый точка доступа работает без сбоев. Я только что сравнил её на одной сети и с тем же коммутатором вместе с новой. M

Ах, если ssh работает каждый раз, а инструменты обнаружения — нет, убедитесь, что на ваших коммутаторах не настроены какие-то broadcast storm фильтры, которые могут блокировать пакеты «Я здесь, возьмите меня под управление», которые посылают неуправляемые точки доступа, и именно эти пакеты «слушают» инструменты обнаружения. По крайней мере сейчас инструменты обнаружения не активно «ищут» — они пассивно слушают широковещательные сообщения «Я здесь, возьмите меня». Надеюсь, это поможет в вашей диагностике!

Йо, похоже, проблема либо с кабелем, либо с плохим портом на коммутаторе, а может, и с плохим Ethernet-портом на точке доступа. DOA (дефектный при получении) бывает, так что меня бы это особо не удивило. Можешь попробовать другой коммутатор и патч-корды? Если подозрение падает на точку доступа, то @UBNT-Brandon наверняка заинтересуется, особенно если таких проблемных устройств несколько подряд.

Ты уверен, что эти «новые» AP неуправляемые? То есть, их сбросили к заводским настройкам? Инструмент для обнаружения не увидит их, если они уже были подключены к контроллеру.

Привет, Эрик, я согласен, что экспорт сайта — хорошая идея по разным причинам.

Говоря о моей ситуации, двежды я сталкивался с этой проблемой, и это было в тех случаях, когда клиент нам должен был деньги. В такой ситуации меня особо не волнует, что он будет делать дальше, мне просто хочется, чтобы всё завершилось чисто.

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

М

Привет, Эрик, спасибо за твой пост. Да, но если забыть устройство, оно сбросится к заводским настройкам и испортит сайт клиента. Даже если мы уже не работаем вместе, я бы не стал отключать их беспроводную сеть, предпочитаю оставить её работающей, но без подключения к нашему контроллеру.  
М

Привет, Коди, спасибо ещё раз за твой ответ и идеи. Я использую тот же рабочий компьютер, что и всегда, так что с файрволом проблем нет. Значит, ещё что-то фильтрует… исключать нельзя, но что именно — понятия не имею.

Так ты говоришь, что оригинальный Unifi discovery tool будет работать с новыми точками доступа «ac»? Что касается вариантов с DNS, эта идея, возможно, сработает для кого-то, это правда. Но у нас опыт показывает, что для каждого клиента нужно указывать свой URL для inform. Так мы можем отдельно закрыть соединение, если потребуется. Другого способа «отпустить» клиента и не давать ему подключаться к нашему контроллеру я не знаю.

С уважением, М

Привет, Коди, спасибо за ответ. Мы всегда настраиваем наши устройства в мастерской перед их установкой на объекте. Так нам намного проще и быстрее на месте – просто подключил и закрепил. Да, в этом случае, наверное, можно было бы зайти по SSH на устройства, но инструмент обнаружения сработал очень хорошо и запуск прошёл без проблем. Было бы обидно, если бы этот инструмент совсем убрали.

В итоге мне удалось запустить дополнение для Chrome. Через какое-то время в приложении Chrome появился дублирующий набор точек доступа. Тогда у меня получилось так: сначала показывался «ложный» набор с описанием «unknown» и без MAC-адреса, а потом дублирующий настоящий набор с MAC-адресами. Второй вариант позволял мне установить inform URL, но, честно говоря, работал он не совсем стабильно. Некоторые устройства приходилось настраивать по несколько раз — хотя они и отображались в контроллере и «усыновлялись», потом исчезали. После повторной настройки inform URL они активировались без повторного усыновления.

Какой инструмент нам вообще стоит использовать? Всё это кажется шагом назад. Почему мы не можем продолжить использовать discovery tool для UNIFI, как раньше? 🙁 Он был отличный.

Я заметил, что новые точки доступа поддерживают SSH из контроллера, но на удалённом объекте пока не пробовал. Если это работает, может, окажется полезным.

М