LINUX.ORG.RU

OpenWRT (Ralink RT5350F) и работа с драйвером wireless

 , , ,


0

1

Доброго ночера уважаемый All. Есть желание ввести в работу роутера понятие минимально-допустимого для клиента(!) уровня сигнала... Из чего исходим: Подключаемся ноутом к роутеру, лежащему на ноуте, в консоли делаем:

watch -n 1 'iwconfig wlan0 | grep Qual'
Видим магические числа:70/70 -20 Уже по этим цифрам появляются вопросы: Первое упоминание 70 - та самая мощность/уровень сигнала? Предположил, что «да» и дальше от этого отталкивался. Второе упоминание /70 - это что? -20 это уровень шума?

Гуляя с ноутом в пределах помещения экспериментальным способом получаем, что 32/70 -60 соответствуют самой дальней точке внутри помещения.

И наконец предположение, взятое за основу для дальнейших действий: первая цифирь это и есть тот самый уровень сигнала, который в различных осях рисуется палочками/черточками. Исходя из наших реалий, за мин.допустимый уровень можно принять значение 30 (попугаев?).

Маленькое отступление: нужно «мониторить» уровень сигнала существующих «клиентов» + не давать подключаться новым, у кого меньше. Выворачивать задачу, изначально уменьшая мощность передатчика, не предлогайе пож. Эта возможность была изучена и отброшена.

Далее, долго копаясь в различных источниках полуслучайно удалось набрести на: ./src/rt2860v2/ap/ap.c в котором нашлась функция: MacTableMaintenance. Далее совсем уж на интуитивном уровне были произведены след.действия: В самом начале кода из ap.c была добавлена переменная:

#include "rt_config.h" 
int LowLevelSignal_ap = 55; /*55 а не 30 было поставлено для облегчения тестирования - меньше бегать с ноутом от роутера*/

Далее, в теле упомянутой функции, была добавлена проверка:

if (pEntry->RssiSample.LastRssi0 < LowLevelSignal_ap)
bDisconnectSta = TRUE;

Выполнив make clean; make получил прошивку, которую не постеснялся залить на роутер. Далее снова тесты: Подключаюсь к роутеру по wi-fi, открываю в одной консоли вотч качества, во второй ping в мир и бреду в даль. После того как качество падает до 54/70 -48 пинги начинают теряться чаще, чем проходить, но - проходят. Смотрим с другой стороны (telnet'ом в логи роутера) и видим, что наш ноут, по выходу в «< 55» зону начинает постоянно дисконектиться, и снова конектиться! От 3х до 6ти таких записей в секунду!

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

Или нет? Собственно, тут я пока что и замер. Ибо недостаточные знания английского не позволяют бегло искать по просторам нерунета необходимую документацию, а слабые познания в Си (все еще преобретаемые благодаря творению Кернигана и Ритчи в 3тьем издании) не служат достаточным подспорьем для самостоятельного аализа исходников драйверов...

Вопрос у меня к тебе, многоуважаемый All: похож ли вышеизложенный поток сознания на правду? Если да, то где мне дальше искать точку входа клиента? В каком файле описывается инициализация именно клиента, а не передатчика например? А то я уже разок промахнулся, благо по шнурку смог зайти и перепрошиться/откатиться. А если все это чуш и притянутые за уши совпадения, то в какую сторону мне изначально смотреть нужно было?

И на последок, встретилась мне такая вот штука:

BOOLEAN bAutoRoaming;	/* 0:disable auto roaming by RSSI, 1:enable auto roaming by RSSI */
А в ./src/rt2860v2/include/mlme.h
#define RSSI_THRESHOLD_FOR_ROAMING 25
Правка значения до 69ти результата не принесла. Во множестве исходников встречается #ifdef перед проверкой if (bAutoRoaming)... Я выдумываю велосипед, вместо того чтоб просто подключить готовый функционал, либо это какой-то другой роуминг, не относящийся к моей задаче???

Sorry за сумбур в описании, готов ответить на уточняющие вопросы...


Странный у вас вывод iwconfig, там, вроде как должны быть названия параметров и они описаны в man'е. То, что у вас 32/70 это качество сигнала, как оно вычисляется драйвер решает сам, может на основании кол-ва пакетов с неправильной контрольной суммой, может ещё как. Но, в общем случае это качество определяется в процессе обмена данными, на момент подключения его как-бы нет, так как нет достаточного количества переданных/принятых пакетов. По идее, при подключении клиента есть только уровень сигнала. Хотя исходники вашего драйвера я не смотрел, может там при подключении клиента есть каким-то образом качество сигнала.

Роуминг вам не поможет, там, если я не путаю, клиента не отключают, а советуют переключится на другую точку доступа, а у вас всего одна точка.

P.S. А вы на англ. читать умеете? Там обычно в исходном тексте достаточно полезные комментарии.

mky ★★★★★
()
Ответ на: комментарий от mky

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

Читая Ваш ответ и вспоминая некоторые доки с просторов инета, снова задался вопросом: а в ту ли сторону я копаю... Суть изначальной задумки - смотреть уровень сигнала, тобиш - мощность приходящего сигнала, тобиш - привязаться не к агрегатно-абстрактному уровню, учитывающему шумы/потери/прочь. заумности, а к «относительно-прозрачному» уровню мощности... В моем понимании сути вопроса сформировалось такое: есть параметр TXPower, при помощи которого можно ограничить мощность передатчика. В каждый конкретный момент времени можно измерить текущую «Power» сигнала, приходящего от клиента... Получается, что я изначально смотрю не на тот параметр, перепутав Rssi0 с Power? И тут же вопрос, а существуют ли инструменты по мониторингу этой самой мощности (Client Transmit Power) или единственное идеологически-верным направлением является мониторинг/анализ конструкции Rssi(0,1,2)? С точки зрения физики (без учета логических составляющих таких как шум и помехи): мощность может же меняться? Или в работе wi-fi этот параметр упразднен за ненадобностью, из разряда - избыточно сильный срежется, а слабый не добьет??

Совсем запутался, и так не знал в какую сторону копать, а теперь еще хуже стало)) Почему так сильно хочу привязаться к мощности - дабы иметь возможность с самого начала, на этапе подключения нового устройства, замеррить уровень приходящего сигнала, «сравнить» его с «эталоном» и решить - давать доступ, али нет... в случае с агрегатными показателями такая схема не состоятельна по определению, ибо пока будут накапливаться кадры в достаточном для получения avg значения кол-ве, клиент уже успеет авторизоваться, получить ip и прочее... Задумка же всего этого балета сводилась к обратному - не потратить ни одного лишнего тика ЦП роутера на «удаленного» клиента...

Надоумьте меня кто-нибудь, продолжать смотреть в сторону Rssi (если да, то на сколько правильным является сравнение с Rssi0, а не Rssi2) или есть возможность выполнить все это на AironetCellPowerLimit/Set_TxPower_Proc механизмах??!

nk_lg
() автор топика
Ответ на: комментарий от nk_lg

В целом сигнал RSSI - это относительный показатель, который зависит от производителя чипа, в интернете много документации на эту тему с ругательствами, что у одних чипов сигнал можно снять с 0.5Дб погрешностью, а у других вообще от фонаря значения. Но, если есть калибровочные данные, то можно привести всё это под общий знаменатель. В целом, если мы смотрим compat-drivers, нужно смотреть непосредственно mac80211 и в нём ковыряться с параметрами сигнала.

nickleiten ★★★
()
Ответ на: комментарий от nickleiten

Спасибо, вектор получил - попробую разобраться... Калибровку я действительно упустил совсем!

nk_lg
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.