Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Неверный учет радиусов - неправильные AcctInputOctets и AcctOutputOctets, UniFi Network
 
Как и многие до меня (с 2011 года) уже спрашивали об этом на форуме, я бы хотел снова задать вопрос: почему данные учёта RADIUS все еще неверны и когда это наконец будет исправлено? Моё основное беспокойство связано с неправильной отчётностью по использованию данных: почти в каждой второй сессии указывается 4 ГБ вверх и вниз, и похоже, что роуминг вызывает создание новых сессий... Так @UI-MikeD, возможно ли исправить это в обозримом будущем?
 
Ничего, если посмотреть на SQL-запросы, они содержат acctinputoctects64. В любом случае, я два дня назад сообщил Unifi о некоторых неверных учетных пакетах и жду их ответа, потому что иногда мне кажется, что точки доступа Unifi отправляют учетные данные с ровно 4 ГБ acctinput/output. Это выглядит случайным для меня, но, возможно, не для их программистов (надеюсь). Я знаю, что это неправильно, потому что невозможно при моем уровне пропускной способности скачать и загрузить 4 ГБ одновременно за 15 минут, что и есть время учета, которое я настроил...
 
Извини за поздний ответ. В queries.conf все запросы раскомментированы (кроме тех, что касаются sql_session_start). В стандартной конфигурации сервера "acct_counters64", конечно, тоже раскомментирован. Поэтому не знаю, что еще нужно сделать...
 
Если посмотреть на файл queries.conf, гигабайты применяются до добавления. Поэтому, если вам нужны все входные и выходные гигабайты в конфигурационном файле (который использует unlang), вам следует раскомментировать эту строку, это не нужно для стандартной конфигурации или пользовательских конфигураций, которые не требуют проверки чего-либо в трафике, но... Unlang: https://freeradius.org/radiusd/man/unlang.htmlВ моем случае проблема возникает иначе... Я написал решение, основанное на снижении скорости пользователя в зависимости от трафика, подобно тому, как это делает любой мобильный оператор, но ежедневно. В моей сети пользователи после скачивания 1 ГБ данных будут работать со скоростью 128 кбит/с до следующего дня (00:00). Из-за этого мне нужно было написать триггер MySQL, чтобы сохранить загруженные и скачанные данные, а также время сессии в другую таблицу, потому что некоторые сессии могут быть длиннее установленного нами периода (в данном случае ежедневно). Дело в том, что мы разбиваем трафик сессии и время по таблице по пользователю и часовому периоду, и я изменяю скорость пользователя с помощью внешнего скрипта. Иногда не понимаю, почему у меня появляются отрицательные значения для потребления данных, но количество данных в исходной таблице radacct остается тем же, так что... Я подозреваю, что иногда точки доступа (NAS) отправляют исправления по поводу потребления трафика пользователя. Не уверен, возможно ли это... Знаю, что эта последняя часть не относится к вашему вопросу, но думаю, что первая часть этой статьи тоже решает вашу проблему.
 
@gtrabanco спасибо, но можешь объяснить это подробнее, что насчет unlang? Как я писал в предыдущем посте, у меня это включено: preacct { preprocess # Сливаем Acct-[Input|Output]-Gigawords и Acct-[Input-Output]-Octets # в один 64-битный счетчик Acct-[Input|Output]-Octets64. # acct_counters64 и иногда кажется, что учет данных работает, а потом вдруг нет — за несколько минут сессии отчет по 4 ГБ...
 
У меня такая же конфигурация, как у тебя, с daloradius и freeradius 3.0. В FR3 проблема с учётом по gigawords решена по умолчанию, тебе нужно всего лишь активировать gigawords в preacct, если ты будешь использовать это с ulang в конфигурационном файле.
 
Очень профессиональная работа с пользовательским интерфейсом...
 
Я уже сообщал об этом более двух месяцев назад, а ответ, который я получил, был о том, что они работают над этим или будут работать.
Страницы: 1
Читают тему (гостей: 1)