forum.bitel.ru http://forum.bitel.ru/ |
|
Не скидывает при отрицательном балансе (после восста.лимита) http://forum.bitel.ru/viewtopic.php?f=5&t=2787 |
Страница 1 из 1 |
Автор: | 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, в любых билдах.
|
Автор: | skn [ 25 авг 2009, 22:08 ] |
Заголовок сообщения: | |
лимит договора считывается при старте сессии, кешируется и далее используется кешированное значение. |
Автор: | Ivanov_AP [ 25 авг 2009, 22:20 ] |
Заголовок сообщения: | |
Спасибо за разъяснение... То есть порвать такие сессии можно только неким самодельным скриптом проверки... |
Автор: | skn [ 25 авг 2009, 22:27 ] |
Заголовок сообщения: | |
да, как вариант, при изменение лимита проверять, есть ли текущие сессии и соответствие баланса и лимита, и при необходимости сбрасывать сессии |
Автор: | Администратор [ 26 авг 2009, 16:19 ] |
Заголовок сообщения: | |
Собыие о смене лимита передается радиусу. Должно использовать новый лимит. Попробуйте: 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 ] |
Заголовок сообщения: | |
set 1.3.6.1.4.1.2021.255.1 i XX - это значит сбросить интерфейс XX, к лимиту и статусу отношения не имеет |
Автор: | Ivanov_AP [ 28 авг 2009, 00:05 ] |
Заголовок сообщения: | |
Цитата: советую вам еще раз проверить конфиг наса
у меня не mpd, и скидывание в других случаях (например, кончились деньги на счету) происходит нормально; но параметры на всякий случай перепроверю |
Автор: | madmax [ 28 авг 2009, 00:11 ] |
Заголовок сообщения: | |
Понятно тогда подскажите что мне посмотреть в логах или еще что-нибудь чтобы выяснить почему при смене статуса на отключить - не происходит сброса клиента. Ivanov_AP если не трудно проверте у себя при разных статусах договора как клиент реагирует - может найдем закономерность какую-нибудь |
Автор: | skn [ 28 авг 2009, 02:05 ] |
Заголовок сообщения: | |
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 ] |
Заголовок сообщения: | |
Цитата: Действительно, у меня в конфиге эта строчка так и осталась с версии 4.5 . Странно, что оно вообще работало...
Исправил. Только ситуация с лимитом при этом не изменилась. Да там и старое имя должно было работать. Мы совместимость оставляем всегда по возможности. Вы можете connection.log вывести когда задача отрабатывает по восстановлению лимита? Т.е. воспроизвести подобный случай. |
Автор: | Ivanov_AP [ 28 авг 2009, 12:20 ] |
Заголовок сообщения: | |
Цитата: Вы можете connection.log вывести когда задача отрабатывает по восстановлению лимита? Т.е. воспроизвести подобный случай
В логе "connection.log", выложенным одним постом выше, именно этот случай и воспроизведен... |
Автор: | Администратор [ 28 авг 2009, 12:23 ] |
Заголовок сообщения: | |
Цитата: ..здесь, в 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 ] |
Заголовок сообщения: | |
Цитата: не, если у других и у вас лимит передается нормально, значит у меня проблемы с конфигурацией, и тогда я лучше не буду отнимать Ваше время
Хм.. Я не знаю такой опции в конфигурации, чтобы отключить передачу события там. А апдейты у вас последние стоят всего? Планировщик работает там же, где сервер? Не на отдельной машине со своими библиотеками? |
Автор: | 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..." и передается радиус-серверу, который уже скидывает пользователя а в случае смены лимита сервером, это событие в БД почему-то не появляется, может, дело и в этом ![]() |
Автор: | Администратор [ 09 сен 2009, 09:31 ] |
Заголовок сообщения: | Re: Не скидывает при отрицательном балансе (после восста.лимита) |
А можете из scheduler.log выдрать сообщения когда задача отрабатывает восстановления лимита? Ну и скрины до и после из договора.. Включите предварительно в log4j.xml дебаг режим (в конце): Код: <root> <priority value="ALL" /> <appender-ref ref="ASYNC" /> </root> Можете доступ дать ссш к серверу в личку? |
Автор: | Ivanov_AP [ 11 сен 2009, 13:35 ] |
Заголовок сообщения: | Re: Не скидывает при отрицательном балансе (после восста.лимита) |
Да. чуть попозже, я на всякий случай еще раз все перепроверю |
Страница 1 из 1 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |