How to Fix Slow GPS Lock on Mediatek MT65xx based Smartphones
I’ve recently purchased ThL W200, an Android 4.2 smartphone powered by Mediatek MT6589T quad core processor, and I’m trying to test a few things including GPS. I’ve enabled access to my location, GPS, and Google’s location service using Wi-Fi and mobile network.
In Google Maps, I could get a somewhat accurate position thanks to mobile network location, but it was clear it could not lock GPS. I’ve also tried Nike+ Running, an application that keeps track of your running sessions with GPS, gives you some audio feedback as you run (distance, time and speed), and compares your performance to the average, and your social network friends. When I wanted to start running, the app complained about weak GPS signal, and tried to lock GPS for about 10 minutes, until I decided to give up.
So I tried to find a solution, and Google pointed me to an article on Gizchina explaining how to fix poor GPS in Mediatek phones. I followed the instructions, and amazingly Nike+ Running can now find my position with GPS within 5 to 10 seconds. Here’s what you have to do.
When I tried in Nike+ Running, first the GPS slider in the application was red, the system GPS icon blinked at top left corner, and within a few seconds, GPS was properly locked, and I could start my run. At the end of the run, it showed a map with my run, and I could see it followed the roads and paths where I ran accurately.
I always thought A-GPS would do what EPO just did here, so let’s have a closer look at what both are supposed to do.
What is A-GPS?
Assisted GPS (A-GPS) is a system that can, under certain conditions, improve the startup performance or time-to-first-fix (TTFF) of a GPS satellite-based positioning system by downloading positioning data from the network. There are two modes of operation:
Mobileuncle MTK Tools reports A-GPS is enabled in my phone and uses MSB. There are also quite a few others options for A-GPS such as Control Plane and User Plane switching, SLP (SUPL Location Platform) settings, and more things that currently do not make much sense to me.
What is EPO?
EPO (Extended Prediction Orbit) provides file downloaded by the GPS device to help it locate GPS satellites more quickly and reduce the Time To First Fix. I can find very little information about EPO, but it seems it’s a solution developed by Mediatek, and just another A-GPS type of solution. It appears some phones have access to EPO directly within the Android Settings, which was not the case for my phone.
So A-GPS and EPO appear to be very similar, and EPO may just be another A-GPS technique, but for some reasons A-GPS provides poor results in Mediatek phones, whereas if EPO is enabled, GPS will lock within a few seconds.
If GPS specialists among my readers could give some more extra information, it would be very nice. Thanks!
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Точка и контроллер находятся в разных подсетях. Использую опцию 43 для обнаружения контроллера.
Проблема: Точка обнаруживает контроллер, но контроллер не регистрирует точку.
Логи с контроллера:
*spamReceiveTask: Feb 20 05:50:04.288: f0:f7:55:b9:e2:63 Discovery Request from 192.168.38.51:40487
*spamReceiveTask: Feb 20 05:50:04.288: f0:f7:55:b9:e2:63 Join Priority Processing status = 0, Incoming Ap’s Priority 1, MaxLrads = 25, joined Aps =0 *spamReceiveTask: Feb 20 05:50:04.288: f0:f7:55:b9:e2:63 Discovery Response sent to 192.168.38.51:40487
*spamReceiveTask: Feb 20 05:50:04.288: f0:f7:55:b9:e2:63 Received LWAPP DISCOVERY REQUEST to 54:75:d0:06:b4:60 on port ‘1’ *spamReceiveTask: Feb 20 05:50:04.288: f0:f7:55:b9:e2:63 Discarding discovery request in LWAPP from AP supporting CAPWAP
Про последнее сообщение видел мнение, что это нормально, и «The AP will join the controller in CAPWAP after the maximum number of retries in LWAPP.» Но у меня точка уже наверно час пытается безуспешно прицепиться к контроллеру.
Да, в таком случае ваша точка попадет в мое управление.
Сделал на интерфейсе влана точек доступа:
*Feb 20 10:20:35.496: f0:f7:55:b9:e2:63 Discovery Request from 192.168.38.51:40487
*Feb 20 10:20:35.496: Unknown vendor-specific message 0x0005 from AP F0:F7:55:B9:E2:63
*Feb 20 10:20:35.496: f0:f7:55:b9:e2:63 Failed to validate vendor message element length F0:F7:55:B9:E2:63
*Feb 20 10:20:35.496: f0:f7:55:b9:e2:63 Decoding WTP vendor specific message element failed
*Feb 20 10:20:35.496: f0:f7:55:b9:e2:63 Join Priority Processing status = 0, Incoming Ap’s Priority 1, MaxLrads = 25, joined Aps =0 *Feb 20 10:20:35.496: f0:f7:55:b9:e2:63 Discovery Response sent to 192.168.38.51:40487
*Feb 20 10:20:35.496: f0:f7:55:b9:e2:63 Received LWAPP DISCOVERY REQUEST from AP f0:f7:55:b9:e2:63 to 54:75:d0:06:b4:60 on port ‘1’ *Feb 20 10:20:35.496: Received a packet which is a (type = DISCOVERY_REQUEST) with session id 0
*Feb 20 10:20:35.496: Discarding discovery request in LWAPP from AP f0:f7:55:b9:e2:63 supporting CAPWAP
Часовой пояс: UTC + 3 часа
Кто сейчас на конференции
Сейчас этот форум просматривают: Google [Bot] и гости: 25
Добрый день! Не работает подключение к OpenVPN серверу? при подключении клиента Openvpn выдает ошибку:
WWRMon Sep 24 14:51:20 2012 us=216858 89.254.252.37:19387 TLS Error: Cannot accept new session request from [AF_INET]89.254.252.37:19387 due to sessi$
RMon Sep 24 14:51:22 2012 us=416852 89.254.252.37:19387 TLS Error: Cannot accept new session request from [AF_INET]89.254.252.37:19387 due to session$
эти ошибки бы полностью увидеть.
;Объявление маршрутов на клиентские сети
route 192.168.7.0 255.255.255.240
по моему должно быть так:
route я пока все за комментировал.
Еще стоит обратить внимание на
в razdolje прописаны route, но я их все закомментировал для проверки, ошибку победил отключив параметр ccd-exclusive в server.conf, после этого стало подключаться, но не идут пинги до сервера VPN пингуется только выданный клиенту ип адрес, пока разбираюсь.
итого ip route после установления связи с openVPN в студию.
в razdolje прописаны route, но я их все закомментировал для проверки,
что за бред? в этом конфиге обычно прописывается статический ip адрес клиента. примерно в таком виде:
Содержание файла razdolje:
При подключении к vpn ip адрес с маской назначается клиентской машине от «балды», хотя в файла razdolje указано ifconfig-push 192.168.7.197 192.168.7.198, может на это влияет опция ccd-exclusive?
у тебя дефолтный gate, если не ошибаюсь:
а должен быть 192.168.7.192, тода всё запингуется.
должно все работать как часы.
Хорошо попробую, дело в том что похоже файлик razdolje не цепляется openvpn сервером, в нем я изменял ип адреса, но при подключении он всеравно ставит не те, которые указанны в файле razdolje ifconfig-push.
пару раз с таким сталкивался, помогала повторная генерация пользовательского сертификата. только не следует генерировать сертификат с таким же именем пользователя, в твоём случае попробуй сгенерировать сертификат razdolje1, соответственно создай файл /etc/openvpn/clients/razdolje1.
Создал новый сертификат test и конфигурационный файл нему, настройки стали подключаться. Шлюз стал openvpn сервер, пинг до подсети 192.168.7.0 / 255.255.255.224 пошел. Но не идет пинг на другие подсети например 192.168.0.0 / 255.255.255.0.
В файле test2 указываю push route 192.168.0.0 255.255.255.0, в route print маршрут появляется, по команде tracert 192.168.0.1 1: идет шлюз openvpn, а далее идет превышение интервала ожидания.
Если ты хочешь передать клиенту маршруты автоматом, то пиши в конфиге сервера
test2 это файл конфигурации клиента test2, я создал новый ключ, push route я указал, но пинги до указанной сети все равно не идут.
Создал новый сертификат test и конфигурационный файл нему
test2 это файл конфигурации клиента test2
как то нескладно получается. Какое в результате имя у клиента?
Где? в серверном конфиге?
а что за интерфейс tun1, кстати?
Да форвардинг установлен, tun1 это впн к другому серваку, подозреваю что в фаервал на сервере нужно правила добавлять, если выставляешь основным шлюзом впн, то перестает инет работать.
да push route указан на сервере в файле test2
Всё разобрался, добавил нужный маршрут route на впн сервере 1 и пинги пошли. Теперь другая проблема, не пингуется сеть за клиентом, причем если клиент подключен через XP, то сеть пингуется, а если через Win7?, пинги не идут, брандмауэр отключил, все равно не помогло, кто-нибудь сталкивался с такой проблемой?
Проблему решил, оказалось не была включена служба маршрутизации на клиентской машине.
HotSpot с помощью Cisco WLC5508, FreeRadius, MySQL и Easyhotspot
Эта статья о том, как создать и настроить HotSpot. При этом мне хотелось подробно описать, как это выглядит изнутри и сделать упор на работу freeRadius, MySQL и простого биллинга Easyhotspot.
Итак, наша система будет строиться на Cisco WLC5508 и CentOS. Чтобы понять как это все между собой взаимодействует, посмотрим на схему.
Начинается все с сервиса Easyhotspot, по сути это биллинг, который управляется через веб-интерфейс. Это open-source проект и главное его преимущество в том, что он прост для понимания и управления.
С помощью него мы генерируем username и password, которые записываются в базу данных MySQL и передаются для пользования юзеру. Далее пользователь подключается к нашей точке доступа, которая управляется контроллером Cisco WLC. При попытке открыть какую либо страницу в браузере, юзера перекинет на страницу авторизации, где он введет полученные креденциалы.
После этого контроллер их перехватит и в сообщении access-request отправит для проверки серверу авторизации FreeRadius’у. Тот обратится к базе данных, найдет соответствующие логин и пароль, и ответит вай-фай контроллеру, что все ок, при этом выдаст время в течении которого пользователь может быть активен. В терминологии RADIUS, вай-фай контроллер Cisco WLC является для радиус-сервера NAS-клиентом (Network Access Server), в терминологии hotspot этот сервис так же называется captive portal. Задачей этого сервиса является показать пользователю окно авторизации, передать креденциалы радиус-серверу, получить ответ с атрибутами и адекватно их обработать.
И хоть Easyhotspot изначально разрабатывался для работы с captive portal, который называется Chillispot, нам в сущности это неважно. После того, как пользователь был авторизован, NAS должен в течении пользовательской сессии отправлять радиус-серверу отчеты об использованных юзером ресурсах: количество времени, трафика и тп. Все это дело freeRadius будет логировать в базу данных. А при следующей попытке подключиться, для юзера будет вестись проверка сколько он чего потратил и сколько этого чего ему осталось доступно.
Вспомним, что такое Radius. Это протокол, который условно делистя на две части, это аутентификация/авторизация и аккаунтинг. Первую описывает RFC 2865, вторую RFC 2866. О том, что они работают раздельно говорит и то, что сервер принимает для них запросы на разных портах 1812 и 1813.
Далее мы подробно разберем, как выглядят запросы и ответы, и то, как они обрабатываются FreeRadius’ом, а сейчас приступим к установке. Предположим, что у нас есть сервер CentOS 6.5 с настроенной сетью и доступом в интернет. Установим программу для скачивания файлов из сети:
Загрузим и установим репозиторий:
Обновим репозиторий и установленные программы:
Установим полезные утилиты, MySQL, Apache и php:
В файле /etc/php.ini нужно раскомментировать строку:
Если забыть об этом параметре, то при попытке открыть страничку биллинга будет появляться такое сообщение:
Там же в файле /etc/php.ini:
Сделаем так, чтоб MySQL и Apache после загрузки системы запускались автоматически:
В EasyHotspot в меню присутствует страничка Chillispot. Когда мы будем нажимать на нее, мы увидим ошибку. Чтобы избежать этого, удалим ее. Для этого нужно удалить или закомментировать следующие строчки в файле /opt/EasyHotspot/htdocs/system/application/views/admin/header.php:
Установим phpMyAdmin, это своего рода GUI для MySQL, поможет нам в изучении таблиц:
Установка и настройка FreeRadius
Устанавливаем фрирадиус, поддержку mysql и утилиты, которые помогут нам в тестировании системы:
Сделаем так, чтоб freeradiu после загрузки системы запускался автоматически:
В файле /etc/raddb/clients.conf в секции “client localhost“ нужно сделать следующее:
В файле /etc/raddb/radiusd.conf в секции “module” раскомментировать:
В секции “instantiate“ добавить:
В файле /etc/raddb/sites-enabled/default в секции “authorize” расскомментировать “sql” и добавить «noresetcounter»:
Затем /etc/raddb/sites-enabled/default в секции “accounting” расскомментировать “sql”:
Затем /etc/raddb/sites-enabled/default в секции “session” расскомментировать “sql” и закомментировать «radutmp»:
И затем /etc/raddb/sites-enabled/default в секции «post-auth» расскомментировать “sql”:
В файле /etc/raddb/sql/mysql/counter.conf в конце уже определен счетчик «noresetcounter», мы его подредактируем:
В файле /etc/raddb/sql/mysql/dialup.conf для работы с Simultaneous-Use раскомментируем следующее:
В файле /etc/raddb/sql.conf в секции «sql» сделаем так:
Настройка Сisco WLC
Подключаем Radius-сервер к WLC: SECURITY->Authentication. SECURITY->Accounting. При настройке нужно ввести IP и Shared Secret.
Настраиваем редирект с помощью которого неавторизованный пользователь при запросе любой страницы будет перенаправлен на страницу авторизации, где нужно ввести логин и пароль.
Настраиваем access-list. Дело в том, что когда пользователь подключается к SSID, всего его запросы из веб-браузера редиректятся на страницу авторизации, но кроме этого его по сути ничего не ограничивает.
Мы должны создать ACL, который разрешит пользователю доступ только к нашей странице авторизации и никуда больше.
Создаем SSID, на вкладке Security->Layer 2 выбираем None. На вкладке Security->Layer 3 выбираем Web Policy — Authentication, в выпадающем списке Preauthentication ACL выбираем наш созданный ранее ACL.
Выбираем из выпадающего списка ранее добавленный сервер радиуса.
Осталось донастроить радиус. Добавим IP-адрес нашего WLC и secret vi /etc/raddb/clients.conf
Теперь по адресу х.х.х.х/easyhotspot доступна страница авторизации:
Логин: admin Пароль: admin123
На веб-интерфейсе нам доступно два основных меню [ Cashier Menu ] и [ Admin Menu ].
В Admin Menu мы можем создать Billing plan и Account plan, чтобы на основе них генерировать логины/пароли. Создадим биллинг план на час, при этом сгенерированный на его основе ваучер будет действителен до конца следующего дня с момента создания(Valid for = 1), а Idle Timeout сделаем 5 мин.
Протестируем нашу систему. С помощью утилиты radtest мы отправим радиус-серверу запрос на авторизацию таким образом как это делает NAS. Используем сгенерированные логин/пароль, ‘easyhotspot’ это secret в файле /etc/raddb/clients.conf:
Здесь у вас может возникнуть ошибка:
Связана она с тем, что при отправке радиус-пакета утилита пытается резолвить имя сервера, чтобы добавить в NAS-IP-Address. Если имя не localhost, нужно добавить его в /etc/hosts. Итак:
Мы видим, что наша авторизация прошла успешно, при этом мы в ответ получили набор атрибутов:
В поле User-Name = «» не забывайте указывать ваш username.
В поле User-Name = «» не забывайте указывать ваш username.
С помощью утилиты radclient мы отправим радиус-серверу пакет аккаунтинга Start.
Видим нашего юзера и время начала сессии. Теперь отправим пакет аккаунтинга interim-update. В этот раз в пакет добавляются новые атрибуты:
Посмотрим Online Users.
Теперь мы видим, что юзер потратил из отпущенного ему часа 11 секунд и 1874 байта. Отправим пакет аккаунтинга stop.
Видим, что у нашего пользователя осталось 59 мин. Время округлилось, но это только в биллинге, freeRadius считает с точностью до секунды. Проверим:
Как можно догадаться из полученного ответа, freeRadius от изначально заданного значения 3600 отнял потраченные юзером 30 и вернул нам 3570. Давайте теперь пошлем пакет начала сессии аккаунтинга.
И заново попробуем авторизоваться, представив что пользователь, получив доступ дал свои креденциалы другу.
FreeRadius получил наш пакет и первым делом запустил секцию authorize, описанную в файле /etc/raddb/sites-enabled/default В квадратных скобках показаны модули, которые поочередно обрабатывают наш запрос.
Итак, мы видим, что при обработке пакета авторизации и аутентификации freeRadius работает с шестью таблицами:
Рассмотрим процесс обработки пакета Interim-Update. Запускается секция preacct, описанная в файле /etc/raddb/sites-enabled/default:
Рассмотрим таблицы в базе данных MySQL
По адресу х.х.х.х/easyhotspot/phpmyadmin мы можем увидеть наши таблицы с помощью GUI. Переходим в БД easyhotspot_opensource. Нас будут интересовать семь вышеперечисленных таблиц с которыми работал freeRadius:
Рассмотрим каждую в отдельности, начнем с radcheck.
Тут мы видим две строки для нашего юзера. В первой с помощью атрибута Cleartext-Password для него задается пароль, а во второй с помощью атрибута Expiration дата по истечению которой креденциалы перестают быть действительными.
Как мы видели в логах дебага атрибут с паролем обрабатывает модуль [pap] в секции authenticate, а атрибут Expiration обрабатывает модуль [expiration] в секции authorize.
Очевидно, что эти строки сгенерировал и записал для нас наш биллинг easyhotspot. Таблица radcheck нужна для записи атрибутов, которые будут проходить проверку, а в таблицу radreply записываются те атрибуты, которые должны передаваться в ответе.
Но здесь мы видим только WISPr-Session-Terminate-Time := «2016-1-6T24:00:00». Все потому, что атрибуты могут быть сгруппированы. Если мы имеем общий биллинг-план с одинаковым набором атрибутов, зачем нам писать их в таблицу radreply для каждого пользователя. Мы просто в таблице radusergroup указываем username пользователя, в groupname его принадлежность к группе и приоритет.
А дальше в таблице radgroupreply в groupname указываем всю ту же группу и перечисляем все атрибуты, которые должны быть переданы тем пользователям, что в ней состоят.
И тут мы видим оставшиеся три атрибута, что приходили к нам в ответе от freeRadius. Что если мы хотим иметь в группе атрибуты не только для отправки, но и для проверки? Тут нам на помощь приходит таблица radgroupcheck.
В ней мы видим Session-Timeout, который проверяется модулем [noresetcounter] в секции authorize и Simultaneous-Use, который обрабатывается модулем [sql] в секции session. value = 1 как раз таки и говорит радиусу о том, что в один момент времни может быть только одна активная сессия, все последующие попытки авторизоваться будут получать отказ.
И все это за нас делает наш биллинг easyhotspot. Когда мы создали биллинг-план и нажали кнопку ‘Generate Voucher’, easyhotspot раскидал все необходимые атрибуты по таблицам самым оптимальным образом. В таблицу radpostauth при помощи модуля [sql] в секции post-auth пишутся логи успешных попыток авторизации.
Видим две записи наших успешных попыток. Остается самая объемная таблица radacct, которая создается freeRadius’ом при обработке пакетов аккаунтинга. К ней будет обращаться наш биллинг когда мы будем просить его показать нам кто из юзеров онлайн, кто сколько потратил времени и трафика. Так же к ней будет обращаться и сам freeRadius в тех же целях при обработке запросов от NAS.
Теперь, имея предсталение, как работают в связке NAS-freeRadius-MySQL-Easyhotspot перейдем к практической части. Запустив в продакшн через некоторое время мы увидем следующую картину в меню «Online Users».
В файле /etc/raddb/sites-enabled/default в секции preacct в самом ее начале запишем следующее выражение:
Мы создаем условие при котором, атрибут User-Name равен:
Работает, при этом помним, что при создании креденциалов мы сами не должны попадать под эти условия, иначе пользователь авторизуется, но аккаунтинга мы от него не увидим. Посмотрим, как теперь выглядит наша таблица «Online Users».
Мак-адресов в ней теперь не наблюдается, но видно, что некоторые сессии явно зависли. Проверим таблицу radacct, посмотрим, что случилось с пользователем «detpis7».
А с его сессией как раз таки все впорядке. Мы видим, что она началась 2015-12-24 18:18:00, а завершилась 2015-12-24 19:11:37 Почему же тогда висит у нас в биллинге со временем старта 2015-12-24 18:18:00? Посмотрим как формируется запрос к базе данных. Это происходит в файле /opt/EasyHotspot/htdocs/system/application/models/onlineusermodel.php:
Из запроса видно, что для каждого пользователя записи группируются вместе по максимальному времени начала сессии и выбирается строка где в acctstoptime записано NULL. Для нашего биллинга этот запрос не будет работать правильно по двум причинам.
Во первых вспомним наши тестовые запросы. Мы выяснили, что при нормальных раскладах одна сессия в таблице должна занимать одну строку. Создается она когда прилетает пакет start, а далее только обновляется. За это отвечает запрос accounting_update_query в файле /etc/raddb/sql/mysql/dialup.conf Но если он зафейлится, freeRadius воспользуется запросом accounting_update_query_alt и создаст новую строку, что у нас и произошло.
Во вторых мы видим, что время начала сессии в пределах одной сессии у нас меняется на секунду. Как это получается? NAS присылает только Acct-Session-Time, а вот acctstarttime для таблицы radacct freeRadius считает сам. Посмотрим запрос accounting_update_query_alt в файле /etc/raddb/sql/mysql/dialup.conf:
Из него нам становится ясно, что сервер берет текущее время, отнимает от него Acct-Session-Time (Acct-Delay-Time у нас 0) и получает время начала сессии.
Значит весь механизм работает так: допустим пользователь авторизовался в системе в 12.00.00, допустим в 12.00.20 NAS решил послать пакет Interim-update, из 12.00.20 вычел 12.00.00, получил 20 и отправил атрибут Acct-Session-Time = 20 freeRadius’у. Наш сервер, получив это значение, воспользовался функцией MySQL DATE_SUB(date,INTERVAL expr type) из 12.00.20 вычел 20, получил 12.00.00 и записал это значение в таблицу как acctstarttime.
Допустим через 20 сек NAS сделал все тоже самое, и послал Acct-Session-Time = 40 но теперь пакет на секунду где-то в сети задержался и когда прилетел к серверу на часах было уже 12.00.41, 12.00.41 — 40 = 12.00.01 теперь в новой строке таблицы radacct acctstarttime = 12.00.01.
Посмотрите еще раз на предыдущую таблицу. Вот и получается, что запрашивая для биллинга MAX(acctstarttime) где acctstoptime = NULL мы получаем зависшую сессию.
При этом обратите внимание на значение Duration в биллинге и acctsessiontime в таблице, оно так же считается неверно. В запросе эти значения суммируются для каждого юзера, но мы не можем суммировать их, когда сессия имеет больше одной строки в таблице.
Изменим запрос так:
Во первых сгруппируем запрос не по username, по acctuniqueid. Это уникальное значение в пределах сессии. Раз на MAX(acctstarttime) мы положится не можем, будет в пределах сессии брать максимальное значение radacctid, при этом не сумму, а максимальное значение acctsessiontime в пределах сессии разделим на 60, чтобы сразу получить результат в минутах и сложим между собой в пределах сессии максимальные значения acctoutputoctets и acctinputoctets и теперь из всего этого найдем те строки где stop = NULL.
Это и будут активные сессии с правильными значениями времени и трафика с учетом тех проблем, что мы выявили ранее. При этом добавим в запрос колонку framedipaddress, она показывает IP-адреса наших пользователей. Добавим ее в биллинг.
vi /opt/EasyHotspot/htdocs/system/application/models/vouchermodel.php +22
Идет запрос к таблице voucher_list На самом деле это не таблица, а представление. Его описание, как и для всех созданных таблиц мы можем найти в файле /opt/EasyHotspot/install/database_with_sample.sql.
Смысл в том, что представление собирает данные из других таблиц, как при обычном запросе, а мы обращаемся к представлению, как к обычной таблице.
Если рассматривать наше представление, как обычный запрос, то нам нужно переделать его так:
Здесь мы используем запрос с подзапросом, который позволяет из сгруппированных в пределах сессии данных получить суммы максимальных значений acctsessiontime, acctoutputoctets и acctinputoctets по всем сессиям для каждого пользователя.
Логика такая: если пользователь имел три сессии и в таблице radacct имеется пятнадцать строк по пять строк на сессиию, то наш подзапрос выведет три строки с максимальными значениями данных для каждой сессии. А потом основной запрос суммирует эти данные сессий для каждого пользователя. В итоге мы собираем все данные таким образом, что в итоге представление по своей структуре колонок остается таким же, как и оригинальное.
Нюанс здесь в том, что представление не может иметь подзапрос. Но зато одно представление может запрашивать данные у другого. Создадим представление voucher_list_0 на котором будет основываться основное представление voucher_list:
Удалим старое представление:
Готовый запрос с подзапросом, который заменит `postpaid_account_list` выглядит так:
Создадим представление postpaid_account_list_0 на котором будет основываться основное представление postpaid_account_list:
Удалим старое представление:
Теперь нужно вспомнить, что freeRadius с помощью своих модулей тоже обращается к radacct. Вспомним про модуль [noresetcounter], описанный в файле /etc/raddb/sql/mysql/counter.conf.
vi /etc/raddb/sql/mysql/counter.conf +110
В этом конфиге мы можем настроить различные счетчики. noresetcounter, как понятно из названия не сбрасывается. То есть, если пользователю дали 3600 секунд, то по истечению их он уже не сможет пользоваться этими креденциалами никогда. Так же можно настроить счетчики, которые скидываются раз в день, неделю, месяц.
Перейдем к следующему модулю, а вернее к знакомой нам секции session и ее модулю [sql] Запрос этого модуля описан в файле /etc/raddb/sql/mysql/dialup.conf в разделе «Simultaneous Use Checking Queries».
С помощью этого запроса определяется сколько активных сессий имеется для пользователя. Запрос возвращает количество, а в таблице radgroupcheck у нас имеется атрибут Simultaneous-Use := 1, то есть только один пользователь в один момент времени может использовать выданные ему крединциалы.
Еще раз посмотрим на данные акаунтинга для юзера detpis7:
Как вы думаете какое число вернет запрос simul_count_query? Не будем гадать, проверим:
Хоть активных сессий и нет, при таком запросе detpis7 никогда больше не сможет авторизоваться. Изменим запрос:
vi /etc/raddb/sql/mysql/dialup.conf +300
Таким образом мы рассмотрели, как установить и настроить hotspot с базовыми функциями биллинга.
