BiTel

Добрый день!

Уже писал об этом ранее. Некоторые клиенты потребляют услуги при отрицательном балансе. Не понятно почему. Живой пример, когда у клиента был отрицательный баланс, и он мог пользоваться услугами так и не выловил. Но есть примеры, как сказать, которые пост фактом показывают что такое поведение имеет место быть(почти по русски выразился).

Это не единичный случай. Довольно частая проблема. В месяц сталкиваюсь с несколькими такими случаями, и это только те, что всплывают.

Как быть?

Прошу прощения, данный пример не корректен(написал уже автоматически не проверяя глубоко, был внесён утром расход за прошлый месяц). Ближайший такой случай обязательно пришлю.

Снова такие моменты появляются. Клиенты логиняться и работают при отрицательном балансе

Не могу объяснить этот баг. Когда до меня доходят случаи, клиент уже не может логиниться, потому живой пример привести не могу. А звонят и говорят, почему меня не выкинуло из инета, если нет денег, бла бла, и т.д., и т.п. и естественно долг их заставлять оплачивать, не самое радужное дело.

Такая ситуация не редкость! Радиус и НАС умеют сбрасывать сессии, хорошо всё. Но одно дело когда клиент уходит в минус в течении сессии (здесь можно предположить что сессиия не сбросилась по какойто причине), а другое, когда он уже в минусе, и может авторизоваться.

Прежде чем скрины выкладывать и т.д. вопрос:
У кого нибудь бывают такие случаи?

Режим работы NAS update или checker?

update.
С акцентирую внимание ещё раз: клиент логиниться после того как он в минусе, и выходить не должен.

Анализ историй понижений лимитов, журнала запросов, по приходам, расходам, и т.д., которые говорили бы что на тот момент клиент мог выйти в интернет, даёт отрицательный ответ. Т.е. анализируя приходишь к выводу что на момент залогинивания у клиента баланс отрицательный, а он логинится.

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

Да, очень странная, потому спрашиваю у других. Бывает ли у кого такое?

Точно, сам тоже не уверен. Но смотрю на результат, у клиента минус, нет понижений лимита, и есть состоявшиеся сессии, анализирую имеющимися средствами, на момент сессии был ли у него положительный баланс, результат отрицательный! Но дело в том что до меня доходят случаи уже после того, как клиента перестаёт пускать. Потому утверждать точно не могу, что пускает клиента при отрицательном балансе.

Сейчас скину скрины с коментами свежего примера

Ну я ж Вам уже предложил решение. Логируйте все выходы юзера скриптом предобработки радиус-ответа, у подозрительного абонента сразу все станет видно. После этого или к разработчикам с отчетом и просьбой испраить баг, или в случае неоправдавшихся подозрений, посыпать голову пеплом.

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

Итак скрины с комментами:

Продолжение

Похоже на то что абон плата не учитывалась, при определении баланса.
Или была начислена вручную позже, если 1-го числа она не начислилась(что врядли). В иерархию два договора были выстроены в феврале

Журнал запросов по приходам расходам, и т.д., по начислению абонплат, очистке наработки по абонплатам говорят что всё ок . Правда действия по начислению абонплат, вообще не логируются

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

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

Судя потому что никто из пользователей БГ не говорит что у них бывают такие проблемы, значит можно предположить что в данном случае дело в абонплате, что начислилась она 30-го числа получается, вместо первого(т.к. в журнале запросов нет действий по начислению абонплат, значит начислилась автоматически). Как такие моменты с планировщиком тогда отлавливать?
PS
Планировщика логи изучать не возможно потому как там огромная куча ошибок по отправлению почты(у меня гугловская с SSL)