Ну, может еще кто-то напишет что у него такое же?
Прекратите истерику. Стас уже знает о проблеме и решает ее. Как только что-то будет понятно, вам сообщат!

Такое же, в разных версиях биллинга, даже в древней ревизии.

Всем привет.

После начала использования модуля Trinity и увеличения количества абонентов которым назначена услуга "TrinityTV" в день начисления абонплаты существенно увеличился промежуток времени, за который происходит начисление услуг и блокировка доступа абонентам.
До использования Trinity, начисление услуг абонентам проходило за 20-30 минут, в первый месяц когда услуга "TrinityTV" начала внедряться начисление происходило больше 1 часа, на следующий месяц около 3 часов, сейчас около 12 часов.
Подозреваю что проблема в модуле Trinity.

Вторая проблема, абонент берет "кредит" а доступ в интернет не получает, в течении нескольких часов.
Третья, списание абонплаты происходит с коэффициентом 0.98-0.99 потому что снятие происходит не в 00:00 а в 10:51.
Срок действия: 01.06.2020 10:51 .. 01.07.2020 00:00
Неполный месяц, коэффициент: 0.98

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

На какой ревизии у Вас это началось ? Метод авторизации один или несколько ?
С определенной ревизии, конфиги модулей "ядра" вынесены в веб интерфейс h t t p ://forum.nodeny.com.ua/index.php?topic=3051.0.

[Последнее обновление авторизации 19 сек назад]

"Последняя авторизация секунд назад" увеличивается до упора не меняется?

В настройках в разделе "ядро" есть параметр "Через какое время в секундах учетная запись переводится в состояние «не авторизована", чему он равен?

1.
Последнее обновление авторизации 19 сек назад - меняется значение, если обновлять страницу, увеличиваясь до упора и потом с 1-2 секунд и растет.
Последняя авторизация 15:37 методом «pppoe» - увеличивается время.

2. По дефолту 150 устанавливал, 300,120,130,140 пробовал, без изменений. Сейчас 150.

Ситуация в том что непонятным выборочным образом, по разным абонентам, информация "не попадает" в auth. Вчера это был один логин, сегодня уже другой.
Когда сессия поднята аккаунтинг есть, но в auth от "проблемного" информации нет вообще.

В дебаге радиуса, видно:

Код:

(2651049)   User-Name = "107"
(2651049)   User-Password = "107"
(2651049) sql:    --> call radcheck('107')
(2651049) sql: Executing select query: call radcheck('107')
(2651049) sql:   Cleartext-Password := "107"
(2651049) sql:    --> call radreply('107', '172.17.1.1', 'cc2de0214022')
(2651049) sql: Executing select query: call radreply('107', '172.17.1.1', 'cc2de0214022')
(2651049) sql:    --> call radupdate('107','',                'user=cc2de0214022;nas=172.17.1.1', '172.17.1.1')
(2651049) sql: Executing query: call radupdate('107','',                'user=cc2de0214022;nas=172.17.1.1', '172.17.1.1')
(2651050)   User-Name = "107"
(2651050) sql:    --> call radupdate('107','10.10.0.6',                'user=cc2de0214022;nas=172.17.1.1', '172.17.1.1')
(2651050) sql: Executing query: call radupdate('107','10.10.0.6',                'user=cc2de0214022;nas=172.17.1.1', '172.17.1.1')

В дебаге auth вообще нет информации об этом абоненте.

Опытным путем установлено, если поднять секунд на 20 и потушить pppoe, через минут 45-50, в логе авторизаций, длительность 39 минут отобразится.
При чем так не у всех, а выборочно.

После обновления до 571 ревизии, вместо auth.cgf внезапно параметры настройки конфигурации "Авторизации" вынесены в админку.
Настройки>ядро>Автоизация.

Код:

Запускать модуль при запуске ядра NoDeny - Да.
Период проверки - 5.
Через какое время в секундах учетная запись переводится в состояние «не авторизована». Зависит от настроек системы авторизации. 
Рекомендуется брать чуть больше двух периодов ре-авторизаций (например, период аккаунтинга). Для стандартной настройки по умолчанию 150 секунд - 150.

По непонятной пока причине, авторизованный по pppoe абонент, после отключения pppoe, корректного и не корректного, через 10-20-30 и больше минут продолжает отображаться в админке как онлайн, зеленый ключик и "Последнее обновление авторизации 15 секунд назад", меняются секунды, если обновить страницу.
Аккаунтинг пакеты, с тестовым логином, после отключения pppoe, не отправляются.

Подскажите пожалуйста как продебажить ?
 

Появилась реальная необходимость выдавать юрикам ипы сетями с масками /29  /28 и т.п.
Можно было бы добавлять ипы в карточку обычным способом, но заказчик хочет чтобы шейпера выдавались на всю сеть целиком а не на каждый адрес отдельно.
Стас, можно ли запилить выдачу абоненту ип пула? Заказчик готов финансировать.
Со своей стороны вижу что обычный ip адрес - это частный случай сети в виде ip/32 т.е. это почти то что и нужно.

Так и сейчас так сделать можно. Выдать клиенту несколько ip.

Код:

ipfw table 31 list | grep 9946
192.168.15.17/32 9946
192.168.15.18/32 9946
192.168.15.19/32 9946
192.168.15.20/32 9946
192.168.15.21/32 9946
192.168.15.22/32 9946

Два одинаковых:
Тип устройства    DES-1210-52 Fast Ethernet Switch
Версия загрузки    1.00.012
Версия ПО    4.10.B029
Версия HW - C1

На скрине в "Количество промежуточных узлов (hop) DHCP Relay (1-16)", сейчас на первом указано "1", на втором свиче "2". Но и при 4х4 и 2х3, результат одинаковый.

Конфиг покажите релея, а не скрины.

1) В схеме mikrotik -> D-link -> D-link
Все клиенты за вторым свичем, в DHCP server - Leases, отображаются за первым свичем на порту в котором подключен второй свитч. Но на фото ниже, всеже одного клиента показывает как на втором свече в 27 порту. Видимо еще надо чтото настроить, чтобы информация о клиентском порте, приходила верно.
2) Некоторых клиентов не отображает Agent Circuit id и Agent Remote id. Это видно на скрине ниже.

Покажите конфиг релея обоих длинков ? Модель длинков тоже укажите и какая прошивка ?

Сейчас перестали освобождаться айпи.

Так они сейчас через 3600 секунд освобождаются.

Вот вырубил с порта клиента. Уже более 3600сек, авторизация не пропадает...

ip клиента освобождается через 3600сек после того как закончилась авторизация. Вы не правильно выразились. Не завершается авторизация.
Биллинг считает что клиент "жив". Ясное дело что ip не освобождается.
Возможно процедуры, возможно аккаунтинг. Не приходит сигнал что клиент завершил авторизацию, там если не ошибаюсь, несколько вариантов.

Сейчас перестали освобождаться айпи.

Так они сейчас через 3600 секунд освобождаются.

Может из за особенностей алгоритма, заканчиваются пайпы ?

Здравствуйте.
FreeBSD 11.2-RELEASE #2 r339376.
Было и на 11.1.
Периодически, раз в месяц примерно, может реже, может чаще, возникает такая ситуация.
В один шейп попадают несколько айпи адресов, разных абонентов.
1. Скорость в шейпе меняется, на скорость последнего авторизованного абона.
2. Все айпи пропадают из проблемного пайпа.
Как лечить ?
По рецептам из этого поста forum.nodeny.com.ua/index.php?topic=2950.msg31869#msg31869  
и запускать perl noserver.pl -u=id_abonenta -v
абонов много.

Код:

ipfw table 31 list | grep 65506
10.0.7.184/32 65506
10.0.39.215/32 65506
10.0.44.219/32 65506
10.0.45.241/32 65506

ipfw table 21 list | grep 65501
10.0.7.184/32 65501
10.0.39.215/32 65501
10.0.44.219/32 65501
10.0.45.241/32 65501


ipfw table all list | wc -l   
   10609

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

Увеличение свопа, ситуацию не решит.

На графиках, смотри есть ли всплекски свопа и оперативки.