Виснут сессии на Dial UP - пользователь проходит авторизацию, создается запись в базе и все, дальше сессия висит. Через некоторое время в базе появляется запись о сессии БЕЗ логина, с АБСОЛЮТНО ЛЕВЫМ IP 182.126.27.176 (откуда только UTM его берет?) и, соответственно, с нулевой стоимостью. Пока сессии не превышали минут десять - с этим можно было мириться, но когда подвисает сессия в которой человек работал 8-9 часов и она не обсчитывается - это становится уже накладно.
Один из клиентов подвисает практически при каждом подключении, при этом он работает не долго (cмотрю по логам pppd). В отчете видно, что сессия проставляется по максимальному таймауту, прописанному в тарифе (у меня он равен 43200).
Еще один клиент сегодня подвис - его сессия, которая к нему относится - была активной 36732 секунды и при этом тоже не обсчиталась.
Закономерный вопрос - что делать и как исправить???
Виснут сессии - что делать???
Виснут сессии - что делать???
UTM 1.10.010+IPCAD
Пакеты приходят - ведь в базу записываются данные по траффику, только сессия не соотносится с пользователем. То есть сессия есть, а привязки к пользователю нет - пусто. В Debug.log видно, что прошла запись в базу и что она без логина и привязки к лицевому счету. То есть здесь, как мне кажется Radius данные отдает, но не знает чьи (вопрос - почему??) Radius_max_session_age стоял на 28800. Допустим, что проблема в этом человек работал около 10 часов и в это время радиус перезагрузился (после того, как прошло 8 часов). Но как тогда объяснить тот факт, что другой пользователь работал несколько минут (смотрел по логам pppd) и все равно его сессия подвисла?? В момент его работы радиус не перезапускался. А сессия длилась 43200 сек. - то есть максимальный тайм-аут, который возможен по тарифу???
Раньше, у меня стояла переменная radius_max_session_age на 86400, но при этом происходило подвисание сессий не много подругому - радиус считал, что пользователь работал 86400 секунд, хотя опять же по логам PPPd видно было, что это не так. При этом у пользователя снимались деньги в полном объеме за это время, и если у него денег не хватало, то баланс улетал в глубокий минус - при этом следует отметить, что учет идет не траффику, а по времени. После этого я уменьшил значение переменной до 28800, а таймаут по тарифу до 43200.
Этот косяк пропал, зато появился другой, который я и описал в этой проблеме и он является следствием.
В общем, как мне видится - это либо связано с моими неправильными настройками (в чем, я сильно сомневаюсь, но допускаю), либо с тем, что радиус от UTM работает некорректно в каких то случаях (знать бы только в каких?). По одному из клиентов такое происходит уже третий раз.... из четырех подключений, которые происходили в разное время.
Раньше, у меня стояла переменная radius_max_session_age на 86400, но при этом происходило подвисание сессий не много подругому - радиус считал, что пользователь работал 86400 секунд, хотя опять же по логам PPPd видно было, что это не так. При этом у пользователя снимались деньги в полном объеме за это время, и если у него денег не хватало, то баланс улетал в глубокий минус - при этом следует отметить, что учет идет не траффику, а по времени. После этого я уменьшил значение переменной до 28800, а таймаут по тарифу до 43200.
Этот косяк пропал, зато появился другой, который я и описал в этой проблеме и он является следствием.
В общем, как мне видится - это либо связано с моими неправильными настройками (в чем, я сильно сомневаюсь, но допускаю), либо с тем, что радиус от UTM работает некорректно в каких то случаях (знать бы только в каких?). По одному из клиентов такое происходит уже третий раз.... из четырех подключений, которые происходили в разное время.
UTM 1.10.010+IPCAD
И все-таки вопрос остается - что делать???? Это явно глюк радиуса. При увеличении radius_max_session_age до 86400 сессии перестают подвисать, но при этом у РАЗНЫХ клиентов проиcходит списание полной суммы со счета, даже в минуса уходит.
Выглядит это так - при подключении клиента - радиус обсчитывает максимальный тайм-аут. После этого, через какое-то время, происходит списание со счета пользователя cуммы равной этому таймауту плюс фактическое время, которое пользователь был подключен. При этом по логу PPPD видно, что человек просидел в он-лайне явно не 12 часов с лишним, а всего минут 7.5. Какого #$#$ тогда радиус шлет данные биллингу через хрен знает сколько часов??? (Извините, за эмоции, но мне уже надоело объяснять клиентам, что денег у них на счете нет, потому что биллинг сглючил - это неправильно. И то что потом приходится сессии восстанавливать руками через базу - это тоже не правильно - это задача биллинга, а в ручную я и сам мог бы посчитать).
В общем вопроc остается - что делать???? Ладно у меня клиентов мало - я могу вручную проверить, а если бы у меня их тысячи были?? Тогда что???
Выглядит это так - при подключении клиента - радиус обсчитывает максимальный тайм-аут. После этого, через какое-то время, происходит списание со счета пользователя cуммы равной этому таймауту плюс фактическое время, которое пользователь был подключен. При этом по логу PPPD видно, что человек просидел в он-лайне явно не 12 часов с лишним, а всего минут 7.5. Какого #$#$ тогда радиус шлет данные биллингу через хрен знает сколько часов??? (Извините, за эмоции, но мне уже надоело объяснять клиентам, что денег у них на счете нет, потому что биллинг сглючил - это неправильно. И то что потом приходится сессии восстанавливать руками через базу - это тоже не правильно - это задача биллинга, а в ручную я и сам мог бы посчитать).
В общем вопроc остается - что делать???? Ладно у меня клиентов мало - я могу вручную проверить, а если бы у меня их тысячи были?? Тогда что???
UTM 1.10.010+IPCAD
Я готов бы не использовать netup-radius, но как это сделать практически?? Хотели прикрутить freeradius, но ведь при прямой записи данных в базу - ядро их не видит и заставить его что-то увидеть - не реально (не перегружать же ядро постоянно). 
Так что пока остается только использовать родной радиус, а он глючит "изредка"
Так что пока остается только использовать родной радиус, а он глючит "изредка" UTM 1.10.010+IPCAD