Wi-Cat / Wive-NG. Страница 4
168
@Wicatllc
Новости, статьи, анонсы относительно операционной сиcтемы Wive-NG, беспроводного оборудования, а так же темы затрагивающие Wi-Fi (802.11) в общем.
-
Wi-Cat / Wive-NG
Участились жалобы на якобы взломы домашних роутеров. Цель взлома - использование как узлы бот сетей и/или для амплификации DDOS. Давайте всё же повторим простые правила что бы этого избежать от более критичных к менее: 1) web/ssh иные службы не следует разрешать с WAN без необходимости, либо делать это только с конкреnных IP 2) все пароли должны быть сложными (анализ данных в репортах показал что 99,9999% случаев либо были пароли по умолчанию, либо словарные). Не стоит думать, что если вы не разрешили доступ с WAN то можно не менять реквизиты доступа к админке. 3) Большинство "взломов" роутеров осуществляется со скомпроментированных устройств под управлением Windows уже из локальной сети. Т.е. просто смотрят адрес шлюза и стучатся туда на Web или SSH... Поэтому реквизиты доступа должны быть изменены при настройке. 4) пароль на WiFI должен быть весьма сложным. Особенно если вам пришлось (в силу кривости клиентов) отключить PMF. 
-
Wi-Cat / Wive-NG
На злобу дня.... 
-
Wi-Cat / Wive-NG
4.4.8 Released: 1) Драйвер MT7615 обновлён до 5.1.0.0 в котором MTK провёл работу над ошибками касательно реализации криптографии, часть правок так же портировано и для других чипов в их драйвера 2) Отрефакторен код iaapd. Это демон реализующий 802.11f и используемый для обмена сообщениями между AP в multiap сетях (в т.ч. для дистрибуции ключей в 802.11r) . Давно планировал т.к. накопилась стопка грязных хаков. Как результат выявлена стопка шероховатостей которые могли приводить к проблемам миграции в ряде хоть и редко возможных, но всё же вполне реальных случаев. 3) Доработан механизм престиринга в bndstrg 4) Затянут ряд фиксов из апстрима busybox,dnsmasq,kernel,uclibc-ng 5) в web добавлена возможность принудительно перезагрузить USB модем по питанию 6) переработана сводная (главная) страница в части индикаторов, например реализованы индикаторы утилизации портов коммутатора И множество других мелких изменений. P.S. 13 марта, за окном -18... ;( 
-
Реклама
-
Wi-Cat / Wive-NG
Небольшая частная инициатива: https://wive-ng.ru/wive-ng-hq-snr-me1/ -
Wi-Cat / Wive-NG
Что поддерживают адаптеры Intel под W10 из K/R/V можно глянуть у них на сайте www.intel.com/content…ess.html Стоит отметить что интел говорит что Windows 10 хоть и научился R и V но не умеет R в Personal сетях (только Enterprise). Благо интелы как из пушки мигрируют где угодно ;) Но если честно этот весь адовый бардак уже реально так поднадоел. Не пора ли R для всех вариантов аутентификации и шифрования в Mandatory? Но не дождусь чую. ;( -
Wi-Cat / Wive-NG
Забыл упомянуть: 4) клиентов впадающих в депрессию и начинающих безбожно глючить вплоть до полной невозможности подключиться при включенной поддержке R или V на ТД стало в разы меньше (однако всё ещё встречаются). Причём глюки могут быть абсолютно любыми. Но чаще всего это отказ подключаться вообще в случае с R и хаотичные отвалы линка в случае с V (в части BTM). Происходит абсолютно бессистемно. 802.11k в подобном незамечен, однако и его поддержки толком нигде нет. Т.е. как и прежде требуется проверка совсместимости, а ещё лучше контроллируемый парк клиентских устройств. Если мне попадаются такие устройства в руки, я пытаюсь или починить или обойти проблемы со стороны AP, но вот SGS J100 (помойму) не вышло. Только анонсим 802.11R и он даже не пытается подключиться. Всё умирает на probe. От ТД не зависит, поведение идентично что у нас, что у именитых ENT товарищей. -
Wi-Cat / Wive-NG
Пару слов, о том что поменялось за последние годы в части поддержки миграции клиентами (личный опыт): 1) поддержка K/R особенно в PSK режимах всё ещё редкость, тут выделяется разве что Самсунг и Яблоки 2) достаточно много устройств умеют WNM (V) (увы часто сильно частично) 3) почти все (>90% двух диапазонных и чуть больше 60% однобэндов) свежевыпускаемые устройства (смартфоны, ноутбуки, остальное не отслеживаю) так или иначе умеют мигрировать между AP в PSK режимах без использования K/R (последствия агрессивного маркетинга в части MESH, по факту MultiAP с бесшовным роумингом) Что сказать, за 5ть лет (а бурные изменения в этой части за последние пару лет) ситуация кардинально улучшилась. Как следствие почти отпала необходимость использовать Handoff (жёсткое спинывание с AP) почти во всех случаях кроме 2.4ГГц устройств. С реализациями хэндовера и критериями как был полный раздрай, так и остаётся. Поэтому поведение разных клиентов может быть сильно разным. Но даже такие изменения уже однозначный позитив. 
-
Wi-Cat / Wive-NG
Новый стэнд и небольшое число правок позволило более оперативно подготовить первый публичный релиз 4.3.х ветки. Основное изменение это обход проблем с миграцией (без нарушения стандарта с нашей стороны) с некоторым оборудованием о котором рассказано выше (потребовалось изменить логику в wifi драйверах и iappd). Так же ряд улучшений. Например возможность задать в Complex Shaper приоритеты исходя из ip клиента (например для ограничения скорости). К сожалению при этом придётся полностью отключить NAT offload, что приведёт к падению производительности а разы. Шейпинг крайне требовательная к CPU вещь. P.S. Первое актуально только для MultiAP конфигураций с роумингом. -
Wi-Cat / Wive-NG
Итого, съездил на объект. Проблемы с миграцией ушли. Увы набор клиентов сегодня куций был (выходной половина работников отдыхает), но выборка достаточная что бы констатировать факт. В паблике фикс будет доступен к концу недели (регрессивные тестирования это не быстро). Однако желающие поучавствовать в тесте до публичной доступности могут это сделать достаточно просто. Нужно: 1) зарегистрироваться у нас на сайте (wi-cat.ru) 2) скинуть на [email protected] адрес e-mail указанный при регистрации, ваш текущий IP (посмотреть на myip.ru, только ipv4), и WAN мак адрес указанный на наклейке на дне устройства (не тот что вы могли задать сами, а именно заводской) Это нужно что бы среди вороха обезличенных данных найти именно вас и переключить ветку на тестовую. Быстро обрабатывать заявки не обещаю. Выходные всё же. -
Wi-Cat / Wive-NG
Только что закончил полный ревью на эту тему. Вроде не должно быть проблем с таким обходом. Интересно, что побочкой стало проявление наличия 802.11R у Galaxy SGS A30s... Причём прикол в том что он заявляет о поддержке FT только уже после первой миграции. И что интересно после этого корректно отрабатывает миграцию по FT процедуре. Поддержка 802.11r для него не то что не заявлена, но и за время владения ни разу ни в одном дампе ни с одним ни с одной ТД, ни одного вендора/чипмэйкера обнаружена не была... В общем, завтра проверю на объекте. И если всё будет ОК то после регрессивных тестов в течении недели зарелизим 4.3.1* -
Wi-Cat / Wive-NG
Не удержался напросился в гости на проблемный объект, заменил в одном помещении убикьюити (люди выбрали их, но почему-то ума не дали) на FT-AIR. Проблема повторилась и на нём. Записал все дампы эфира. Логи в дебаг режиме. Нужно чуть чуть поменять логику в процедуре реассоциации и думаю этого будет достаточно что бы обойти проблему не сломав на других. Сегодня сделаю - завтра проверим. ;) Спасибо хозяину сети и клиентов за возможность немного подпортить рабочий процесс экспериментами. ;) Хотя учитывая, что ещё неделю назад оно вообще не шевелилось... =) -
Wi-Cat / Wive-NG
Отличная табличка составленная по анализу захваченных с эфира дампов. Ценность оной в том, что позволяет оценить какой клиент и что поддерживает. Однако это не истина в последней инстанции. Ибо например некоторые клиенты анонсируют поддержку 802.11w но по факту она неработоспособна. Так же многие возможности не железоспецифичны и зависят от OS и конкретной реализации в ней. P.S. Не помешали бы ещё отдельные колонки 802.11R/K но даже это уже хорошо. И автору спасибо однозначное. Пригодится. ;) https://clients.mikealbano.com/ -
Wi-Cat / Wive-NG
Ещё на заметку. Начиная с iOS10 Apple кроме уровня научился оценивать загруженность AP по данным Qload предоставляемым самой AP. Т.е. если загрузка у AP по Qload 100% iOS будет откладывать старт миграции на эту AP. А учитывая что QBSS Load это загрузка не AP а эфира в выбранной полосе частот на которой работат AP то... А дальше варианты в зависимости от устройства сети, числа узлов, конфигурации и т.д. ;) Но есть над чем подумать. =) -
Wi-Cat / Wive-NG
На заметку... Вчера на объекте в очередной раз столкнулся со странностями поведения клиентов. И опять это чистокровный китай в виде Xiaomi. Суть в том, что миграция при включенном 802.11R происходила с ооочень большими задержками (несмотря на льющийся в это время трафик) и не всегда успешно. При этом судя по логам и дампу эфира они вообще 802.11r не умеют (впрочем как и WPA3, а уж SAE-FT вообще редкая птица пока может). Но видимо сам факт вещания Mobile Domain у них так же меняет критерии выбора (о чём статья выше). И всё бы не беда, и можно было бы не заморачиваться т.к. сеть без Radius, чисто на PSK, но при отключенном R перестали бесшовно мигрировать яблоки у части сотрудников. =)))) Методом перебора всех вариантов оказалось что откат с WPA3/WPA2 Mixed на голый WPA2 с отключенным PMF приводит к тому что включенный 802.11r больше не влияет на китайцев и они мигрируют относительно пристойно. Ну и яблоки довольны. На мой взгляд отключение PMF идея крайне фиговая. Но в этом кейзе важна была именно бесшовность на всех клиентских устройствах. И вот сегодня покопавшись в сети нашёл у CISCO следующее высказываение: 802.11r FT + PMF is not recommended www.cisco.com/c/en/us…-dg.html Что делает сиё ещё более интересным. Может дадут на выходные погонять проблемные экземпляры для препарации, ибо вопросы остаются. Пока ясно что наличие PMF или WPA3 в анонсах осложняет миграцию на ряде клиентов (как минимум ряде Xiaomi). Надо будет посмотреть что за радиомодуль в этих трубках. Ибо китайцы редко правят что-то в части WiFI относительно SDK чипмэйкера, т.е. можно будет попытаться найти исходники (утечки есть почти всегда) и посмотреть изнутри. ;) В 2022г это беда... И по-хорошему нужно вендору этих клиентов писать и ругаться. -
Wi-Cat / Wive-NG
Роуминг (миграция клиентов между ТД) в Wi-Fi сетях — Часть 6 — Пример критериев выбора кандидата для миграции К сожалению 802.11 как стандарт не имеет явных требований к критериям выбора кандидата для миграции, в итоге каждый чипмэйкер (а то и вендор) реализует этот момент в силу своей фантазии. Этим и обусловлено различное поведение при миграции от устройства к устройству. Сегодня рассмотрим один из вариантов на примере кода клиентов от MTK. Этот код… wi-cat.ru/wi-fi-r…criteria -
Реклама
-
Wi-Cat / Wive-NG
Релиз 4.2.17 ознаменовал собой очередную победу Band Steering в деле мягкого порабощения новых клиентских устройств. Теперь и последние топовые SGS уживаются со стирингом и роумингом одновременно. Т.е. удалось, в очередной раз, найти тот самый компромисс когда стиринг эффективен, но практически не сказывается на бесшовной миграции, а в некоторых случаях даже помогает. В любом случае о применимости той или иной технологии в конкретно вашем случае можно судить только проведя эксперимент. -
Wi-Cat / Wive-NG
Что ещё можно сделать (без отказа от единого SSID и без активации BandSteering) для улучшения ситуации с клиентами не умеющими BandPreffered и усиленно пытающимися съехать в 2.4ГГц. Ну или просто подстраховаться на стационарных клиентах, где миграция между диапазонами вообще абсолютное зло ибо устройство неподвижно. Если устройство на Android то можно попробовать например вот такое приложение play.google.com/store/a…/details Конечно всём было бы проще если бы вендоры просто вынесли бы крутилки (которые чаще всего присутствуют в драйверах клиентских устройств и/или с лёгкостью реализуются даже на уровне wpa_supplicant) для приоритизации выбора диапазона (да и настройки критериев handover иметь возможность покрутить было бы не лишним), ну хоть так. Это всё же лучше, чем пытаться со стороны ТД, не имея никаких данных с клиента (кого он видит, с какими уровнями, что по факту умеет т.д.) т.е. действуя абсолютно вслепую на уровне ТД пытаться вынудить сделать то, что нам нужно клиента... -
Wi-Cat / Wive-NG
Кроме прочего ноутбучные карточки часто позволяют задать агрессивность роуминга. По сути это порог RSSI при котором устройство начнёт искать кандидата для миграции. Выше агрессивность - ниже порог. Очень полезная крутилка, особенно когда невозможно построить сеть по-человечески (почти все домашние инсталляции). Достаточно просто увеличить агрессивность роуминга, что бы клиент во многих случаях начал уверенно мигрировать. Что в купе с механизмом Band Preffered сделает работу в Multi AP сети максимально комфортной. Но к сожалению в телефонах/планшетах такие настройки не вынесены на сторону UI и влиять на них не выйдет. Потому....