Перейти к содержимому
Калькуляторы

sfstudio

SNR
  • Публикации

    5 146
  • Зарегистрирован

  • Посещение

4 подписчика

О sfstudio

  • Звание
    Академик
  • День рождения 30.03.1982

Контакты

  • Сайт
    http://wi-cat.ru
  • Jabber
    sfstudio-omsk@jabber.ru

Информация

  • Пол
    Мужчина
  • Интересы
    Kernel Hacking

Город

  • Город
    EKB

Посетители профиля

9 065 просмотров профиля
  1. Wi-Fi сеть в ТЦ 4 этажа

    Перестаньте нести херню. Вы сами придумываете себе проблему. Вам уже 300 раз сказали, что её нет, вы продолжаете рассказывать о хэндоверах в вакууме. OKC как и 802.11R это сущности ускорящие миграцию в сетях с шифрованием и только. Причём мегакритичны только в сетях где радиус утащили в жопу мира или развернули на кофейнике. OKC вообще так и кричит своими 3мя буквами что это кэширование ключей и только. Своеобразное, но таки тупо кэш ключей коих в открытых сетях нет вовсе. А больше ничего OKC и не даёт. И если 802.11R можно с трудом за счёт MDIE за уши притянуть к решаемой задаче, то OKC вообще никак не притягивается, ни в каком виде. Хоть застрелись. Они (OKC/R) ничего не дают в открытых сетях коими являются хотспоты (кроме поля MDIE в R). В hotspot 2.0 там другая система, и тоже никакие FT/OKC не упились для миграции и их отсутсвие тоже никак не ведёт к переаутентификации. Это просто сущности из другой задачи от слова совсем. Хватит уже из людей идиотов делать... Не смешно уже нифига Да и на психа внедряющего hotspot 2.0 сейчас (года через 2 может и будет смысл, если не сдохнет в муках) я бы посмотрел..... А вот отсутствие поддержки RRM для дуалбэнда запросто может сделать бесполезным всё остальное, т.к. клиент будет болтаться как говно в проруби сканя весь эфир что вплоть до 7с может занять, ещё и с обрывом. Правда и в этом случае повторной реаутентификации на хотспоте не потребуется в любом случае, т.к. он (хотспот) о физике вообще ничего не знает обычно. А соединениям пользовательских приложений станет дурно. P.S. Кстати убики нынче умеют и R и OKC, так что ваши условия на них тоже выполняются. Пора придумывать другую мантру. Текущая в любом случае не работает. Не говоря уже о сказанном выше (о бесполезности R/OKC в контексте обсуждаемой темы от слова совсем).
  2. Wi-Fi сеть в ТЦ 4 этажа

    Мониторилка? Ну дык wive-ng-control и читаем. Кому хочется может вообще по ssh бегать сам руками опрашивать. Скриптовать свою логику на тру BASH диалекте ASH и т.д. =)) Вариантов дофига. Вот в 4ре утра я точно не готов рассказывать. Тем более всё есть в соответствующем разделе на этом форуме + на wi-cat.ru и вопросы можно задать там же. Соррь. Но я бы таки поспал бы наверное. =))) По мониторилке лучше сразу на wifi@nag.ru написать, дадут линк, подскажут как развернуть, можно даже не имея АП на пробу. По тому что касается роутерно-апшной части это уже к нам на Wi-CAT.
  3. Wi-Fi сеть в ТЦ 4 этажа

    PP.SS. Уж прошу прощения. Но кой-кто мне тут палочкой натыкал на тему. =)) Как бы я тут не бываю, и у нас (ну если у кого будут вопросы) есть свой форум https://wi-cat.ru ;)
  4. Wi-Fi сеть в ТЦ 4 этажа

    Почитайте о архитектуре того же чиллиспота. Он внезапно из 2х частей состоит, одна крутиться на AP ходит до радиуса, она же dhcp сервер + может туннелировать трафик. Для клиента сеть остаётся плоской, а где находиться страница авторизации не имеет значения. И никаких перередиректов с переавторизациями не будет от слова совсем. Опять же если чилли размещаем только на шлюзе, то вообще пофигу и не надо даже заморачиваться. А если он индивидуально на каждой AP то придётся немного хитрее настраивать радиус для чилли, что бы при миграции для изученных маков не происходил повторный редирект, а dhcp выдал тот же адрес что и при первой регистрации плюс всё это полетело через тот же шлю в мир. И это тоже решается штатно. У человека выше ещё проще. Он тупо для всех неизученных MAC (ну как я думаю) редиректит прямо на шлюзе сети на страничку. Как только чел авторизовался, прямо на том же шлюзе убралось правило редиректа и трафик полился во внешку. Больше ничего для клиента не поменялось. А т.к. всё делает шлюз, то и при миграции никаких перезапросов не будет, т.к. ему сугубо пофигу с какой АП пришёл клиент, для него он один фиг пришёл с LAN интерфейса с коммутатора или протащен вместе с L2 туннелем. И эти схемы не единственные беспроблемные. Скорее я могу только одну схему придумать когда описанная проблема будет проявляться. Но напуркуа создавать самому себе проблемы? Если вы не понимаете как это работает, это не значит, что все остальные идиоты. Это значит, что вам пора разобраться в вопросе и переcтать пороть чушь повторяя её как мантру. У яблок он жёстко зашит, обычно это -70Дб у ведроидов тех что сертифицированы по VoIP Enterprise у альянса порог -75 по дефолту (как пример SGS A5 2017), и может регулироваться через проприретарные API либо в конфиге драйвера. И не порог дисконнекта. А именно процедуры хэндовера (да да так оно прям в дровах тех же QCA и обзывается). Т.е. при падении ниже клиент не оборвёт связь до того как не выберет кандидата для миграции. Либо используя RRM либо тупо с помощью сканирования. Опять таки да, можно даже активное сканирование выполнять по всему (и даже обоим) диапазонам не обрывая соединения с текущей АП. Так же нормальный клиент ещё попробует и преаутентифицироваться на кандидате, и только потом послать прощальный фрэйм текущей АП (в случае если удалось уже можно сказать мигрировать). Там целый ряд ухищрений в части миграции используется, что бы попытаться максимально прозрачно для клиента перейти на следующую АП. 1) как править на андроид на квалкоме тут https://wi-cat.ru/wi-fi/besshovnaya-migraciya-rouming-wi-fi-dlya-android-klientov/ 2) программа сертификации от альянса https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-voice-programs 3) пороги при которых инициируется процедура миграции в зависимости от девайса (автор циско) https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/device_classification_guide.html 4) другая полезная информация https://wi-cat.ru/forums/topic/podborka-literaturyi/ Ну и прямо процитирую альянс. How does a client roam? The decision to roam from a connected access point to a new access point is generally the responsibility of the wireless client device. The roaming algorithms used by wireless client devices vary from vendor to vendor, but almost always involve the evaluation of the received signal strength indicator (RSSI). As a user moves away from the connected AP, the signal degrades. The client compares the received signal strength to a pre-defined threshold and determines if a roam is required. Once the signal drops below this threshold, the wireless client performs an off-channel scan, scanning all available channels for a candidate AP, selects one with acceptable signal strength, and completes the roaming process by connecting or associating to the new AP. Some more sophisticated clients utilize additional parameters such as AP neighbor lists or capacity load on an AP to help optimize the roaming process. По поводу ускорения. Самая важная часть это 802.11K особенно в 5ГГц https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html#concept_EA3AF8F14F244478804B2D36C25F44C4 802.11R в схеме с хотспот вообще ничего не даёт ибо нет шифрования на уровне клиент<=>ap, собсно ускорять нечего. Ессно если говорим о публичных хотспотах. Даже в случае с WPA2 Enterprise при локальном размещении радиуса толку с 802.11R в части ускорения около нуля (на фоне на полный рескан диапазона при отсутствии 802.11k). А учитывая, что по прежнему большинство клиентов как не умело FT так и не умеет, в лучшем случае будет заюзан OKC. Польза от 802.11R чаще выражается в наличии поля MDID (mobile domain id) который по сути во первых позволяет устроить роуминг внутри сети со скрытым броадкаст SSID и/или при поддержке АП и клиентом позволяет хоть как-то гарантировать что клиент не мигрирует на левак, хотя опять таки понимает это только часть устройств, во вторых никто не мешает подделать это поле т.к. это по сути тупо текст. А вот 802.11K даёт возможность чётко выяснить кто у нас рядом работает и сканировать не весь диапазон (перед переключением, или после обрыва связи и/или по другому какому-то событию), а просто спросить кто рядом у текущей АП к которой подключен клиент. Т.е. исключается полное сканирование диапазона которое может занимать до 7 секунд в случае с 5ГГц. Так же 802.11K предоставляет возможность запросить клиенту Link Measure, т.е. спросить у текущей АП с какими уровнями она слышит вопрощающего, дабы скорректировать порог форсирования миграции. Так же именно в 802.11k передаются параметры рассказывающие клиенту о том совпадает ли тип авторизации и т.д. и т.п. Всё это (при условии поддержки клиентом) существенно сокращает время миграции. И это ещё не всё, например QCA/BCM для андроид после всех запросов и прочего считают для каждого кандидата score в котором учитывается куча факторов, включая поддержку WNM и прочего. Может учитываться QLOAD и ещё дофига чего. Что ещё есть со стороны АП? Ну например есть WNM частью которого является BTM, но я так и не нашёл ни одного клиента который бы его поддерживал. Даже яблоки с заявленной поддержкой 802.11v на данный момент игнорируют BTM фрэймы. Остальное всё чистокровный фуфел и очковтирательство. Уж простите, но наболело. P.S. Что бы при этом миграция оставалась бесшовной не только с точки зрения индикатора подключения wifi на клиенте, но и для приложений, нужно сделать несколько доп телодвижений что бы для клиента после миграции на L2 и выше по сути ничего не менялось. Т.е. один DHCP сервер который если что продлит лизу, один адрес до и после мигарции, один шлюз. Для этого чаще всего либо тянут туннелями L2 до шлюза, либо просто делают плоскую L2 сеть куда воткнуты все АП + шлюз в мир + dhcp + dns сервер и если надо радиус сервер. Если к этому ещё привернуть красивую морду для управления слабоподготовленным персоналом + запустить мониторинг с красивыми графиками + обеспечить какую-то худо бедную конфигурилку уже можно смело говорить, о том что у вас суперпупер контроллер. =))) PP.S. Ну и да. Wive (а значит и SNR) традиционно уже умеют как 802.11K/R/OKC, могут быть сами радиусом, сами DHCP и прочим. И мониторинг с управлялкой так же доступен. И всё без очковтирательства, бесплатно и без SMS. =))))
  5. Точка доступа SNR-CPE-AP2 dhcp-client

    Конфигурировались у вас точки, конфигуратором по имени контроллер, который чаще всего ещё и dhcp/radius и т.д. сервер. О городушках с L2 я говорил выше. И они обычно плохо заканчиваются, как показывает практика того же микротика. У нас управление с Wive-NG-CONTROL по ssh. Никаких городушек с изобретением велосипедов. Уж о ональных зондах молчу. Не проплатил подписку -> сдох сертификат -> приплыли. Быстро понимаешь, чья тут сеть твоя или CISCO. Нет ну дело каждого. У нас нет цели захватить клинта в рабство, потому тяготем к стандартным для *nix вещам.
  6. Точка доступа SNR-CPE-AP2 dhcp-client

    Без разницы контроллеры там или не контроллеры. Оборудование обеспечивающее инфраструктуру должно минимально зависеть хоть от контроллера, хоть от сервиса сети хоть от чего-то ещё. Динамика тут зло которая ничего не даёт, кроме экономии 2х минут на АП при первой инсталляции. И даже это обходиться развёртыванием одной из систем управления (wive-ng-control/acs tr-*) которая при включении точки может подхватывать её по дефолтовым адресам, автоматом тут же обновить и забить адрес сразу занеся в базу управления. Натыкать АП с dhcp и потом выяснять где какая АП висит по факту занимает гораздо больше времени чем даже ручная конфигурация. Ведь наверняка следующим вопросом будет - а почему бы по дефолту не включить dhcp на единственный интерфейс AP. А потом начнётся нагораживание всяких L2 костылей для отлова и т.д. Так уж случается, что в мире сетей удобство (часто удобство сомнительное) с точки зрения администратора чаще всего выливается в оверхид по логике, доп точкам отказа и прочим прелестям. Нет, я на полях запишу, но я не вижу никакого профита от использования dhcp для конфигурации по сути инфраструктурных вещей, можно наловиться чудес по полной.
  7. Точка доступа SNR-CPE-AP2 dhcp-client

    Никак. Штатно такой вариант не предусмотрен. АП есть АП, нечего там динамике делать.
  8. Ничего с тех пор не поменялось. Логика всё та же. И уж я точно не помню что выкладывал, ибо если проблему решили - решение ушло в основную ветку. На стороне CPE основной канал без vlan. Сервисы SIP/IPTV могут быть тегированы. Ну и как я уже грил wifi@nag.ru - пусть повторяют. Либо (желательно после wifi@nag.ru) с полной диагностикой к нам на wi-cat.ru. P.S. Если я правильно понял, то при native vlan на входе CPE обычный ETH без всяких тэгов. Не вижу проблем. Как и не понимаю что значит отваливается. Логов нет, диагностики нет. Ну я не знаю чем помочь. Вроде провайдер, должны понимать, что что бы в чём-то разобраться, заявлений о "отваливается" или "подземных стуках" недостаточно. Т.к. ни логов, ни конфига ничего не вижу... Ну... В общем на wifi@nag.ru либо (а лучше после) жду нормальный репорт с хоть какими-то данными для повторения. PP.S. Что-то мне подсказывает, что проблема у вас на уровне коммутатора. В вашей схеме по сути собсно он "голый" трафик заворачивает по влан, по логике, что всё то, что пришло не тегированным должно быть завёрнутов в vlan (97 у вас) ну и наоборот. А тегированный должен бегать без вмешательсва. Роутер о этой схеме ничего не знает, да и не должен. Стоит задать вопрос производителю коммутатора. Если только тегированное ТВ "иногда отваливается" то это вдвойне сказачно... Хотя без понимания, что значит отваливается и как повторить я ХЗ чем помочь. PP.SS. Фирмварь последняя отсюда https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/ ? Сброс кнопкой и настройка (МИНИМАЛЬНАЯ, без кручения опций "по наитию") ручками (для чистоты эксперимента).
  9. Продолжение публикаций будет после запуска в серию новых устройств ближе к осени. Сейчас 24/7 загружен работой над ними. Потому всё (кроме работы над ними и сопровождением текучки по багрепортам) остановлено. Примеры настройки handoff есть тут на форуме. handover клиентская сущность (описался выше видимо или из контекста выдрали). Все новые материалы появляются у нас на сайте https://wi-cat.ru Следите за обновлениями. Если есть конкретные вопросы - https://wi-cat.ru/forums/ Вопросы, что где, как и откуда брать, а так же как настроить можно задавать на wifi@nag.ru типовые кейзы товарищам описаны. Это первая линия поддержки. Собсно что бы не отрывать остальных от дела. Если не помогло, то к нам https://wi-cat.ru/forums/ На форуме NAG я бываю по остаточному принципу. Так же ряд публикаций и заметок уже готов и есть на wi-cat.ru в т.ч. общие рекомендации, заметки по миграции и т.д.
  10. Напишите уже наконец на wifi@nag.ru, там сидят люди которые расскажут и покажут в т.ч. что и где взять и как настроить и какие схемы вообще возможны. А то я умру заниматься всем и всям.
  11. Эт хвалёный TR-069 и иже с ними. Разворачиваете ACS и вперёд.
  12. Бесшовный WiFi на openWRT

    Вот тут недавно описывал что поменялось за последнее время http://forum.ixbt.com/topic.cgi?id=14:65313 Кстати в 802.11 WNM наконец появилась возможность сказать клиенту "посмотри по сторонам". Но пока даже свежие дрова под интелы и самсы этого не понимают. Как только получу клиента умеющего это дело - сразу добавлю в Wive. Причём там есть непонятка в виде завязки на Hotspot2.0, не ясно напуркуа.
  13. А сейчас как-то иначе? =) Включить SSH по дефолту с WAN и добавить юзверя для ssh managment со своей стороны, причём оно не будет сбрасываться кнопкой, сейчас вполне реально. Но в любом случае это городушки. Хочется автоматизации и связи с биллингом - можно осуществить через CWMP при желании и предконфигурить его включение с завода. Дальше уже всё штатно. Собсно для этого оно и придуманно. Развернуть ACS задача для доморощенного сисадмина на вечер. В общем всё решаемо. Опять таки напишите на wifi@nag.ru расскажут какие схемы и варианты возможны.
  14. Какие нафиг серверные стороны, какой к чёрту белый шум. Завязывайте. Форум фантазёров не тут, да и фантазии разбиваются о суровую реальность. Правильный подход это конфигурация паролей по факту установки с возможностью юзверю сгенерить новый по запросу. И правильное оно со всех отчек зрения, от технической до законодательной.
  15. Для приложения вообще никаких баз не надо. А вот для преконфигура на заводе либо статические алгоритмы и генерация прямо в прошивке, или усложнение цикла, что выльется в доп затраты и наплодит доп потенциальных косяков.