Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

WPA Enterprise/802.1x (авторизация с использованием Radius)

Есть SNR-CPE-ME1.

В настройках радио выбран WPA2-EAP, указан RADIUS-сервер.

Подключаюсь к беспроводной сети с андроида, выбираю метод EAP, указываю правильные логин и пароль.

В дампе проскакивает следующее:

12:58:50.634190 IP (tos 0x0, ttl 63, id 40689, offset 0, flags [DF], proto UDP (17), length 162)
    10.1.128.101.57435 > 10.1.128.100.radius: RADIUS, length: 134
   Access-Request (1), id: 0x02, Authenticator: 6899ce2b2b74afbaa0271e11251030fd
     User-Name Attribute (1), length: 9, Value: 1010002
     NAS-IP-Address Attribute (4), length: 6, Value: 10.10.10.51
     NAS-Identifier Attribute (32), length: 11, Value: Wive-NG 0
     NAS-Port Attribute (5), length: 6, Value: 1
     Called-Station-Id Attribute (30), length: 19, Value: F8-F0-82-50-50-BB
     Calling-Station-Id Attribute (31), length: 19, Value: CC-61-E5-0F-54-4A
     Framed-MTU Attribute (12), length: 6, Value: 1400
     NAS-Port-Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
     EAP-Message Attribute (79), length: 14, Value: ..
     Message-Authenticator Attribute (80), length: 18, Value: 5;...M..W?.IiV..
12:58:50.635051 IP (tos 0x0, ttl 64, id 32277, offset 0, flags [none], proto UDP (17), length 108)
    10.1.128.100.radius > 10.1.128.101.57435: RADIUS, length: 80
   Access-Challenge (11), id: 0x02, Authenticator: bc83cde4c07a823c98268005c1864695
     EAP-Message Attribute (79), length: 24, Value: ..
     Message-Authenticator Attribute (80), length: 18, Value: )..{xA
     State Attribute (24), length: 18, Value: .B-..@).P.D.}..B
12:58:50.637948 IP (tos 0x0, ttl 63, id 40693, offset 0, flags [DF], proto UDP (17), length 174)
    10.1.128.101.57435 > 10.1.128.100.radius: RADIUS, length: 146
   Access-Request (1), id: 0x03, Authenticator: b849f4216ad0bf7477cf105d5c2328aa
     User-Name Attribute (1), length: 9, Value: 1010002
     NAS-IP-Address Attribute (4), length: 6, Value: 10.10.10.51
     NAS-Identifier Attribute (32), length: 11, Value: Wive-NG 0
     NAS-Port Attribute (5), length: 6, Value: 1
     Called-Station-Id Attribute (30), length: 19, Value: F8-F0-82-50-50-BB
     Calling-Station-Id Attribute (31), length: 19, Value: CC-61-E5-0F-54-4A
     Framed-MTU Attribute (12), length: 6, Value: 1400
     NAS-Port-Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
     EAP-Message Attribute (79), length: 8, Value: ..
     State Attribute (24), length: 18, Value: .B-..@).P.D.}..B
     Message-Authenticator Attribute (80), length: 18, Value: g....$..fq...Uy.
12:58:51.730689 IP (tos 0x0, ttl 64, id 32501, offset 0, flags [none], proto UDP (17), length 72)
    10.1.128.100.radius > 10.1.128.101.57435: RADIUS, length: 44
   Access-Reject (3), id: 0x03, Authenticator: ed732735227e3dc7b66a8c57bf4ff3d7
     EAP-Message Attribute (79), length: 6, Value: ..
     Message-Authenticator Attribute (80), length: 18, Value: o..........TT.M.

И на смартфоне выводится ошибка подключения.

Проблема в настройках RADIUS? Или AP не умеет метод PWD?

Радиус где? На точке? У нас встроенный радиус есть в фирмваре, какраз схема WPA2-EAP-PWD with MSCAHP2 юзается если склероз не замучал. Можно подглянуть и сравнить в т.ч. дампы при работе с вашим уже радиусом.

В лоб я вот по дампу не скажу, как бы настройки радиус серверов это не то, что я каждый день делаю. =)

P.S. Вообще прежде чем дампить зачастую крайне полезно смотреть в логи с обоих сторон. Зачастую нормальный радиус сервер способен сказать чего ему не нравиться нормальным языком без необходимости разбора дампов.

PP.S. Если юзаете FreeRadius то сконфигурировав радиус на точке можно в /etc на ней глянуть и конфиги для примера.

PP.SS. В общем я бы начал бы разбор с того что настроил бы встроенный в Wive радиус сервер на одной железке. На другой бы сконфигурил радио для аутентификации в радиус. Убедился бы что всё работает. Сдампил бы на всякий общение. Затем переключился бы на проблемную связку, глянул бы на что ругаеся радиус, сдампил бы неудачную сессию. И уже имея все эти данные разбирался бы дальше.

Нет, RADIUS внешний.

Пробовал активировать встроенный и прописать в нем статикой логин/пароль — и тоже не получилось авторизоваться.

Встроенный я прописывал как 127.0.0.1. Правильно?

Чтобы исключить все постороннее, начал все с нуля.

Перевел в режим точки доступа.

В Сервисы - Сервер RADIUS включил RADIUS-сервер, секрет оставил по умолчанию (snr-cpe-key). Добавил пользователя eap_test_1 с паролем 1 и eap_test_2 с паролем 2. В настройках радио выбрал режим WPA2-EAP, адрес RADIUS-сервера указал как 127.0.0.1, секрет скопировал из предыдущего значения. Когда со смартфона пытаюсь подключиться к беспроводной сети, выбирая метод PWD и указывая eap_test_1/1, получаю ошибку аутентификации. В логе точки "Aug 29 16:05:06 radiusd[4058]: (1) Login incorrect (eap: No mutually acceptable types found): [eap_test_1] (from client * port 1 cli CC-61-E5-0F-54-4A)".

Попробовал вместо localhost указать IP-адрес моста (10.10.10.51) — без изменений, не подключается.

Берём фирмварь отсюда https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/NAG-SNR-CPE/

Шьём, сбрасываем кнопкой.

Включаем радиус добавляем юзверя. Затем в настройках радио выбираем режиме WPA2 Enterprise и указываем LAN адрес АП.  Пробуем.

На смартфоне ничего трогать не надо. Он сам предлагает по дефолту нужный метод обычно.

Кстати далеко не все смарты увы работают корректно с WPA Enterprise. Увы.

Ок.

Загрузил прошивку SNR-CPE-ME1-5GHZ-MT-MT7621-MT7603-MT7610-1T1R-16M-USB.8.2.8.RU.27082019.bin, сделал сброс настроек кнопкой, настроил в режиме точки доступа заново. Включил RADIUS, добавил пользователей. Включил WPA2-EAP, указал настройки RADIUS (IP-адрес LAN).

Подключаюсь со смартфона методом PWD (Lenovo P2, по умолчанию он ничего не предлагает, а дает на выбор список методов) — неуспешно, уровень сигнала сразу же падает с максимального до небольшого и следом телефон выдает ошибку аутентификации. То же самое с методами PEAP-MSCHAPV2, TTLS-MSCHAPV2 (для этих методов выбирал использование системных сертификатов и указывал домен DEFAULT).

Если выбирать метод PEAP-MSCHAPV2, но вместо выбора сертификатов указать "Не проверять и не шифровать соединение", то подключение успешно устанавливается. Так и должно быть?

Разве это не означает, что аутентификационные данные будут передаваться по радио в открытую?

Я бы все-таки хотел использовать метод PWD (и опционально SIM). На своем RADIUS-сервере я смогу настроить их поддержку. Требуется ли их поддержка от точки доступа? Как я понимаю, общение с RADIUS-сервером осуществляет точка доступа, а не клиент, то есть точка доступа должна получать от клиента нужные данные и отправлять их на сервер AAA.

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

Встроенные радиус сконфигурирован как PEAP+MSCHAPv2 вторым этапом.

Т.е.  при подключении выбираем Метод PEAP, Проверка подлинности MSCHAPv2.

Если выбирать метод PEAP-MSCHAPV2, но вместо выбора сертификатов указать "Не проверять и не шифровать соединение", то подключение успешно устанавливается. Так и должно быть?

Разве это не означает, что аутентификационные данные будут передаваться по радио в открытую?

Нет, данные аутентификации будут шифроваться ибо юзается MSCHAPv2 который подразумевает шифрование, остальные данные штатно будут пошифрованы AES.

Что бы заработало на основе сертификатов требуется как минимум наличие валидного сертификата с 2х сторон, в системе и радиусе, ещё и андроид их должен нормально съесть.

Единственный вариант поддерживаемый почтив семи клиентами эт PEAP+MSCHAPv2 . Остальное требует танцев вокруг клиентов и радиуса т.е. в реальной жизни увы слабо применимо.

У меня руки так и не дошли раскрутить всю эту муть до конца т.к. никто не хочет заморачиваться с плясками вокруг клиентов и какие-то сертификаты предустанавливать и т.д. Хотя в теории работать должно и в таком режиме.

Мы бы хотели развернуть это все с сертификатами. И как я понимаю, самоподписанные не подойдут (т.к. применимы только в корпоративных сетях с применяемыми политиками), нужны сертификаты, удостоверенные публичными CA. Правда непонятно, у кого их спрашивать, отечественные УЦ вообще не понимают, о чем речь, когда я у них спросил сертификат для хотспота. И как я понимаю, пусть и публичные, но сертификаты все равно нужно будет загружать клиентам, просто в отличие от самоподписанных на них не будет ругаться сам смартфон, что недоверенные.

Отсутствие шифрования меня беспокоит не столько тем, что кто-то взломает MVCHAPv2, сколько тем, что на каком-нибудь обновлении айфоны начнут считать такую сеть небезопасной и откажутся к ней подключаться.

Но я сейчас проверил, на десятом самсунге такого метода нет. И на айфоне тоже нет. Так что этот метод для публичного хотспота скорее всего не годится. Раз PEAP+MSCHAPV2 самый распространенный и совместимый, значит буду использовать его.

А вот если надумаете добавить поддержку методов SIM или AKA, то это было бы перспективно.

Судя по коду там сделано так:

type = data[0]; // берём тип фрэйма
...
if (type == EAP_TYPE_IDENTITY) // если это данные аутентификации
{
  выбираем кусок непосредственно уже фоэйма аутентификации в буфер (там и типы и прочее прям куском)
}

Затем пакуем всё это в пакет и шлём радиусу. Если всё ОК получаем ответ и пускаем клиента.

Т.е. с таким подходом должен работать любой метод поддерживамый радиусом т.к. по сути выполняется тупо трансляция запросов.

Я задам МТК вопрос что бы форсировать. Ибо у меня сейчас не будет времени разбираться. Да и PEAP+MSCHAPv2 таки как ни крути основной юзаемый почти везде, потому на нём и отлаживал.

 

Цитата: alibek от 29/08/2019, 19:11

Мы бы хотели развернуть это все с сертификатами. И как я понимаю, самоподписанные не подойдут (т.к. применимы только в корпоративных сетях с применяемыми политиками), нужны сертификаты, удостоверенные публичными CA. Правда непонятно, у кого их спрашивать, отечественные УЦ вообще не понимают, о чем речь, когда я у них спросил сертификат для хотспота. И как я понимаю, пусть и публичные, но сертификаты все равно нужно будет загружать клиентам, просто в отличие от самоподписанных на них не будет ругаться сам смартфон, что недоверенные.

Вот тут не подскажу. После того как андроид перестал жрать самоподписанные сертификаты и запретили генерить их для серых адресов я выпал из этого момента.

Отсутствие шифрования меня беспокоит не столько тем, что кто-то взломает MVCHAPv2, сколько тем, что на каком-нибудь обновлении айфоны начнут считать такую сеть небезопасной и откажутся к ней подключаться.

Ну нет. Эт как бы основная штука юзаемая по миру. Замены ей пока не предложено. Всмысле связка PEAP+MSCHAP для коннекта произвольных девайсов зная только логин и пароль по радио.

Так что не в обозримом будущем точно.

Цитата: alibek от 29/08/2019, 19:20

Если добавите, будет не лишним.

Судя по всему на стороне АП добавлять ничего не требуется (см выше)

Но я сейчас проверил, на десятом самсунге такого метода нет. И на айфоне тоже нет. Так что этот метод для публичного хотспота скорее всего не годится. Раз PEAP+MSCHAPV2 самый распространенный и совместимый, значит буду использовать его.

Ну вот на Yota у меня оного тоже нет. На cамсунге 5м есть.

А вот если надумаете добавить поддержку методов SIM или AKA, то это было бы перспективно.

Ну опять таки, похоже не нам надо добавлять, а на стороне радиуса и разбираться чего эт такое для начала.

Дойдём до реализации радиуссервера с микробиллингом в x86 устройствах посмотрю на эту тему. Записал на полях.

//чутка подчистил что бы народ в заблуждение не вводить

Получилось, завел PEAP+MSCHAP на своем RADIUS-сервере. Сейчас подключение к беспроводной сети выполняется по индивидуальному логину-паролю из БД. На RADIUS-сервер приходит такой запрос:

   Packet-Type = Access-Request
   User-Name = "???"
   NAS-IP-Address = 10.10.10.51
   NAS-Identifier = "Wive-NG 0"
   NAS-Port = 1
   Called-Station-Id = "F8-F0-82-50-50-BB"
   Calling-Station-Id = "CC-61-E5-0F-54-4A"
   Framed-MTU = 1400
   NAS-Port-Type = Wireless-802.11
   EAP-Message = 0x???
   State = 0x???
   Message-Authenticator = 0x???
   Event-Timestamp = "Aug 30 2019 16:14:46 MSK"
   Timestamp = 1567170886

Можно ли сделать так, чтобы передавалось имя беспроводной сети, к которой осуществляется подключение?

На правах гадалки хочется MBSSID заюзать в связке с ENT и бесшовным роумингом? Просто иначе смысла не видиться.

Вообще там регламентированы поля все, добавлять что-то своё == ломать совместимость с другими реализациями готовых wifi биллингов и их радиус серверами.

Ну и соль возможности аутентификации в радиус это возможность ухода от схемы MBSSID (увеличивающую утилизацию эфира бесполезными данными, добавляющую дополнительные периоды ожидания и т.д. Да и потенциально проблемную в ряде случаев), и переход к правильной схеме с например разруливанием доступа в ту или иную подсеть/индивидуальному шейпингу/ и т.д. по данным из радиуса per user на шлюзе.

Можно пойти конечно другим путём. И для каждого MBSSID сделать разные адреса радиус сервера, а на стороне машинки с радиусом настроить альясы.

Но ИМХО нужно избегать костылей в виде MBSSID учитывая что K/R по нормальному будет работать только для WDEV=0 т.е. только рутовых интерйфейсов (это касается всех железок на чипах до MT7615D да и там не все ограничения сняты).

Я реализовывал схему собсно x86 машинка с радиусом + bind + мускул + самописанная логика под шейпер. Суть в том адреса и роуты выдаём в зависимости от пары логина с которым пришёл юзверь. Сразу же в зависимости от его статуса (гость, начальник и т.д.) рулим правила нетфильтра на основании src mac, там же лепим шейпер.

Вполне красивая схема.

В последнее время вообще рекомендую людям не делать автоматического доступа из радиосети в корпоративную сеть где есть какие-то сервисы с важными данными. А строить wifi сугубо как доступ в интернет и до шлюза где развёрнут VPN сервер в корпоративку.

Связано это с тем, что 802.11 сейчас предмет усиленного расколупывания всякими мезрзкими лицами, и нет гарантий что кто-то не расколупал какую-то врождённую болячку.

Да и просто на мой взгляд логичнее подключаться к корпоративному сегменту только когда там что-то нужно из сервисов. Меньше шансов что через скомпроментированный ПК поимеют и корпоративную сеть. Поработал - отключил VPN ибо нефиг.

Как VPN можно юзать хоть PPPOE+MPPE который умеют вообще все клиенты.

Да, именно про MBSSID я и думал. Хочу сделать два хотспота. Первый для зарегистрированных пользователей, с авторизацией непосредственно в момент подключения к сети (WPA2-EAP). Второй гостевой, без шифрования Wi-Fi и с captive portal.

Цитата: sfstudio от 30/08/2019, 19:10

переход к правильной схеме с например разруливанием доступа в ту или иную подсеть/индивидуальному шейпингу/ и т.д. по данным из радиуса per user на шлюзе.

А каким образом это можно сделать? Точки доступа — это просто транспорт, сервисами они не управляют. Как шлюз определит, что хост с MAC-адресом 11-22-33-44-55-66 — это пользователь, который авторизовался на точке доступа WAP1 под сессией 123456 и логином user/pass?

Цитата: alibek от 30/08/2019, 19:22

Да, именно про MBSSID я и думал. Хочу сделать два хотспота. Первый для зарегистрированных пользователей, с авторизацией непосредственно в момент подключения к сети (WPA2-EAP). Второй гостевой, без шифрования Wi-Fi и с captive portal.

Вообще не очень хорошая идея без шифрования оставлять сеть даже гостевую. Да и вообще делать сеть для гостей и не гостей на одной железке. Все эти MBSSID они от бедности появились.

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

Очень правильное решение появилось сейчас с массовым DUALBAND, никаких гостей в 5ГГц, весь офис все рабочие железки принудительно только в 5ГГц. А у самых правильных железки офисные закупаются централизованно что бы иметь поддержку как минимум K/R. =)

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

Цитата: sfstudio от 30/08/2019, 19:10

переход к правильной схеме с например разруливанием доступа в ту или иную подсеть/индивидуальному шейпингу/ и т.д. по данным из радиуса per user на шлюзе.

А каким образом это можно сделать? Точки доступа — это просто транспорт, сервисами они не управляют. Как шлюз определит, что хост с MAC-адресом 11-22-33-44-55-66 — это пользователь, который авторизовался на точке доступа WAP1 под сессией 123456 и логином user/pass?

А зачем знать с какой АП он пришёл вообще? Хотя мак источника (железки где авторизовался) у нас есть. Мак клиента тоже есть. Имя юзера так же имеется. Прям в запросах всё это летит. Дальше связка с мускулом куда радиус складывает эту инфу при логине и откуда выбираютя данные для настройки чего нужно.

С этим как раз проблем никаких. Из DHCP уже можно узнать какой ему IP присвоен и т.д. и т.п. Т.е. на стороне радиуса есть все данные что бы на L2 чётко идентифицировать клиента в сети и связать его с login name, а дальше уже как фантазия сработает так и поступаем. По сути из исходных данных нам вообще важно только имя пользователя (по которому классифицируется кто он и какие права и обязанности имеет) и его мак.

Ксати тот же абилс вроде как всё это из коробки нынче умеет.

Схем на самом деле существует великое множество.

Но вот самая логичная эт описанная выше. При этом гостей можно прям по маку сразу после авторизации под логином guest рулить на каптив портал в отдельную подсеть ибо нефиг.

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

Я видимо что-то не понимаю.

Вот есть шлюз, который раздает интернет. К шлюзу подключены точки доступа, на точках доступа настроен WPA2-EAP.

К беспроводной сети подключается клиент. Точка доступа принимает запрос клиента, проверяет его через RADIUS, получает положительный ответ и подключает клиента. Клиент в сети и через шлюз получает интернет.

Как шлюз сопоставит клиента (MAC-адрес) с аутентификационными данными (логин), которые получила точка доступа? Шлюз о WPA2 вообще понятия не имеет, он вообще не знает, какой именно транспорт привел кдиента к нему.

Или речь о следующем: RADIUS выгружает в базу данных сессии (в которых содержится MAC-адрес), а затем скрипт получает с DHCP-сервера список лиз, по MAC-адресу находит в БД логин сессии, и затем применяет ACL в зависимости от сервисов абонента? Если так, то схема понятна, но это же жуткий костылинг, еще хуже чем отдельные SSID для гостей и пользователей. Плюс для этой схемы нужен сервер (ПК), ну и работать это будет не онлайн, а с какой-то периодичностью.

Если так, то эта схема мне не подойдет.

Допустим, используется один SSID с WPA-EAP, где пользователи используют свои персональные логины, а гости используют для подключения гостевой логин (например guest/guest). RADIUS при авторизации отдает сервисы, которые соответствуют авторизованному пользователю. Самым удобным мне кажется отдавать VLAN. один VLAN для пользователей, другой для гостей — и тогда на шлюзе разделить пользователей и гостей будет тривиальной задачей. Но как я понимаю, CPE это не умеют. Будь это DHCP, можно было бы отдавать IP-адреса из разных подсетей — но как я понимаю, на этапе подключения к Wi-Fi речь о назначении IP-адресов еще не идет и это сделать невозможно.

Какие вообще RADIUS-атрибуты поддерживает CPE? Может быть я найду что-то подходящее.

Начнём с начала. =)

О радиусе на АП никто не говорил. =)

Совсем не обязательно скрипт там что-то из базы выбирает. Не просто скрипт необязателен но и DHCP сервера могут ходить до радиуса сами, а тот уже до БД.

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

Можно выдавать клиента ip с /32 маской + роуты только куда надо и через что надо. А трафик с авторизованных но не обратившихся к DHCP тупо глушить.

Насчёт костылинга. Вы просто не в курсе как реализуется MBSSID изнутри. Вот там костылинг так костылинг. =)) Те кто это видел забывают это дело и если сильно надо ставят рядом ещё один девайс аппаратный дл "гостей". =)

Причём пускать гостей по всей сети в офисе?  Ну НАФИГ! =)

Особенно весело когда в стройной корпоративной сети приходит гость с кривым клиентом у которого почему-то ACK шлются через раз (например планшеты с RTL8197SU) и идет по офису.  Его прохождение вызывает море радости и сверхкультурных выражений у сотрудников работающих на той же АП но на корпоративном SSID. =)

MBSSID не является чем-то обособленным. Это виртуальная фигня и кривой клиент на любом SSID положит весь интерфейс целиком. При этом при включенном MBSSID отключается часть проверок на уровне RX/TX packet handle (ну не сделать по другому) что безопасности тоже не прибавляет. Я уже не грю о банальнастях, что надо все сервисные вещи выполняемые регулярно выполнять 2жды. Т.е. тормозить работу всех клиентов  (а не только на MBSSID) что бы например послать маячок.

MBSSID это дома  что бы пароли родственникам не сливать. Остальное не для MBSSID.

Что касается атрибутов. В ваших железках и Wive-NG-MT реализована только  аутентификация. Ничего другого там нет.

В 7615 из коробки есть полуживой экаунтинг (выправленный в Wive-NG-HQ). И мной начата реализация ClientDynamicVlan, пока только для старших железок (ну просили неоднократно, время от времени кивиряю, даже как-то работает, но до готовности что бы я выпустил это в паблик пока далековато). SNR ессно в пролёте.

Чем хороша предложенная мной схема - пофигу что юзать лишь бы радиус в каком-то виде умела, а безопасность корпоративных сервисов осущетвляется на стыке wifi и проводной сети на шлюзе.

Т.е. заранее понимаем, что радиосеть не может быть безопасной в силу просто специфики среды передачи и огромного внимания всяких кулхацкеров, да и просто в силу врождённых проблем  коих за 2 года вагон выявлено и сколько ещё выявят. А значит надо переносить средства обеспечения безопасности дальше. На шлюз например. Или как грил до корпоративных сервисов в туннель.

При такой схеме wifi авторизайция через радиус по сути даёт что:
1) возможность индивидуально шейпить
2) возможность пустить или не пустить до шлюза/vpn в корпоративный сегмент
3) возможность зарулить гостей на каптив портал
4) ... по вкусу

Не воспринимайте беспроводный сегмент как что-то защищённое. Не важно какой вариант доступа использован.

А если хочется гостям обеспечить доступ (они же не по всей конторе у вас в наглую ходят) поставить отдельные физические девайсы в точках где он нужен самое верное решение. Хотя сейчас в этом смысла 0. Ну только если не в подвале офис. Т.к. инет от обсосов есть на мобилах у всех гостей и даже недругов. И нечего им в корпоративной сети  делать вообще.

Я, к сожалению видя как это всё работает изнутри давно пришёл к выводу необходимости жёсткого разделения радио и проводных сегментов с отдельным механизмом аутентификации и туннелирования (или хотя бы mac based acl на шлюзе) в корп сеть из беспроводной сети.

А вот изолировать клиентов друг от друга на самом деле достаточно просто на уровне радиоинтерфейса и выдавая /32 маску. Трафик соседа там всё равно подслушать не выйдет не эксплуатируя каких-то дыр в AP, а гостей со сканерами и прочим сам бы с лестницы спустил =))

Т.е. всегда отделяем мух от котлет..  Корпоративная сеть должна оставаться корпоративной сетью.

P.S. Опять же никто не мешает настроить 2MBSSID с EAP, а в запросе видно MAC радиоинтерфейса с которого юзверь пришёл. При этом этот интерфейс засунуть во VLAN.  Будет ровно то что вы хотите и корп и гость сегменты будут разделены вланами. При этом останется возможность всем централизованно рулить с радиуса и управлять на шлюзе  из одной токи. Плюсне будет проблем с шифрованием (ну низя голой оставлять). Причём гостям MBSSID сделать только 2.4 что бы хотя бы работающим в 5ГГц офисникам не мешали. Но это не решает проблемы с кривыми клиентами у гостей гуляющими по тем же физическим интерфейсам гре и работники фирмы.

Да. Случай с DOS атаками на радиосегмент тоже с MBSSID вдвойне "вкусней". Они сводятся чаще всего как раз задержке посылки ACK почти на грани таймаута. И по сути АП и все клиенты на ней тихо курят в сторонке, т.к. АП не может вести передачу пока ждёт подтверждения.

Но для этого надо иметь активное подключение к сети, иначе АП пофигу и обена данными не будет. В случае с гостевой сетью на MBSSID это реализуется на раз плюнуть ибо самое сложное тупо открыто и доступно. А лягут все на этой АП в этом диапазоне, ибо физически в Дуалбэн АП радиомодуля 2. И с добавлением MBSSID новые не отрастают. Т.е. при гостевом доступе в виде MBSSID ваша сеть априори становиться подвержена подобной атаке. И что самое важное, против неё ничего не сделать, вообще ничего.

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

P.S. И даже это ещё не все аргументы. Но я просто чесслово уже устал из года в год одно и то же объяснять. ;)

Мне кажется, что вы говорите о чем-то другом, не о том, что я спрашиваю.

Мне не нужно совместить офисную сеть и посетителей. У меня только хотспот, который никак с офисной сетью не связан. Просто у хотспота есть две категории клиентов — пользователи и гости. Пользователи — это клиенты, у которых имеется персональные учетные данные для доступа к хотспоту (логин и пароль). Гости — это все остальные, логина у них нет, но они могут получить временный доступ по номеру телефона. По MBSSID я понял, забудем пока про него, мне этот способ был интересен потому что с помощью разных SSID очень легко разнести клиентов по разным VLAN.

Вы предлагаете хотспот, на котором Wi-Fi будет только транспортом, а управление доступом (и авторизацией) будет осуществляться на шлюзе (контроллере). Шлюз будет давать сервисы авторизованным пользователям, а неавторизованных заворачивать на страницу авторизации. Раньше я считал такой подход наиболее правильным и такой хотспот у меня уже есть, но практика показала, что у такого подхода есть ряд принципиальных недостатков. Перечислять их не буду, но все сводится к тому, что шлюз не знает заранее статус пользователя и перенаправить пользователя на страницу авторизации не всегда возможно.

Комфортный хотспот — это как домашний роутер, когда пользователь просто подключился к домашней сети и сразу получает доступ к домашним сервисам, без каких-либо дополнительных действий. В домашнем роутере успешное подключение к домашней сети — и есть факт авторизации, никаких дополнительных проверок роутер не выполняет. Поэтому и мне на хотспоте нужно сделать так же — если пользователь подключился к Wi-Fi, значит он уже авторизован и имеет право на получение сервисов. И WPA-EAP с авторизацией по логину/паролю это все идеально решает — во-первых это защищенная зашифрованная сеть, во-вторых это одновременно и аутентификация по логину.

Единственная проблема — я хочу так же сохранить и гостевых пользователей, у которых нет своего постоянного логина/пароля. И пока что я не могу выбрать для этого решение.

Две беспроводные сети с разными именами мне с самого начала казались не очень правильными, независимо от того, будут это физически разные точки доступа или MBSSID. А теперь я против MBSSID я получил дополнительные аргументы.

Было бы идеальным, чтобы точка доступа навешивала на подключившегося клиента какой-нибудь признак, который мог бы проверить шлюз. Тогда я бы навешивал на гостей этот признак, а на роутере в момент обращения к DHCP проверял бы этот признак и гостей бы заворачивал в отдельную подсеть или навешивал отдельные политики.

Но если Wive-NG-MT умеет только аутентификацию без каких-либо дополнительных атрибутов, значит такого признака нет. И единственный способ, чтобы шлюз мог узнать, с каким логином пользователь подключился к хотспоту — это проверять журнал RADIUS. Такой способ мне не кажется правильным и если я не придумаю, что с этим сделать, придется вернуться к разным SSID для пользователей и гостей.

  1. Если это корпоративная сеть и критично что бы люди могли нормально работать, то гостей беспарольных я уже грил выше оставлять чревато независимо MBSSID там или просто доступ. Как только любой левак может авторизоваться, ваша сеть автоматически становиться уявзвима по схеме описанной выше.
  2. что значит не знает? Есть имя в базе? Авторизация по EAP прошла успешно - всё шлюз по DHCP выдаёт адрес из нужной подсети, выдаёт нужные роуты и открывает доступ в FW. Всю жизнь так было. Можно accel-ppp на шлюзе в режиме IPOE заюзать до кучи. Тут как раз проблем вообще никаких. Рекизиты юзверя радису получает с АП при попытке авторизации, т.е. до срабатывания остального. Пары логин пароль и разрешения забиты в базе зарание. Так всю жизнь у всех и работает. Любители винды через радиус вообще интегрят в AD всё это дело.

Я откровенно не понимаю о каком ещё признаке идёт речь и нафиг оно надо. Есть пара логин пароль. В момент авторизации мы узнаём правильно его юзверь ввёл или нет. Пара логин/mac прилетает в БД тогда же. Нет никаких проблем сразу же в DHCP хоть адреса отдельные выдать хоть что-то ещё сделать.

Куда точка этот признак навешать должна? И что за признак? Признак чего? АП это транспорт и только. Она не знает ни о каких признаках или не признаках. И не в Wive-NG такого нет, а нет в принципе. Ибо это не задача АП что-то там навешивать.

Не ну вы можете хоть SSID делать хоть гостей и критичную инфраструктуру мешать в кучу. Моё дело предупредить чем чревато. Что как только гости появляются на те же физических интерфейсах и авторизация для них не уникальная == сразу хапнете проблем. Особенно если это где-нить в ТЦ. И даже если сеть в бункере но позволено произвольным гостям цепляться с их кривыми клиентами в ту же физическую сеть - всё равно с вероятностью далеко не нулевой можете хапнуть проблем.

Гости и критичная рабочая офисная инфраструктура априори должна жить на разных железках физически.

Либо как самый безобидный вариант выдавать каждому гостю временные логин/пароль.

Т.е. так и сяк нужен эдакий мелкобиллинг. А дальше никаких отличий от настройки работы самых обычных IPOE сетей с DHCP сервером и управлением через радиус запросы нет. Вопрос исключительно в логике увязывания данных полученных от АП в момент аутентификации, и данных доступных остальным сервисам.

Для DHCP это будет MAC по которому из базы выбирается юзверь и если для него заданы права доступа куда-то выдаётся один адрес + роут, если нет другой.

Это всё нормальная вполне схема. Ессно придётся для реализации своих хотелок написать свою связку или хотя бы скрутить на изоленту. Так же существуют коммерческие решения аля абилс где за денежку за вас реализуют нужный вам подвыверт такой схемы. Ну если бесплатного варианта не хватит.

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

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

Ну тут могу только посочувствовать вашим работникам в этой корпоративной сети.

Что мешает сделать по человечески установив отдельное железо для гостей в необходимых точках и тупо запихать их в отдельный влан? В 5ГГц для гостей утащить вообще куда-нить на 140+ канал. 2.4ГГц ну придётся подумать и посмотреть с кем на один канал поселить.

Это решает проблему описанную мной на корню с кривыми клиентами и атакой (атакована будет только гостевая точка т.к. рекивзитов доступа до корп АП у атакующего не будет и туда ещё надо будет пробиться как-то). Так и вашу звучащую для меня как "малой кровью, без усилий  поделить юзверей" а заморачиваться очень не хочется, как и платить за готовое решение например тому же абилсу.

И тады на гостевой железке тупо WPA2 с паролем guest (ну не нужно совсем открытую, данные то надо шифровать так и сяк, да и не привлекать мамкиных кулхацкеров, ибо задрючат просто сетку)  и во влан.

 

У меня такое ощущение складывается, что когда я начинаю говорить о безопасности о том что нельзя мешать гостей совсем бесконтрольных (т.е. со статичными парами а не временно выданными) или грю о том что в корп сети вообще не должно быть абы каких левых клиентских устройств по возможности, и даже личные устройства сотрудников допущенные в сеть должны быть номинально ИТ отделом прочеканы что радио в них не кривое и не ставит раком АП (это 802.11 тут такое запросто), то люди думают что я или издеваюсь или черезчур перестраховываюсь.

Ну дык вот. =) Если бы я издевался или параноил, я бы предложил схемы гораздо круче. А вот то что мной тут описано это подходы которые появились после набивания шишек людьми на моих глазах и неоднократно.

Стоит понимать, что корпоративная сеть с доступом к критичным сервисам ещё и с информацией не для всех требует несколько иного подхода чем домашний роутер, и "комфорт" местами должен быть принесён в жертву. А все гости выгнаны поганой метлой с  рабочих АП впринците. Ну или хотя бы так же получать временный логин/пароль на ресепшн при входе. Или групповой логин/пароль на какой-нить сабантуй. Затем всё это должно удаляться.

Но и даже это не решает проблемы нечаянного DOS (пришёл гость с кривым клиентом см выше). Зато как минимум защищает от специального DOS мамкиным кулхацкером с баночной антенной из дома на против. Или из соседнего офиса тупо придурком который по приколу в кали кнопки тычет.

И если вас эта проблема не коснулась пока нигде, то считайте что вам очень везёт и рано или поздно в самый неподходящий момент (когда работникам работать надо и для этого wifi должен быть жив) сеть ваша решит "прилечь однохнуть" балагодаря какому-нить школьнику. Для осуществления большинства DOS атак на 802.11 сегмент достаточно иметь хоть какое-то подключение к физ АП, не важно какой MBSSID не важно что там по шифрованию.

Пустил на АП "гостя" - получи гранату. Ну или как в вашем случае: "гость комфортно поработал - сеть комфортно полежала". =)

2019г на дворе, мамкиных кулхацкеров с инструментами аля "нагадь соседу" развелось не меряно. Как и таких инструментов где часто даже думать не надо.

В общем посмотрел ещё раз внимательно код и доки МТК (учитывая что они сами внятно на простой вопрос так и не ответили пришлось код распутывать) делается там следующее

EAP запрос авторизации прилетевший с WLAN преобразуется в EAPOL (eap over lan) запрос и отправляется радиусу. Содержимое не меняется идёт трансляция 1:1. И так же в обратном порядке.

Т.е. теоретически если радиус способен обработать EAPOL запрос с нужным методом, то и авторизация через WLAN будет работать с этим методом.

Отсюда вывод, что в общем-то поддержан может быть любой механизм EAP ибо это реализуется исключительно на стороне Radius, а не AP которая сугубо только транслирует EAP в EAPOL и назад.

Отсюда вывод. EAP-PWD не заработал т.к. чего-то не хватает/не донастроено на стороне радиуса.

Остаётся маааненький процент что ошибка в трансляции может приводить к поломке конкретного метода. Но глазками пробежался там тупо не где накосячить в части инкапа в OL.

Так же есть и вероятность того, что клиент таки не в должной мере поддерживает данные метод. Если говорить просто то клиент и радиус недоговорились. АП между ними это просто посредник не меняющий ничего в их диалоге и запросах/ответах по сути.

 

Спасибо, хорошая новость.

От PWD я отказался, слишком на многих устройствах его нет. Остановился на PEAP+MSCHAP.

SIM выглядит многообещающе, но похоже на то, что без опсоса не обойтись, там в схеме вроде бы HLR нужен. И вроде бы Мегафон нам как-то присылал предложение по хотспоту с авторизацией по SIM.

Продолжение темы.

Через некоторое время точка доступа начинает работать со странностями. Время, когда начинаются странности, обычно составляет несколько дней. Перезагрузка по питанию приводит в норму (на некоторое время).

1. Уровень сигнала порядка -60, в эфире есть еще пара сетей с таким же уровнем и одна с уровнем -30. Подключиться к сети со смартфона не удается — при попытке подключения уровень тут же падает до нуля (сеть пропадает), смартфон от сети отключается, затем уровень сети снова возвращается к норме. Часто напротив сети смартфон пишет статус «Выключено» — это когда он несколько раз пытался подключиться, попытки были неуспешными и он пометил сеть как отключенную, чтобы не подключаться.

2. На айфоне также подключение к сети не удается, но с несколько другими симптомами. Сеть он видит, пытается подключиться (показывает слева от сети вращающийся значок ожидания), но безуспешно, независимо от времени ожидания. Уровень сигнала показывает высокий (три деления из трех). Но на точке доступа я этот айфон вообще не вижу. Ниже привожу фрагмент лога — на точке доступа я отключил 5 ГГц (на всякий случай), затем с андроидом (cc:61:e5:0f:54:4a) и айфоном (c4:61:8b:38:8c:ff) подошел к точке доступа и одновременно выключил и включил Wi-Fi. Андроид подключился сразу, а айфон не подключается.

Sep 16 15:54:33 roaming: Tune wifi handoff parametrs for ra0 2.4GHz mask: 3;0;0;-70;0;-78;-80;-82;60;-76;14
Sep 16 15:54:33 roaming: Tune wifi handoff parametrs for rai0 5GHz mask: 3;0;0;-83;0;-91;-93;-95;60;-89;14
Sep 16 15:54:33 services: Restart needed services and scripts. Mode all
Sep 16 15:54:33 QoS: Stopping SHAPER
Sep 16 15:54:34 QoS: Set default rules.
Sep 16 15:54:34 Codel: QoS Add codel for all interfaces.
Sep 16 15:54:34 iptables: Add netfiler rules
Sep 16 15:54:34 iptables: Allow established/related in input
Sep 16 15:54:34 iptables: Drop invalid state connections
Sep 16 15:54:34 iptables: Service limit set
Sep 16 15:54:34 iptables: Set igmp input rules
Sep 16 15:54:34 iptables: DHCP server allow
Sep 16 15:54:34 iptables: 802.11f daemon allow to connect
Sep 16 15:54:34 iptables: Dnsproxy allow to connect
Sep 16 15:54:34 iptables: Remote managment web limit
Sep 16 15:54:34 iptables: Remote managment ssh limit
Sep 16 15:54:34 iptables: Remote managment telnet limit
Sep 16 15:54:34 iptables: Allow rate limited ping from all interfaces.
Sep 16 15:54:34 iptables: Allow established/related in forward
Sep 16 15:54:34 resolv: Generate resolv DNS1: 10.101.0.250 DNS2: 
Sep 16 15:54:34 resolv: Install ipv4 DNS servers to local resolv.
Sep 16 15:54:35 dnsserver: Generate /etc/hosts file.
Sep 16 15:54:35 dnsserver: Send HUP to dnsmasq.
Sep 16 15:54:35 dnsmasq[1022]: read /etc/hosts - 5 addresses
Sep 16 15:54:35 dnsmasq[1022]: using nameserver 10.101.0.250#53
Sep 16 15:54:35 ntp: Stopping NTPD
Sep 16 15:54:35 ntp: Starting NTPD
Sep 16 15:54:36 kext: Nat mode Linux Hybrid
Sep 16 15:54:36 kext: NAT Offload mode not supported in this device mode (bridge/apclibridge/etc), hw_nat and all fastpaths disabled.
Sep 16 15:54:36 kext: Enable multicast to unicast conversion for rai0 ra0
Sep 16 15:54:36 iappd: Stopping 802.11f roaming daemon
Sep 16 15:54:37 iappd: Starting iappd 802.11f daemon
Sep 16 15:54:37 iappd[5349]: iapp> IfName[0]: ra0
Sep 16 15:54:38 inetd: Stopping inetd
Sep 16 15:54:38 inetd: Starting inetd
Sep 16 15:54:38 transmission: Not any disk connected.
Sep 16 15:54:38 dhcpd: DHCP server disabled. OPMODE=0 APCLIBR=0
Sep 16 15:54:39 apd: Starting apd radius daemon for 2.4GHz
Sep 16 15:54:39 syslog: Ralink DOT1X daemon, version = '3.0.0.0' 
Sep 16 15:54:39 syslog: Main Interface name = 'ra0'
Sep 16 15:54:39 irqbalance: Stopping irqbalance
Sep 16 15:54:40 irqbalance: Start irqbalance routing/wifi optimize mode
Sep 16 15:54:40 irqbalance: Start irqbalance auto mode
Sep 16 15:54:45 kernel: br0: port 1(eth2) entered forwarding state
Sep 16 15:54:46 nginx: 2019/09/16 15:54:46 [info] 3631#0: *88 client 10.1.144.3 closed keepalive connection
Sep 16 15:54:47 kernel: br0: port 2(ra0) entered forwarding state
Sep 16 15:54:47 kernel: br0: port 3(rai0) entered forwarding state
Sep 16 15:55:54 kernel: ASSOC - Assign AID=1 to 2.4GHz AP cc:61:e5:0f:54:4a
Sep 16 15:55:54 kernel: ASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Sep 16 15:56:45 kernel: 2.4GHz AP AUTH - receive DE-AUTH(seq-906) from cc:61:e5:0f:54:4a, reason=3
Sep 16 15:56:46 nginx: 2019/09/16 15:56:46 [info] 3631#0: *110 client 10.1.144.3 closed keepalive connection
Sep 16 15:56:49 kernel: ASSOC - Assign AID=1 to 2.4GHz AP cc:61:e5:0f:54:4a
Sep 16 15:56:49 kernel: ASSOC - HT support STA. Update AP OperaionMode=0, fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Sep 16 15:56:56 nginx: 2019/09/16 15:56:56 [info] 3631#0: *111 client 10.1.144.3 closed keepalive connection

 

Через некоторое время точка доступа начинает работать со странностями. Время, когда начинаются странности, обычно составляет несколько дней. Перезагрузка по питанию приводит в норму (на некоторое время).

Key Renewal Interval  и Session Timeout в настройках безопасности  оба не 0 и не больше суток?

1. Уровень сигнала порядка -60, в эфире есть еще пара сетей с таким же уровнем и одна с уровнем -30. Подключиться к сети со смартфона не удается — при попытке подключения уровень тут же падает до нуля (сеть пропадает), смартфон от сети отключается, затем уровень сети снова возвращается к норме. Часто напротив сети смартфон пишет статус «Выключено» — это когда он несколько раз пытался подключиться, попытки были неуспешными и он пометил сеть как отключенную, чтобы не подключаться.

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

2. На айфоне также подключение к сети не удается, но с несколько другими симптомами. Сеть он видит, пытается подключиться (показывает слева от сети вращающийся значок ожидания), но безуспешно, независимо от времени ожидания. Уровень сигнала показывает высокий (три деления из трех).

Ни о чём не говорит. Тестить телефонмобильными клинетами == гадалок завать. И если на андроиде в тех же aruba utilites можно лог глянуть хотя бы что ему не нравиться (кстати стоит поставить) то на яблоках кроме ванги никто не поможет

Но на точке доступа я этот айфон вообще не вижу. Ниже привожу фрагмент лога — на точке доступа я отключил 5 ГГц (на всякий случай)

Не отключать надо на всякий, тем более что после любой манипуляции с настройками сразу привет сброс всех временных данных т.к. драйвер радио будет полностью перезагружен. А проверять другим клиентом которого ещё не было в этой сети отдельно по бэндам. Потом тем на котором проблемы отдельно по бэндам. Это может дать какую-то доп инфу.А лезть сразу крутить что-то - привет сбросу состояния в исходное.

, затем с андроидом (cc:61:e5:0f:54:4a) и айфоном (c4:61:8b:38:8c:ff) подошел к точке доступа и одновременно выключил и включил Wi-Fi. Андроид подключился сразу, а айфон не подключается.

Сессия на радиусе поди висит и всё. Или на радиусе сессия умерла по таймауту,  а на АП осталась в кэше Вариантов миллион.

В логе ничего интересного нет. Да и неоткуда взяться т.к. приведён с момента отключения второго бэнда. Т.е. предыстория вся удалена по сути.

А вот конфиг который мог что-то прояснить отсуствует.

В кратце.
1) У себя ничего подобного не наблюдал не разу.
2) ИМХО копать в сторону длины сесси и залипших сессий радиуса
3) ставить аруба утилиты и смотреть на что ругается т.е. что именно не проходит в этот момент
4) ещё лучше с ПК под *nix пробовать повторить с wpa_supplicant в дебаг режиме

Но на правах гадалки эт именно где-то сессия залипла.

В обозримом будущем у меня не будет возможности найти время попробовать повторить это всё на MT. Море работы по актуальным железкам и ПО.

Однако на подопечных сетях с авторизацией через радиус на MT ничего подобного не наблюдается. Т.е. кроме предположений выше (исходя из данных слабо подходящих для какой-либо диагностики) увы больше как-то ничего в голову не приходит.

Hadoff кстати вырубить для чистоты эксперимента. Это всё же костыль и побочка может быть очень разная. Использовать его стоит только для страховки на уровнях когда уже нормальной работы быть не может для отстрела залипших клиентов. Особенно в схемах с K/R и WPA Enterprise. В идеале клиентов использующих R хэндофф вообще не должен трогать.

Key Renewal Interval = 3600, Session Timeout = 0 (дефолтные значения).

На уровень тут можно забить.

Ок.

Не отключать надо на всякий

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

Сессия на радиусе поди висит и всё.

Нет. Я параллельно смотрел логи RADIUS-сервера. В случае с андроидом все отрабатывало, в случае с айфоном тишина, к RADIUS вообще не было обращений.

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

Но вот проблема с подключением к точке доступа, когда уровень сигнала низкий, остается. Но опытным путем выяснил, что проблема зависит не столько от уровня сигнала, сколько от прямой видимости. Если есть прямая видимость, то даже со слабым уровнем телефон скорее всего подключиться без проблем. А если прямая видимость чем-то перекрыта, то даже при не таком уж слабом сигнале (например -60) есть проблема с подключением, телефон пытается подключиться и тут же отключается.

Может быть ME1 не хватает чувствительности и при наличии перекрытий это точка доступа теряет клиента, а не клиент точку доступа?

handoff попробую отключить.

Уровни надо с обоих сторон смотреть. О настойках handoff уже сказал.

Ну и сеть нужно так планировать что бы в любой точке пространства где требуется покрытие была прямая видимость хотя бы на одну АП.

Далее. RSSI это пол беды. ХЗ что там по SNR в конкретных точках. Т.е. чувствительность может быть офигенная, но это никак не поможет улучшить SNR. А важен для корректного декодирования именно SNR, а не RSSI.

Собсно поэтому сеть обычно зонируется, т.е. вместо ОМНИ применяются потолочки и сектора, и обеспечивается равномерное покрытые установкой нужного числа штук, а не одна железка на десятки метров по прямой на омни которая весь мусор вокруг соберёт.

Запросто уровни могут быть в потолок, но Rx тракт утопает в мусоре собираемом ОМНИ со всех сторон. И на фоне этого мусора полезного сигнала (с того самого клиента) может оказаться запросто не достаточно что бы обеспечить нужный SNR на стороне АП для декодирования. И хоть заувеличивайся чувствительность.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: