Комментарии 14
Хорошо, когда большую часть нужной информации можно взять с контроллера, что сильно ускоряет диагностику.
Linux с приоритетом:
nmcli -f NAME,UUID,AUTOCONNECT,AUTOCONNECT-PRIORITY
Проверить доступность
...
- Внешний ip-адрес (8.8.8.8)
Неразумно. Такой пинг при неудаче не скажет почти ни о чём. Пинговать надо адрес самой точки доступа, причём как LAN, так и WAN адреса, и адрес дефолтного шлюза точки. Можно ещё заранее оттрассировать 2-3 ближайших узла (можно больше, вплоть до выхода от провайдера на магистраль) и пинговать также их.
А на 8.8.8.8 лучше натравливать tracert.
У точки может и не быть адреса, который будет виден пользователю и который можно попинговать "из воздуха". Даже так — по-хорошему, у точки такого адреса быть и не должно.
Такой пинг при неудаче не скажет почти ни о чём.
Согласен с тем, что сам по себе пинг восьмёрок не показателен. Но, например, если google.com не пингуется, а 8.8.8.8 пингуется - это нам о чём-то уже говорит.
Идея в том, чтобы собрать сразу всю диагностику из списка, а потом её комплексно изучать.
tracert (traceroute) там, кстати, тоже есть.
Но, например, если google.com не пингуется, а 8.8.8.8 пингуется - это нам о чём-то уже говорит.
Само по себе нет. Это может быть проблема DNS (на что покажет DNS probe). Это может быть проблема маршрута, обычно магистрального (на что укажет tracert). Плюс экзотика. А потому нет никакого смысла получать эту информацию, которая (в случае "собрать сразу всю диагностику из списка, а потом её комплексно изучать") будет гарантированно перекрыта и дополнена другими тестами, всё равно при анализе она не добавит ни бита дополнительных данных.
Вот сразу, до получения полной диагностики по всем тестам - да. Причём в случае проблемы на пинге важным будет то, какой тип отказа получен (no route to host, destination unreacheable или timeout expired и даже general failure - конкретный тип ошибки сразу отбрасывает часть возможных вариантов проблемы).
Забрал в закладки! С нетерпением жду статьи о разборе собранного материала.
У меня Xiaomi роутер недавно вообще не хотел подключаться ни в какую, и до заводских сбрасывал нифига не помогло.
Спасибо за статью. Очень жду следующую статью что делать и кто виноват.
Будет здорово, если в статье будут разобраны реальные примеры как логи в жизни помогли проблему решить. Я обычно с другой стороны (сетевой) на проблему смотрю, и теми же средствами контроллера пользуюсь, хотя да, порой бывают странности, когда какое-то устройство просто не подключается, к примеру, когда на сети 11r "adaptive" включен и контроллер ничего не знает о таком клиенте (потому что он в биконе одно видит, нет 11r а в accoc response видит что есть 11r и входит в ступор), а человек жалуется что к Wi-Fi вообще не подключается корпоративному, только к гостевому. Но тут, возможно, даже логи не нужны, чтобы понять что таким устройствам, нужно выключать 11r.
По-хорошему, наверно, в каждой компании где штат не маленький, должна быть своя вики, куда вносят все такие приключения с клиентскими устройствами. Админам бы было проще наверно в анализе тех же логов имея базу знаний.
Спасибо за "useful" статью, беру на вооружение! Приятно удивила генерация автоматического отчета netsh wlan show wlanreport, вся диагностическая информация клиента в одном месте. Единственное, у меня в винде почему-то проблема с кириллицей (если отдельно запускать в командной строке, таких проблем нет):
Как и написали уже 100 раз выше, я бы добавил в диагностику пару команд проверки data flow (винда):
tracert -d [IP]
pathping -n [IP]Чаще приходится работать с заявками типа "Нет Интернета", и эта информация будет полезна для исключения/подтверждения проблем на пути передачи трафика.
Ждем продолжения :)
Не работает Wi-Fi: какую диагностику собрать?