ACCT_TERMINATE_CAUSE 3 : Lost-Service

[ran]

Получается, что случайным образом (особенно при неуверенном покрытии сети) от юзера не приходят алайвы, биллинг закрывает его сессию с ACCT_TERMINATE_CAUSE=Lost-Service

та не... если по причине сбоев сети теряются LCP echo request/replay то радиусклиент посылает радиуссерверу стоп пакет с ACCT_TERMINATE_CAUSE=Lost-Carrier (при этом разумеется прибивая туннель) и сессия закрывается корректно... тут дело не в этом... тут именно теряется связь между радиуссервером и радиусклиентом... конечный усер здесь абсолютно ни причём

ЗЫ: и проблема здесь собсно не в абиллсе а в протоколе обмена радусклиента с радиуссервером... это UDP протокол а значит без гарантированной доставки... получается что при потере связи между радисклиентом и радиуссервером радиусклиент не знает, получил ли сервер алайв или нет... и продолжает держать поднятый туннель (у негото всё пучком)... и слать алайвы (в никуда)... а сервер их не получает и рвёт сессию по лост-сервис... мдя... неаккуратненько... и броться с этим похоже невозможно (такой протокол)

ЗЫ2: хотя нет... я думаю на уровне абиллса можно организовать каким-то образом посылку "подтверждений" от сервера клиенту на принятый алайв... чото мне так кажется

ЗЫ3: о! выход есть!!! просто абиллс при обрыве сессии по лост-сервис должен сделать (так на всякий случай) хенгап этого усера и тада будет всё пучком

[Dozz]

Получается, что случайным образом (особенно при неуверенном покрытии сети) от юзера не приходят алайвы, биллинг закрывает его сессию с ACCT_TERMINATE_CAUSE=Lost-Service

та не... если по причине сбоев сети теряются LCP echo request/replay то радиусклиент посылает радиуссерверу стоп пакет с ACCT_TERMINATE_CAUSE=Lost-Carrier (при этом разумеется прибивая туннель) и сессия закрывается корректно... тут дело не в этом... тут именно теряется связь между радиуссервером и радиусклиентом... конечный усер здесь абсолютно ни причём

ЗЫ: и проблема здесь собсно не в абиллсе а в протоколе обмена радусклиента с радиуссервером... это UDP протокол а значит без гарантированной доставки... получается что при потере связи между радисклиентом и радиуссервером радиусклиент не знает, получил ли сервер алайв или нет... и продолжает держать поднятый туннель (у негото всё пучком)... и слать алайвы (в никуда)... а сервер их не получает и рвёт сессию по лост-сервис... мдя... неаккуратненько... и броться с этим похоже невозможно (такой протокол)

ЗЫ2: хотя нет... я думаю на уровне абиллса можно организовать каким-то образом посылку "подтверждений" от сервера клиенту на принятый алайв... чото мне так кажется

ЗЫ3: о! выход есть!!! просто абиллс при обрыве сессии по лост-сервис должен сделать (так на всякий случай) хенгап этого усера и тада будет всё пучком

Вот это доступно объяснил! Спасибо большое, ran! Теперь ясна суть проблемы. остается выяснить почему может теряться связь между радиус-клиентом и радиус-сервером, если оба эти демона запущены на одной машине. Не может ли быть, что радиуссервер (freeradius 1.1.7) отбрасывает пакеты от клиента при большой загрузке (например, если запустить сервер в однопоточном режиме)?

[ran]

Не может ли быть, что радиуссервер (freeradius 1.1.7) отбрасывает пакеты от клиента при большой загрузке

может... проверено! но дело даже не в этом... с этим можно бороться

я просто хочу обратить внимание Автора на это

абиллс при обрыве сессии по лост-сервис должен сделать (так на всякий случай) хенгап этого усера и тада будет всё пучком

[Dozz]

Acct-Interim-Interval - это ж время, через которое биллинг делает пересчет статистики пользователя, инициированное радиусом. Разве оно как-то связано с алайв-пакетами, которые клиент обязуется посылать каждые 60 (в данном случае) секунд для оповещения сервера о своем присутствии. Исправьте меня, если я неправ.

Acct-Interim-Interval - это атрибут, передаваемый радиус-клиенту. Который как раз и указывает, как часто клиент будет слать алайв-пакеты.
Поле алайв - только для биллинга актуально, клиент о его существовании даже не подозревает

Совсем я запутался.

У меня в настройках mpd5 есть такие строчки:

Код: Выделить всё

radius:
    set auth acct-update 300
...
pptp:
    set link keep-alive 30 120
    load radius
...

"acct-update 300" - это есть параметр Acct-Interim-Interval, который инициирует каждые 300 сек аккаунтинг конечного юзера. Но кем? Действительно ли клиентом, как утверждается, а не НАСом посредством передачи радиус-сервером НАСу этой радиус-пары? - не верю!

А вот "link keep-alive 30 120" - это как раз инструкция НАСу посылать алайв-запросы (LCP echo request/replay, о которых писал ran) с периодичностью в 30 сек, а при неполучении алайв-ответа в течении 120 сек сбрасывать юзера с линии.

Параметр же Alive (он же NAS_ALIVE) в билинге присутсвует лишь для скрипта billd, который по крну запускается и проверяет сессии. Если какие-либо подвисли на время большее, чем NAS_ALIVE*ERROR_ALIVE_COUNT, то сессия переноситься в ZAP (Lost Alive), если же ответа нет больше чем 2*NAS_ALIVE*ERROR_ALIVE_COUNT, то сессия обрывается с ошибкой "Error: Session Calculate".

Что верно, а что, как говорил ran, "тришечки не так"? Помогите разобраться ху із ху.

[NiTr0]

"acct-update 300" - это есть параметр Acct-Interim-Interval, который инициирует каждые 300 сек аккаунтинг конечного юзера. Но кем? Действительно ли клиентом, как утверждается, а не НАСом посредством передачи радиус-сервером НАСу этой радиус-пары? - не верю!

Кто задаст этот интервал - конфиг mpd или нас - без разницы.

А вот "link keep-alive 30 120" - это как раз инструкция НАСу посылать алайв-запросы (LCP echo request/replay, о которых писал ran) с периодичностью в 30 сек, а при неполучении алайв-ответа в течении 120 сек сбрасывать юзера с линии.

Да, только это называется не алайв-запросы, а эхо-запросы, подобие пинга. Которые никакого отношения к "вышестоящим инстанциям" не имеют, и о существовании которых биллинг даже и не подозревает.

Параметр же Alive (он же NAS_ALIVE) в билинге присутсвует лишь для скрипта billd, который по крну запускается и проверяет сессии. Если какие-либо подвисли на время большее, чем NAS_ALIVE*ERROR_ALIVE_COUNT, то сессия переноситься в ZAP (Lost Alive), если же ответа нет больше чем 2*NAS_ALIVE*ERROR_ALIVE_COUNT, то сессия обрывается с ошибкой "Error: Session Calculate".

Не совсем так. Если биллинг не получал NAS_ALIVE*ERROR_ALIVE_COUNT времени Alive-пакеты (они же аккаунтинг-пакеты) от наса - он помещает сессию в зап. Что у вас и получилось с вашим конфигом.

[Dozz]

А вот "link keep-alive 30 120" - это как раз инструкция НАСу посылать алайв-запросы (LCP echo request/replay, о которых писал ran) с периодичностью в 30 сек, а при неполучении алайв-ответа в течении 120 сек сбрасывать юзера с линии.

Да, только это называется не алайв-запросы, а эхо-запросы, подобие пинга. Которые никакого отношения к "вышестоящим инстанциям" не имеют, и о существовании которых биллинг даже и не подозревает.

Вот в этом и была моя ошибка - считал, что алайв пакетами называются в том числе и LCP пакеты. Спасибо за разъяснение!