Архив метки: lanbilling

Lanbilling и работа с IP адресами

Начиная с 18 сборки, в Lanbiling поменялись все поля связанные с работой с IP.

Например, было:

`segment` int(10) unsigned NOT NULL DEFAULT ‘0’

Стало:

`segment` binary(16) DEFAULT NULL

Соответственно если раньше выборку по IP можно было сделать :

mysql> select inet_ntoa(segment) from staff limit 1;
+--------------------+
| inet_ntoa(segment) |
+--------------------+
| 11.242.164.20      |
+--------------------+
1 row in set (0.00 sec)

Теперь:

mysql> select inet_ntoa(CONV(RIGHT(HEX(segment), 8),16,10))  from staff limit 1;
+-----------------------------------------------+
| inet_ntoa(CONV(RIGHT(HEX(segment), 8),16,10)) |
+-----------------------------------------------+
| 11.242.164.20                                 |
+-----------------------------------------------+
1 row in set (0.00 sec)

Плюс предлагают  несколько функций для работы с подобным типом значений:

delimiter ;;

DROP FUNCTION IF EXISTS `IPV42BIN`;;
CREATE FUNCTION `IPV42BIN`(addr int(11)) 
RETURNS BINARY(16)
NO SQL DETERMINISTIC SQL
SECURITY INVOKER
BEGIN
RETURN 
unhex(concat('00000000000000000000FFFF', lpad(conv(addr, 10, 16), 8, '0')));
END;;

DROP FUNCTION IF EXISTS `IPSV42BIN`;;
CREATE FUNCTION `IPSV42BIN`(addr varchar(16)) 
RETURNS BINARY(16)
NO SQL DETERMINISTIC SQL
SECURITY INVOKER
BEGIN
RETURN 
unhex(concat('00000000000000000000FFFF', lpad(conv(inet_aton(addr), 10, 16), 8, '0')));
END;;

DROP FUNCTION IF EXISTS `BIN2IPSV4`;;
CREATE FUNCTION `BIN2IPSV4`(addr binary(16)) 
RETURNS VARCHAR(16)
NO SQL DETERMINISTIC SQL
SECURITY INVOKER
BEGIN
RETURN 
inet_ntoa(conv(substr(hex(addr),25,8),16,10));
END;;

delimiter ;

Затейники…

Вполне работает вот так:

select replace(inet6_ntoa(segment),"::ffff:","") from staff limit 1;

и

select INET6_ATON("::ffff:192.168.13.1") limit 1;

Автоматическая «прибивка» пользователей к портам устройств в LanBilling 2 путем опроса MAC свичей

Дано:

1) LanBilling в которой ведется журнал авторизации пользователей по логину с указанием MAC адреса устройства с которого прошла авторизация.

2) В LanBilling нет привязки пользователя ни к порту, ни к сетевому устройству.

Задача: опросить все сетевые устройства, узнать все MAC адреса и порты свичей на которых «висят» пользователи

Решение:

— получаем у свичей информацию о MAC адресах на портах
— ищем этот MAC  в истории авторизации LanBilling — получаем учетку
— «прибиваем» эту учетку в LanBilling к конкретному устройству, к конкретному порту.

Вуаля! Теперь когда пользователь звонит «ничего не работает», мы знаем на каком свиче и на каком порту он сидит. Ура товарищи!

Читать далее Автоматическая «прибивка» пользователей к портам устройств в LanBilling 2 путем опроса MAC свичей