forum.bitel.ru • Просмотр темы - Не скидывает при отрицательном балансе (после восста.лимита)

Сообщения без ответов | Активные темы

Список форумов » BGBilling » Модули Интернета » Модуль DialUp (VPN)

Часовой пояс: UTC + 5 часов [ Летнее время ]

Не скидывает при отрицательном балансе (после восста.лимита)

Страница 1 из 1

[ Сообщений: 22 ]

Версия для печати

Пред. тема | След. тема

Автор

Сообщение

Ivanov_AP

Заголовок сообщения: Не скидывает при отрицательном балансе (после восста.лимита)

Добавлено: 25 авг 2009, 21:25

Объясните пожалуйста ситуацию.

Абонент подключен на безлимитный тарифный план,
на счету у него, допустим, "-179.35"
Ему до 5-го числа разрешено подключаться с балансом, допустим "-200"
То есть оператором у него выставлен лимит -200 до 5-го числа, т.к. пользователь пообещал заплатить.
4-го числа он успешно подключился и работает.
И не собирается платить.

5-го числа в 00.00 срабатывает задача восстановления лимитов.
У пользователя на счету теперь остаются те самые "-179.35"

Почему при этом биллинг не предпринимает попытки скинуть пользователя с линии,
и пользователь может преспокойно работать дальше, хоть до конца месяца, с отрицательным балансом?
В логах BGRadiusDialup при этом ничего необычного, никаких попыток сбросить.
Конечно, если пользоветель разъединит VPN-соединение, то снова уже не зайдет - "Ошибка баланса."

Нормально ли это - позволять работать пользователю с отрицательным балансом,
или у меня проблемы с конфигурацией? /тогда в какую сторону копать?/

Конфиги radius-сервера и NASа практически стандартные (из документации), за исключением добавленных наборов атрибутов и пулов адресов,
dialup.workmode=1 (UPDATE)
NAS - Linux pppd 2.4.4, update-пакеты ходят каждые 60 сек,
инспектор для проверки соединений на основе SNMP настроен и работает.
Конфиги привести полностью?

Тарифный план - максимально простой, и приведен ниже на скриншоте;

Такая ситуация возникает у всех абонентов, то есть по истечении лимита не отключает никого.
(ни дебетовых, не кредитовых)

Версия 4.6, в любых билдах.

Вложения:

plan.png [ 9.37 КБ | Просмотров: 7804 ]

Вернуться к началу

skn

Заголовок сообщения:

Добавлено: 25 авг 2009, 22:08

Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4494
Откуда: Уфа, Россия
Карма: 187

лимит договора считывается при старте сессии, кешируется и далее используется кешированное значение.

Вернуться к началу

Ivanov_AP

Заголовок сообщения:

Добавлено: 25 авг 2009, 22:20

Спасибо за разъяснение...
То есть порвать такие сессии можно только неким самодельным скриптом проверки...

Вернуться к началу

skn

Заголовок сообщения:

Добавлено: 25 авг 2009, 22:27

Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4494
Откуда: Уфа, Россия
Карма: 187

да, как вариант, при изменение лимита проверять, есть ли текущие сессии и соответствие баланса и лимита, и при необходимости сбрасывать сессии

Вернуться к началу

Администратор

Заголовок сообщения:

Добавлено: 26 авг 2009, 16:19

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

Собыие о смене лимита передается радиусу. Должно использовать новый лимит.
Попробуйте:
1) Поменять лимит руками (сбросит-не сбросит).
2) Воспроизвести указанный вами случай и выложите connection.log по "бессмертной" сессии.

Вернуться к началу

madmax

Заголовок сообщения:

Добавлено: 27 авг 2009, 19:03

Такая же история, только меняем статус договра на (отключен, закрыт, приостановлен). И те сессии договор которым сменили статус и которые висят на данный момент не сбрасываются.
Правильно ли мы понимаем что сбросить сессии можно только скриптом - биллинг не делает проверку по статусу и лимиту.
при этом в мониторе ручной сброс отрабатывает.

Вернуться к началу

Ivanov_AP

Заголовок сообщения:

Добавлено: 27 авг 2009, 19:32

А, значит еще и по статусу проверку не делает...

Ситуацию обязательно воспроизведу и выложу логи чуть позже, сейчас совсем нет времени

Вернуться к началу

madmax

Заголовок сообщения:

Добавлено: 27 авг 2009, 23:55

При тестировании выявили следующую особенность.
Стоит MPD 5.2, биллинг 4.6544
При смене статуса договора на закрыт или приостановлен - система отрабатывает и отключает клиента в логи пишет.
08-27/23:11:51 INFO [Thread-8] connections - [ нет; test1; 96773 ] sendKillRequest
08-27/23:11:51 INFO [Thread-8] connections - [ нет; test1; 96773 ] SNMP reset request: set 1.3.6.1.4.1.2021.255.1 i 24

При смене статуса на Отключить клиент не отключается а в логи пишет
08-27/23:11:51 INFO [Thread-8] connections - [ нет; test1; 18701 ] sendKillRequest
08-27/23:11:51 INFO [Thread-8] connections - [ нет; test1; 18701 ] SNMP reset request: set 1.3.6.1.4.1.2021.255.1 i 20

А вот если поиграть с лимитом то клиент отключается и в логи пишет
Changing limit on 10.00
08-27/23:11:51 INFO [Thread-8] connections - [ нет; test1; 18701 ] SNMP reset request: set 1.3.6.1.4.1.2021.255.1 i 16

Получается при значении i 20 не происходит отключение.
Разработчики можите ответить почему так происходит.

А что качается Ivanov_AP советую вам еще раз проверить конфиг наса
в 4.6 изменились названия для mpd например в 4.6
nas.inspector.class=bitel.billing.server.processor.SNMPNASConnectionInspectorMPD (а раньше было Type5 на конце).

Вернуться к началу

skn

Заголовок сообщения:

Добавлено: 28 авг 2009, 00:02

Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4494
Откуда: Уфа, Россия
Карма: 187

set 1.3.6.1.4.1.2021.255.1 i XX - это значит сбросить интерфейс XX, к лимиту и статусу отношения не имеет

Вернуться к началу

Ivanov_AP

Заголовок сообщения:

Добавлено: 28 авг 2009, 00:05

Цитата:

советую вам еще раз проверить конфиг наса

у меня не mpd, и скидывание в других случаях (например, кончились деньги на счету) происходит нормально;
но параметры на всякий случай перепроверю

Последний раз редактировалось Ivanov_AP 28 авг 2009, 00:13, всего редактировалось 1 раз.

Вернуться к началу

madmax

Заголовок сообщения:

Добавлено: 28 авг 2009, 00:11

Понятно тогда подскажите что мне посмотреть в логах или еще что-нибудь чтобы выяснить почему при смене статуса на отключить - не происходит сброса клиента.
Ivanov_AP если не трудно проверте у себя при разных статусах договора как клиент реагирует - может найдем закономерность какую-нибудь

Вернуться к началу

skn

Заголовок сообщения:

Добавлено: 28 авг 2009, 02:05

Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4494
Откуда: Уфа, Россия
Карма: 187

madmax писал(а):

Понятно тогда подскажите что мне посмотреть в логах или еще что-нибудь чтобы выяснить почему при смене статуса на отключить - не происходит сброса клиента.

возможно просто не всегда отрабатывает сброс....
попробуйте поменять статус несколько раз подряд и посмотреть всегда ли отрабатывает или нет
в любом случае судя по логу биллинг запрос на сброс посылает, надо смотреть что на NASе, доходит ли до него запрос и отрабатывает ли он там

Вернуться к началу

Ivanov_AP

Заголовок сообщения:

Добавлено: 28 авг 2009, 02:56

To Administrator:

Цитата:

Попробуйте:
1) Поменять лимит руками (сбросит-не сбросит).
2) Воспроизвести указанный вами случай и выложите connection.log по "бессмертной" сессии.

Код:

пользоатель подсоединился - 
08-27/23:56:15  INFO [pool-2-thread-1] connections - [ 234; zzz; 75161 ] DialUpNASConnection startConnection mode=1
08-27/23:56:15  INFO [pool-2-thread-1] connections - [ 234; zzz; 75161 ] DialUpNASConnection set STATUS=1
[здесь каждую минуту однообразная информация о пришедших update-пакетах]
08-27/23:59:15  INFO [pool-2-thread-4] connections - [ 234; zzz; 75161 ] DialUpNASConnection update connection..
08-27/23:59:15  INFO [pool-2-thread-4] connections - [ 234; zzz; 75161 ] DialUpNASConnection set STATUS=1
..здесь, в 00.00 лимит пользователя обнулится, и его баланс стал минусовой... но он продолжает работать...
08-28/00:00:15  INFO [pool-2-thread-5] connections - [ 234; zzz; 75161 ] DialUpNASConnection update connection..
08-28/00:00:15  INFO [pool-2-thread-5] connections - [ 234; zzz; 75161 ] DialUpNASConnection set STATUS=1
08-28/00:01:15  INFO [pool-2-thread-6] connections - [ 234; zzz; 75161 ] DialUpNASConnection update connection..
08-28/00:01:15  INFO [pool-2-thread-6] connections - [ 234; zzz; 75161 ] DialUpNASConnection set STATUS=1
08-28/00:02:15  INFO [pool-2-thread-7] connections - [ 234; zzz; 75161 ] DialUpNASConnection update connection..
08-28/00:02:15  INFO [pool-2-thread-7] connections - [ 234; zzz; 75161 ] DialUpNASConnection set STATUS=1
08-28/00:03:15  INFO [pool-2-thread-8] connections - [ 234; zzz; 75161 ] DialUpNASConnection update connection..
08-28/00:03:15  INFO [pool-2-thread-8] connections - [ 234; zzz; 75161 ] DialUpNASConnection set STATUS=1
все еще работает...
Тогда вручную выставляем ему limit=10. И тут же видим...
08-28/00:03:37  INFO [Thread-19] connections - [ 234; zzz; 75161 ] Changing limit on 10.00
08-28/00:04:15  INFO [pool-2-thread-9] connections - [ 234; zzz; 75161 ] DialUpNASConnection update connection..
08-28/00:04:15  INFO [pool-2-thread-9] connections - [ 234; zzz; 75161 ] No close calculate period..
08-28/00:04:15  INFO [pool-2-thread-9] connections - [ 234; zzz; 75161 ] Set connection to KILL
08-28/00:04:15  INFO [pool-2-thread-9] connections - [ 234; zzz; 75161 ] DialUpNASConnection killing connection after UP
DATE
08-28/00:04:15  INFO [pool-2-thread-9] connections - [ 234; zzz; 75161 ] DialUpNASConnection set STATUS=1
08-28/00:04:17  INFO [Thread-8] connections - [ 234; zzz; 75161 ] sendKillRequest
08-28/00:04:17  INFO [Thread-8] connections - [ 234; zzz; 75161 ] SNMP reset request:  set 1.3.6.1.4.1.2021.255.1 i 2724
3
08-28/00:04:17  INFO [pool-2-thread-10] connections - [ 234; zzz; 75161 ] IP address unregistred from collector
08-28/00:04:17  INFO [pool-2-thread-10] connections - [ 234; zzz; 75161 ] DialUpNASConnection stoppingConnection
08-28/00:04:17  INFO [pool-2-thread-10] connections - [ 234; zzz; 75161 ] DialUpNASConnection has stop Packet => true
08-28/00:04:17  INFO [pool-2-thread-10] connections - [ 234; zzz; 75161 ] DialUpNASConnection set STATUS=3
08-28/00:04:17  INFO [pool-2-thread-10] connections - [ 234; zzz; 75161 ] DialUpNASConnection sessionTime => 482
08-28/00:04:17  INFO [pool-2-thread-10] connections - [ 234; zzz; 75161 ] Adding DisconnectByBalanceOverEvent..

То есть событие ручной смены лимита передается радиусу, а автоматической, по планировщику -нет?

To madmax:

Цитата:

в 4.6 изменились названия для mpd например в 4.6...

Спасибо огромное!
Действительно, у меня в конфиге эта строчка так и осталась с версии 4.5 . Странно, что оно вообще работало...
Исправил. Только ситуация с лимитом при этом не изменилась.

Цитата:

проверте у себя при разных статусах договора как клиент реагирует

нормально отключает при смене статуса на
приостановлен,отключен, закрыт и ручной смене лимита,
то есть во всех случаях, кроме смены лимита сервером.

Вернуться к началу

Администратор

Заголовок сообщения:

Добавлено: 28 авг 2009, 10:38

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

Цитата:

Действительно, у меня в конфиге эта строчка так и осталась с версии 4.5 . Странно, что оно вообще работало...
Исправил. Только ситуация с лимитом при этом не изменилась.

Да там и старое имя должно было работать. Мы совместимость оставляем всегда по возможности.
Вы можете connection.log вывести когда задача отрабатывает по восстановлению лимита? Т.е. воспроизвести подобный случай.

Вернуться к началу

Ivanov_AP

Заголовок сообщения:

Добавлено: 28 авг 2009, 12:20

Цитата:

Вы можете connection.log вывести когда задача отрабатывает по восстановлению лимита? Т.е. воспроизвести подобный случай

В логе "connection.log", выложенным одним постом выше, именно этот случай и воспроизведен...

Вернуться к началу

Администратор

Заголовок сообщения:

Добавлено: 28 авг 2009, 12:23

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

Цитата:

..здесь, в 00.00 лимит пользователя обнулится, и его баланс стал минусовой... но он продолжает работать...

Вот этот момент?

Еще: Slave база у вас не подключена?

Вернуться к началу

Ivanov_AP

Заголовок сообщения:

Добавлено: 28 авг 2009, 12:35

не, slave база вообще не настроена

Цитата:

Вот этот момент?

да, в 0 часов -

Код:

08-28/00:00:03  INFO [Thread-5] TaskExecuter - TaskExecuter => reloadTasks()
08-28/00:00:03  INFO [Thread-5] TaskExecuter - Task: bitel.billing.server.contract.LimitRestorer
08-28/00:00:03  INFO [Thread-5] TaskExecuter - Task: bitel.billing.server.npay.Calculator
08-28/00:00:03  INFO [Thread-5] TaskExecuter - Starting periodic taks ID: 1 bitel.billing.server.contract.LimitRestorer
08-28/00:00:03  INFO [pool-2-thread-1] LimitRestorer - Task finished time=12 ms.

не, если у других и у вас лимит передается нормально, значит у меня проблемы с конфигурацией, и тогда я лучше не буду отнимать Ваше время

Вернуться к началу

Администратор

Заголовок сообщения:

Добавлено: 28 авг 2009, 16:58

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

Цитата:

Хм.. Я не знаю такой опции в конфигурации, чтобы отключить передачу события там.

А апдейты у вас последние стоят всего? Планировщик работает там же, где сервер? Не на отдельной машине со своими библиотеками?

Вернуться к началу

madmax

Заголовок сообщения:

Добавлено: 28 авг 2009, 17:12

У нас при всех случаяю заработало. Спасибо.
Кому важно mpd 5.2 настраивали по wiki с использованием патча.
В файле closelink.sh есть строка
$printf "GET /bincmd?link%%20l-%d&close HTTP/1.0\r\n\r\n" $link | $nc 127.0.0.1 8080 >/dev/null
В которой говориться (l-%d) что отключать интерфейсы с названием L-10.
А у нас в крнфиге mpd было прописано create link template l pptp
а также create link template q ppoe.
так вот как раз "q" не передавалось
Решили вопрос
добавление в файл closelink.sh еще одной строки
$printf "GET /bincmd?link%%20q-%d&close HTTP/1.0\r\n\r\n" $link | $nc 127.0.0.1 8080 >/dev/null

Вернуться к началу

Ivanov_AP

Заголовок сообщения:

Добавлено: 04 сен 2009, 17:18

Цитата:

А апдейты у вас последние стоят всего? Планировщик работает там же, где сервер? Не на отдельной машине со своими библиотеками?

Да, апдейты стоят последние,
и все (и биллинг, и радиус, и планировщик и NAS) на одном компьютере, он же тестовый

когда руками меняешь лимит договора, то даже в БД
в таблице billing_event_bus появляется запись на event,
"bitel.billing.server.admin.eventbus.event.LimitChangedEvent0..."
и передается радиус-серверу, который уже скидывает пользователя

а в случае смены лимита сервером, это событие в БД почему-то не появляется, может, дело и в этом

Вернуться к началу

Администратор

Заголовок сообщения: Re: Не скидывает при отрицательном балансе (после восста.лимита)

Добавлено: 09 сен 2009, 09:31

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

А можете из scheduler.log выдрать сообщения когда задача отрабатывает восстановления лимита? Ну и скрины до и после из договора..
Включите предварительно в log4j.xml дебаг режим (в конце):

Код:

<root>
      <priority value="ALL" />
      <appender-ref ref="ASYNC" />
   </root>

Можете доступ дать ссш к серверу в личку?

Вернуться к началу

Ivanov_AP

Заголовок сообщения: Re: Не скидывает при отрицательном балансе (после восста.лимита)

Добавлено: 11 сен 2009, 13:35

Да. чуть попозже,
я на всякий случай еще раз все перепроверю

Вернуться к началу

Страница 1 из 1

[ Сообщений: 22 ]

Список форумов » BGBilling » Модули Интернета » Модуль DialUp (VPN)

Часовой пояс: UTC + 5 часов [ Летнее время ]

Кто сейчас на конференции

Сейчас этот форум просматривают: Majestic-12 [Bot] и гости: 1

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти:

BiTel

Не скидывает при отрицательном балансе (после восста.лимита)

Кто сейчас на конференции