Неверный учет радиусов - неправильные AcctInputOctets и AcctOutputOctets, UniFi Network
Lisciu
Guest
12.08.2019 12:26:00
Как и многие до меня (с 2011 года) уже спрашивали об этом на форуме, я бы хотел снова задать вопрос: почему данные учёта RADIUS все еще неверны и когда это наконец будет исправлено? Моё основное беспокойство связано с неправильной отчётностью по использованию данных: почти в каждой второй сессии указывается 4 ГБ вверх и вниз, и похоже, что роуминг вызывает создание новых сессий... Так @UI-MikeD, возможно ли исправить это в обозримом будущем?
gtrabanco
Guest
02.11.2019 16:51:00
Ничего, если посмотреть на SQL-запросы, они содержат acctinputoctects64. В любом случае, я два дня назад сообщил Unifi о некоторых неверных учетных пакетах и жду их ответа, потому что иногда мне кажется, что точки доступа Unifi отправляют учетные данные с ровно 4 ГБ acctinput/output. Это выглядит случайным для меня, но, возможно, не для их программистов (надеюсь). Я знаю, что это неправильно, потому что невозможно при моем уровне пропускной способности скачать и загрузить 4 ГБ одновременно за 15 минут, что и есть время учета, которое я настроил...
Lisciu
Guest
30.10.2019 10:01:00
Извини за поздний ответ. В queries.conf все запросы раскомментированы (кроме тех, что касаются sql_session_start). В стандартной конфигурации сервера "acct_counters64", конечно, тоже раскомментирован. Поэтому не знаю, что еще нужно сделать...
gtrabanco
Guest
02.10.2019 20:53:00
Если посмотреть на файл queries.conf, гигабайты применяются до добавления. Поэтому, если вам нужны все входные и выходные гигабайты в конфигурационном файле (который использует unlang), вам следует раскомментировать эту строку, это не нужно для стандартной конфигурации или пользовательских конфигураций, которые не требуют проверки чего-либо в трафике, но... Unlang: моем случае проблема возникает иначе... Я написал решение, основанное на снижении скорости пользователя в зависимости от трафика, подобно тому, как это делает любой мобильный оператор, но ежедневно. В моей сети пользователи после скачивания 1 ГБ данных будут работать со скоростью 128 кбит/с до следующего дня (00:00). Из-за этого мне нужно было написать триггер MySQL, чтобы сохранить загруженные и скачанные данные, а также время сессии в другую таблицу, потому что некоторые сессии могут быть длиннее установленного нами периода (в данном случае ежедневно). Дело в том, что мы разбиваем трафик сессии и время по таблице по пользователю и часовому периоду, и я изменяю скорость пользователя с помощью внешнего скрипта. Иногда не понимаю, почему у меня появляются отрицательные значения для потребления данных, но количество данных в исходной таблице radacct остается тем же, так что... Я подозреваю, что иногда точки доступа (NAS) отправляют исправления по поводу потребления трафика пользователя. Не уверен, возможно ли это... Знаю, что эта последняя часть не относится к вашему вопросу, но думаю, что первая часть этой статьи тоже решает вашу проблему.
Lisciu
Guest
02.10.2019 09:07:00
@gtrabanco спасибо, но можешь объяснить это подробнее, что насчет unlang? Как я писал в предыдущем посте, у меня это включено: preacct { preprocess # Сливаем Acct-[Input|Output]-Gigawords и Acct-[Input-Output]-Octets # в один 64-битный счетчик Acct-[Input|Output]-Octets64. # acct_counters64 и иногда кажется, что учет данных работает, а потом вдруг нет — за несколько минут сессии отчет по 4 ГБ...
gtrabanco
Guest
01.10.2019 17:04:00
У меня такая же конфигурация, как у тебя, с daloradius и freeradius 3.0. В FR3 проблема с учётом по gigawords решена по умолчанию, тебе нужно всего лишь активировать gigawords в preacct, если ты будешь использовать это с ulang в конфигурационном файле.
gtrabanco
Guest
03.11.2019 06:45:00
Очень профессиональная работа с пользовательским интерфейсом...
Lisciu
Guest
02.11.2019 17:16:00
Я уже сообщал об этом более двух месяцев назад, а ответ, который я получил, был о том, что они работают над этим или будут работать.