BiTel

В модуле Dialup есть вкладка ограничения. В модуле инет не смог найти аналогичного. Необходима возможность ограничевать по Calling-Station-Id для MPD.

Под calling-station-id подразумевается MAC-адрес?
Если да, то:
http://bgbilling.ru/v5.2/doc/ch18s12s03s01.html Если в сервисе будет указан один или несколько MAC-адресов, будет пускать только их.

pptp и pppoe подразумевается ip-адрес или MAC-адрес

А обычный ethernet адрес же в таких случаях легко поменять (легче, чем MAC)? Или нет?
Поддержка именно по IP-адресу точно нужна? В принципе можно IP вместо MAC'а вставлять в скрипте предобработки, главное чтобы длиной 6/8 байт был.

У нас, кстати, тоже используются ограничение, только в качестве телефона использует аттрибут Called-Station-Id, в который заносим vlan пользователя. Можете посоветовать, как организовать ограничение в модуле Inet?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Не удобочитаемый вид адреса получаеться. А почему бы не сделать точно такоеже(в плане настройки) как и mac, поле Calling-Station-Id в сервисе с типом данных строка.
Удобный инструмент получился бы. С учётом скриптов предообработки туда хоть информацию о солнечных пятнах загоняй.
radius.Calling-Station-Id.vendor=...
radius.Calling-Station-Id.type=....
radius.Calling-Station-Id.prefix=....

И назвать его только не Calling-Station-Id, а, например, limitation для универсальности. Ну и использовать не одно ограничение, а несколько:

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Не совсем понятно, как? Просто проверять, что один из них совпадет?

Несколько ограничений это так, до кучи. Хотя бы одно если будет - уже хорошо.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

А не проще по объектам? Можно воткнуть все что угодно в совершенно любых сочетаниях и никуда глубоко лезть не надо, как в случае с телефонами в dialup

Проще, если бы были ограничения в модуле Inet по аналогии с модулем DialUp.
А за идею спасибо!

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

К сожалению, для модуля Inet нет события "RADIUS-аутентификация".

В общем, вопрос к разработчикам: есть какие-либо движения по теме?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Там все события в дин. коде, насколько я понял.
У меня скоро переезд на inet, поэтому всю работу с объектами всеравно буду до/перепиливать под inet.

Что значит "все события в дин. коде"? Обрабатывать события можно в дин. коде, но к событию всё-равно сначала нужно привязать этот код. Так вот как раз нужного события я не нашёл.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Уважаемые разработчики, наличие ограничения по mac-адресу или вообще любого ограничения не даёт той гибкости, которые были с событием "RADIUS-аутентификация". Прошу добавить это событие для модуля Inet или объясните, как реализовать произвольную логику обработки radius-запросов. preprocessAccessRequest сейчас позволяет установить разные опции и атрибуты пакета, но что сделать с этим пакетом в зависимости от опций уже зашито в коде биллинга.
Данные для организации ограничений уже можно хранить где угодно, хоть в дополнительных параметрах сервиса.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

То что нужно случайно не в ru.bitel.bgbilling.modules.inet.api.common.bean.InetConnection находится?

Не понял, что вы хотите этим сказать...

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Выложили обновление модуля, добавили событие при аутентификации
http://bgbilling.ru/v5.2/javadoc/ru/bit ... Event.html

Спасибо за оперативность!
Можно ещё маленькое уточнение: это событие до принятия решения о Reject-to-Accept или после?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Пока об этом говорим, то хотелось бы напомнить о вот такой теме, т.к. в описании inet этого ОЧЕНЬ не хватает.

Также, как в Dialup - после, прямо перед отправкой ответа.

Порядок работы скриптов/событий в доку запилите, пожалуйста.

Выложили обновление, добавили идентификатор. В сервисе можно указать несколько идентификаторов через запятую.
В конфигурации устройства/типа сервиса по аналогии с MAC-адресом автоматическая привязка: Не забудьте сделать бекап старых библиотек.

Дока...
Я так и знал, что то-то забыл.

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

public git+markdown?

У нас, наконец-то, собрали стойку с циской, поэтому продолжаю свои изыскания...

Сейчас привязка к порту коммутатора реализована через ограничения по mac-адресу, т. к. раньше можно было только так, позже переделаю через ограничения по идентификатору.
Для большинства абонентов это работает нормально, но есть абоненты, которые должны выходить с любого порта (mac-адреса, идентификатора). Что реализовать это сейчас, нужно заводить новый тип сервиса, в котором нужно будет указать serv.identifier.auto=0, что не очень удобно. Было бы значительно проще, если бы существовал идентификатор (mac-адрес) "any", который бы для конкретного сервиса выключал ограничение по идентификатору (mac-адресу). Например, в поле Идентификатор ставишь "*" (звёздочку) или в поле mac-адрес записываешь все нули, и абонент может выходить с любым идентификатором (mac-адресом).

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Выложили обновление: MAC-адрес FFFFFFFFFFFF (так и раньше работало), идентификатор *.

Может есть смысл сделать поддержку всех типов записей? Т.е.

Сейчас вводить можно по разному, но в базе хранится как байты, потому после сохранения и открытия будет FF:FF:FF:FF:FF:FF.