BiTel

В версии 4.6 при достаточно частых попытках авторизации (раз в 20 - 30 сек) очень высока вероятность успешной авторизации для второй сессии при ограничении в 1 сессию.
Эта проблема поднималась ранее http://www.bgbilling.ru/forum/viewtopic ... 1%F1%E8%E8, но, по видимому, она до сих пор не решена.
Если возможно, сообщите алгоритм проверки на количество сессий при авторизации, чтобы понять как оптимизировать систему для предотвращения подобных ошибок.

Вообще если даже сессия авторизуется, ее через некоторое время сбросить должно. 20 авторизаций в секунду вообще как делают?

Не 20 авторизаций в секунду, а одна авторизация в 20 секунд.
Через какое время должно сбросить? И где это можно настроить?

У вас режим обсчета случаем не checker стоит в конфигурации? Поставьте update.
Раз в 30 секунд проверяет..

У нас стоит dialup.workmode = 1, то есть режим update, и тем не менее двойные сессии продолжаются десятки минут и часы, то есть не сбрасываются.

А UPDATE пакеты идут вообще?

UPDATE пакеты посылаются каждые 5 минут.
Вот хронология событий для некоторого аккаунта:
17 13:59:20 - начало 1-й сессии
17 16:10:04 - Превышен лимит сессий - для 2-й сессии
17 16:10:26 - Превышен лимит сессий - для 2-й сессии
17 16:11:53 - Превышен лимит сессий - для 2-й сессии
17 16:31:25 - Превышен лимит сессий - для 2-й сессии
17 16:31:57 - Начало 2-й сессии
Далее каждые 5 минут посылаются UPDATE пакеты для обеих сессий, трафик и время сессий увеличиваются.

Есть какое-то решение?
Сейчас, как временную меру, наряду с ограничением по логину используем скрипт по контролю соответствия МАК адреса, но это не особенно удобно.
Хотелось бы чтобы заявленные функции работали.

У вас получается воспроизвести ошибку самостоятельно? Выложите скрины, как настроен логин, как у него установлено ограничение по сессиям.
Выборку из connection.log 2х сессий под одним логином выложите.

Отправлено в ЛС.

Вероятнее всего, у вас UPDATE пакеты идут реже, чем интервал указанный в конфигурации модуля в max.update.timeout . Т.е. между апдейт пакетами соединение успевает пометиться как неактивное.

Можете RADIUS запросы по любой сессии выложить?

ну а как же фраза из документации:


Было max.update.timeout=120

Сейчас установим max.update.timeout=360 и попробуем повторить с одновременными соединениями.


по любой сессии или именно одной из двойных?

Да с любой, просто посмотрите интервал между Update пакетами. А Auth Accept что передается в Acct-Interim-Interval?

Ну собственно согласно этой фразе и работает. То, что в скобках - описывает свойства коннекта а не опции. Т.е. неактивное соединение не учитывается в списке активных. Ну чтобы висяки клиенту зайти не помешали если что.

т.е. для нормальной работы ограничения необходимо, чтобы параметр max.update.timeout был больше времени между UPDATE-пакетами?

ну из названия опции же следует что это таймаут между апдейтами, т.е. если на сессию апдейт не пришел в течении времени max.update.timeout значит сессия умерла, например, при аливах раз в 60 сек значение в 120 говорит о том что если в течении 120 сек. не пришло ни одного алива, а должно прийти 1-2 алива, значит сессию можно считать мертвой ... значение max.update.timeout обычно = Acct-Interim-Interval * 2 или 3

Просто не правильно был понят комментарий к опции.
Выставление опции решило проблему.
Спасибо за помощь.