Как стать автором
Обновить

Комментарии 14

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

Это половина нужной диагностики, потому что контроллер (и сама вайфай-сеть) видит клиента, так скажем, с другой стороны.

Хорошо, когда есть сенсоры вайфая, активный мониторинг — вот тут можно будет сравнить клиентскую статистику с эталонной клиентской статистикой.

Только в конце нужно добавить connection, а иначе не сработает:

nmcli -f NAME,UUID,AUTOCONNECT,AUTOCONNECT-PRIORITY connection

(вместо connection можно использовать просто c)

Спасибо, теперь в статье.

Извините, почему то в буфер не попало при копи-пасте из терминала:(

Проверить доступность

...

- Внешний 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]

Чаще приходится работать с заявками типа "Нет Интернета", и эта информация будет полезна для исключения/подтверждения проблем на пути передачи трафика.

Ждем продолжения :)

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

Публикации

Истории