Amir писал(а):
А у вас какая схема работы?
Вообще, по логике работы модуля, serviceCreate должен вызываться один раз, когда добавили сервис (или начался его период действия), serviceCancel - когда удалили сервис (кончился его период действия), serviceModify часто - когда кончились/появились деньги (или поменялся статус договора/сервиса, а также при редактировании его в клиенте биллинга) и когда поменялся набор опций из тарифа.
В случае, когда в типе сервиса стоит инициация сессии по сигналу (PPTP/DHCP.82/ISG/CLIPS, т.е. когда возможно одновременно несколько сессий) также вызываются для каждой сессии connectionModify и connectionClose.
Значит логику я понимаю правильно.
У нас при заведении сервиса создается сабскрайбер на RB, при удалении удаляется, при serviceModify он реавторизуется запрашивая актуальные атрибуты.
Бывают случаи что абонента реджектит по каким либо причинам, в нашем случае это не допустимо. Я чтобы не лезть на железку просто синхронизирую сервисы на устройстве после устранения причины реджекта, тем самым пересоздаю их на RB и все становится хорошо. Вот и подумал что здорово было бы в таких случаях вызывать serviceCancel-serviceCreate на определенном сервисе, чтобы не дергались рабочие. Но думаю в моем случае лучше полностью исключить реджект.
В данный момент почему то с radius.disable.accessCodes=1,2,3,4,10,11,12,20,44,45,62 при Reply-Message=1 абонент получает Access-Reject, остальные вроде все получают Accept как и предполагалось.
Reply-Message=1 возвращается если указать период сервиса в который не входит настоящая дата, в этом случае должен сработать serviceCancel и удалить абонента с шейпера - в этом мы уже разобрались, жду обновления после которого думаю все заработает гладко.
Вот так вот все наложилось друг на друга, хотя всеравно странно что radius.disable.accessCodes не реагирует на Reply-Message=1 .
Вход
Регистрация
FAQ
Поиск
