Перейти до

Ubilling ipfw pipe queue приоритезация трафика


Рекомендованные сообщения

В общем после пользования  приоритета трафика около 3 лет на nas микротик, с переходом на nas freebsd ubilling ощутимо сказывается на пользовании. Поскольку сеть маленькая , в глубинке и почти все клиенты   на точках , то 3м в трубе заполнить на раз, два и последующие запросы , игры или просто серфинг,  пинг ого. Биллинг работает как часы , без нареканий. Привязал очереди к уже готовым трубам для каждого ip , перепробовал множество вариаций , но пока не могу запустить , может кто ткнет где не туда смотрю? К каждой трубе для каждого пользователя привязал 4 очереди с разными портами (потом можно добавить и по размеру файлов) . Очереди как бы заполняются , но скорость (например 3m) для каждого pipe  почему то общая и для других ip , но по идее должна быть для каждого . Это одна из нескольких конфигураций , возможно кто подскажет где не так? Копию рабочего биллинга установил на виртуалку для оттачивания , чтобы клиенты не прибили за эксперименты!

 

#onconnect

 

#SPEED CONTROL
${fwcmd} pipe `expr $ID + 18101` config bw $SPEED$SCOUNT   mask dst-ip 0xffffffff
${fwcmd} pipe `expr $ID + 101` config bw $UPSPEED$SCOUNT   mask src-ip 0xffffffff
 
 # WAN -> LAN
${fwcmd} queue 111 config weight $wot   queue 50 pipe `expr $ID + 18101`  mask dst-ip 0xffffffff  
${fwcmd} queue 112 config weight $http  queue 50 pipe `expr $ID + 18101`  mask dst-ip 0xffffffff 
${fwcmd} queue 113 config weight $tcp   queue 50 pipe `expr $ID + 18101`  mask dst-ip 0xffffffff
${fwcmd} queue 114 config weight $all   queue 50 pipe `expr $ID + 18101`  mask dst-ip 0xffffffff
 
# LAN -> WAN
${fwcmd} queue 211 config weight $wot   queue 50 pipe `expr $ID + 101` mask src-ip 0xffffffff
${fwcmd} queue 212 config weight $http  queue 50 pipe `expr $ID + 101` mask src-ip 0xffffffff
${fwcmd} queue 213 config weight $tcp   queue 50 pipe `expr $ID + 101` mask src-ip 0xffffffff
${fwcmd} queue 214 config weight $all   queue 50 pipe `expr $ID + 101` mask src-ip 0xffffffff
 
#firewall.conf
 
# WAN -> LAN
${FwCMD} add 13011 queue 111 ip from any ${wot} to any via ${LAN_IF}  out
${FwCMD} add 13022 queue 112 ip from any ${http} to any via ${LAN_IF} out
${FwCMD} add 13033 queue 113 ip from any ${tcp} to any  via ${LAN_IF} out
${FwCMD} add 13044 queue 114 ip from any not ${wot},${http},${tcp}  to any via ${LAN_IF}  out
 
# LAN -> WAN
${FwCMD} add 13055 queue 211 ip from any to any ${wot} via ${LAN_IF} in
${FwCMD} add 13066 queue 212 ip from any to any ${http} via ${LAN_IF} in
${FwCMD} add 13077 queue 213 ip from any to any ${tcp} via ${LAN_IF} in
${FwCMD} add 13088 queue 214 ip from any to any not ${wot},${http},${tcp}     via ${LAN_IF} in
 
root@billing:~ # ipfw queue show
q00213  50 sl. 0 flows (64 buckets) sched 101 weight 33 lmax 0 pri 0 droptail
    mask:  0x00 0xffffffff/0x0000 -> 0x00000000/0x0000
q00212  50 sl. 2 flows (64 buckets) sched 101 weight 50 lmax 0 pri 0 droptail
    mask:  0x00 0xffffffff/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  6 ip       10.10.100.6/0             0.0.0.0/0      132     5762  0    0   0
 14 ip       10.10.100.2/0             0.0.0.0/0       29     1330  0    0   0
q00214  50 sl. 1 flows (64 buckets) sched 101 weight 1 lmax 0 pri 0 droptail
    mask:  0x00 0xffffffff/0x0000 -> 0x00000000/0x0000
 14 ip       10.10.100.2/0             0.0.0.0/0       60     4800  0    0   0
q00211  50 sl. 0 flows (64 buckets) sched 101 weight 100 lmax 0 pri 0 droptail
    mask:  0x00 0xffffffff/0x0000 -> 0x00000000/0x0000
q00111  50 sl. 0 flows (64 buckets) sched 18101 weight 100 lmax 0 pri 0 droptail
    mask:  0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
q00114  50 sl. 1 flows (64 buckets) sched 18101 weight 1 lmax 0 pri 0 droptail
    mask:  0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
 22 ip           0.0.0.0/0         10.10.100.2/0       45     2664  0    0   0
q00113  50 sl. 0 flows (64 buckets) sched 18101 weight 33 lmax 0 pri 0 droptail
    mask:  0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
q00112  50 sl. 1 flows (64 buckets) sched 18101 weight 50 lmax 0 pri 0 droptail
    mask:  0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
 18 ip           0.0.0.0/0         10.10.100.6/0      107    73002 15 10860   0
 
 
root@billing:~ # ipfw show
00004    58     3793 allow ip from table(2) to 10.10.100.1 dst-port 53 via em0
00004    58    10586 allow ip from 10.10.100.1 to table(2) src-port 53 via em0
00004     0        0 allow ip from table(2) to me dst-port 80 via em0
00004     0        0 allow ip from me to table(2) src-port 80 via em0
00005     0        0 fwd 127.0.0.1,80 ip from table(47) to not me dst-port 80
00005     0        0 fwd 127.0.0.1,80 ip from 172.32.0.0/20 to not me dst-port 80
00005     0        0 reset ip from 172.32.0.0/20 to any dst-port 443
00006     0        0 reset ip from table(47) to any dst-port 443,444
00006     0        0 allow ip from me to 172.32.0.0/20 via em0 out
00006     0        0 allow ip from 172.32.0.0/20 to me via em0 in
00101    28     1840 allow ip from me to 10.10.100.0/24 via em0 out
00102     1      328 allow ip from 10.10.100.0/24 to me via em0 in
06000 25885 13463718 nat 1 ip from table(2) to not table(9) out xmit em1
06001 23082 18714879 nat 1 ip from any to me in recv em1
13011     0        0 queue 111 ip from any 53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999 to any via em0 out
13022 22702 18675566 queue 112 ip from any 80,443,3128,8080,8081 to any via em0 out
13033     0        0 queue 113 ip from any 20,21,22,23,25,110,179,2222,3389 to any via em0 out
13044   276    18704 queue 114 ip from any not 53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999,80,443,3128,8080,8081,20,21,22,23,25,110,179,2222,3389 to any via em0 out
13055     0        0 queue 211 ip from any to any dst-port 53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999 via em0 in
13066 25736 13635783 queue 212 ip from any to any dst-port 80,443,3128,8080,8081 via em0 in
13077     0        0 queue 213 ip from any to any dst-port 20,21,22,23,25,110,179,2222,3389 via em0 in
13088   397    37455 queue 214 ip from any to any not dst-port 53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999,80,443,3128,8080,8081,20,21,22,23,25,110,179,2222,3389 via em0 in
14000     0        0 pipe tablearg ip from table(3) to any via em0 in
14001     0        0 pipe tablearg ip from any to table(4) via em0 out
65533     0        0 deny ip from table(2) to any via em0
65535  4667   857482 allow ip from any to any
 
 
Відредаговано zaza12
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

интересно , а вообще кто то делал приоритезацию трафика когда либо для своих клиентов , или у всех тут не клиенты а хомячки , для которых это не нужно? 

В микротике приоритет в основном  сильно ощутимо давал результат для очередей с помощью маркировки  layer 7 (огромная база по распилке трафика) , это можно привязать потом

Відредаговано zaza12
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Все таки додул я как это реализовть, все запустилось даже лучше чем ожидал. Результат на девайсах  ощутился сразу . Теперь   правило для 3 и 4 таблички для труб в фаерволе можно не использовать,  его заменили queue tablearg и подправить OnDisconnect, для удаления ip из новых табличек. На биллинг вроде не повлияло. Дальше можно играться с портами, или добавлять таблицы с хостами, да много чего можно накручивать.  Получилось как то так

onconnect

# с weight параметрами можно поиграться

wot=100 # Высокоприоритетный  
http=50 # HTTP
tcp=33  # Остальной TCP
all=1 # Остальной IP  , 
 # WAN -> LAN
${fwcmd} queue `expr $ID + 1001` config weight $wot   queue 32Kbytes pipe `expr $ID + 18101`   
${fwcmd} queue `expr $ID + 1002` config weight $http  queue 32Kbytes pipe `expr $ID + 18101` 
${fwcmd} queue `expr $ID + 1003` config weight $tcp   queue 32Kbytes pipe `expr $ID + 18101`  
${fwcmd} queue `expr $ID + 1004` config weight $all   queue 32Kbytes pipe `expr $ID + 18101`  
 
# LAN -> WAN
${fwcmd} queue `expr $ID + 1011` config weight $wot   queue 32Kbytes pipe `expr $ID + 101` 
${fwcmd} queue `expr $ID + 1012` config weight $http  queue 32Kbytes pipe `expr $ID + 101` 
${fwcmd} queue `expr $ID + 1013` config weight $tcp   queue 32Kbytes pipe `expr $ID + 101` 
${fwcmd} queue `expr $ID + 1014` config weight $all   queue 32Kbytes pipe `expr $ID + 101` 
 
# SHAPER
${fwcmd} table 4 add $IP `expr $ID + 18101`
${fwcmd} table 3 add $IP `expr $ID + 101`
 
#QUEUE
${fwcmd} table 10 add  $IP `expr $ID + 1001`
${fwcmd} table 20 add  $IP `expr $ID + 1002`
${fwcmd} table 30 add  $IP `expr $ID + 1003`
${fwcmd} table 40 add  $IP `expr $ID + 1004`
${fwcmd} table 11 add  $IP `expr $ID + 1011`
${fwcmd} table 21 add  $IP `expr $ID + 1012`
${fwcmd} table 31 add  $IP `expr $ID + 1013`
${fwcmd} table 41 add  $IP `expr $ID + 1014`

 

ondisconnect

# DELETE FROM SHAPER
${fwcmd} table 3 delete $IP
${fwcmd} table 4 delete $IP
${fwcmd} table 10 delete $IP
${fwcmd} table 20 delete $IP
${fwcmd} table 30 delete $IP
${fwcmd} table 40 delete $IP
${fwcmd} table 11 delete $IP
${fwcmd} table 21 delete $IP
${fwcmd} table 31 delete $IP
${fwcmd} table 41 delete $IP
 
firewall.conf
wot="53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999"
http="80,443,3128,8080,8081"
tcp="20,21,22,23,25,110,179,2222,3389"
# WAN -> LAN
${FwCMD} add 13011 queue tablearg ip from any ${wot} to table\(10\) via ${LAN_IF}  out
${FwCMD} add 13022 queue tablearg ip from any ${http} to table\(20\) via ${LAN_IF} out
${FwCMD} add 13033 queue tablearg ip from any ${tcp} to table\(30\) via ${LAN_IF} out
${FwCMD} add 13044 queue tablearg ip from any not ${wot},${http},${tcp}  to table\(40\) via ${LAN_IF}  out
 
# LAN -> WAN
${FwCMD} add 13055 queue tablearg ip from table\(11\) to any ${wot} via ${LAN_IF} in
${FwCMD} add 13066 queue tablearg ip from table\(21\) to any ${http} via ${LAN_IF} in
${FwCMD} add 13077 queue tablearg ip from table\(31\) to any ${tcp} via ${LAN_IF} in
${FwCMD} add 13088 queue tablearg ip from table\(41\) to any not ${wot},${http},${tcp}  via ${LAN_IF} in
 

#ipfw show  только что применил на рабочем биллинге, все очереди заполняются, все шейпится, приоритет работает.

00004    6490     411870 allow ip from table(2) to 10.10.100.1 dst-port 53 via re0
00004    6490    1271223 allow ip from 10.10.100.1 to table(2) src-port 53 via re0
00004       0          0 allow ip from table(2) to me dst-port 80 via re0
00004     897     851643 allow ip from me to table(2) src-port 80 via re0
00005    4742     291300 fwd 127.0.0.1,80 ip from table(47) to not me dst-port 80
00005       0          0 fwd 127.0.0.1,80 ip from 172.32.0.0/20 to not me dst-port 80
00005       0          0 reset ip from 172.32.0.0/20 to any dst-port 443
00006    3539     219256 reset ip from table(47) to any dst-port 443,444
00006       0          0 allow ip from me to 172.32.0.0/20 via re0 out
00006       0          0 allow ip from 172.32.0.0/20 to me via re0 in
00101    1238     340072 allow ip from me to 10.10.100.0/24 via re0 out
00102    1133     118770 allow ip from 10.10.100.0/24 to me via re0 in
06000 2801906  272038544 nat 1 ip from table(2) to not table(9) out xmit re1
06001 3542839 4550092147 nat 1 ip from any to me in recv re1
13011    1657     356913 queue tablearg ip from any 53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999 to table(10) via re0 out
13022 3130131 4382390839 queue tablearg ip from any 80,443,3128,8080,8081 to table(20) via re0 out
13033      17       1269 queue tablearg ip from any 20,21,22,23,25,110,179,2222,3389 to table(30) via re0 out
13044  400825  165314111 queue tablearg ip from any not 53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999,80,443,3128,8080,8081,20,21,22,23,25,110,179,2222,3389 to table(40) via re0 out
13055    1964     225587 queue tablearg ip from table(11) to any dst-port 53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999 via re0 in
13066 2180849  175868149 queue tablearg ip from table(21) to any dst-port 80,443,3128,8080,8081 via re0 in
13077      12        699 queue tablearg ip from table(31) to any dst-port 20,21,22,23,25,110,179,2222,3389 via re0 in
13088  625322   97765731 queue tablearg ip from table(41) to any not dst-port 53,9081,9100,9090,8086,3724,9091,8087,6112,6881-6999,80,443,3128,8080,8081,20,21,22,23,25,110,179,2222,3389 via re0 in
65533    3222     271084 deny ip from table(2) to any via re0
65535 3505132 2748118133 allow ip from any to any
 
Відредаговано zaza12
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

поправка , конфликт с очередями , разброс нужен побольше  , что бы очередь не забрела в чужую трубу

# WAN -> LAN
${fwcmd} queue `expr $ID + 1001` config weight $wot   queue 10  `expr $ID + 18101`   
${fwcmd} queue `expr $ID + 3002` config weight $http  queue 10  pipe `expr $ID + 18101` 
${fwcmd} queue `expr $ID + 5003` config weight $tcp   queue 10  pipe `expr $ID + 18101`  
${fwcmd} queue `expr $ID + 7004` config weight $all   queue 10  pipe `expr $ID + 18101`  
 
# LAN -> WAN
${fwcmd} queue `expr $ID + 2001` config weight $wot    queue 10  pipe `expr $ID + 101` 
${fwcmd} queue `expr $ID + 4002` config weight $http   queue 10  pipe `expr $ID + 101` 
${fwcmd} queue `expr $ID + 6003` config weight $tcp    queue 10  pipe `expr $ID + 101` 
${fwcmd} queue `expr $ID + 8004` config weight $all    queue 10  pipe `expr $ID + 101` 
 
и #QUEUE  table соответственно
${fwcmd} table 10 add  $IP `expr $ID + 1001`
${fwcmd} table 20 add  $IP `expr $ID + 3001` итд
Відредаговано zaza12
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від Plastilin
      Вітаю. Маю наступний комплект. Ubilling на Debian + Mikrotik CHR як маршрутизатор. Наче все запустилось, але виникло питання яке не вдається розрулити. Читав Wiki, ковиряв, читав знову Wiki, знову ковиряв - не допомогло.
      Чи можливо якось визначити конкретну IP адресу з пулу який видає Mikrotik клієнту через Radius? Мені пропонує обрати наступну вільну адресу з пулу при спробі зміни адреси?
      З цього з'являється додаткове питання, чи можливо контролювати доступ користувачам у яких IP назначений статично, тобто прописаний вручну? Наприклад при зміні статусу не активний - пхати до Firewall Mikrotik правила заборони доступу з IP адреси визначеної вручну, навіть якщо вона не отримана по DHCP.
       
      UPD: з першою частиною знайшов: IP_CUSTOM=1 в alter.ini 
    • Від ppv
      Потрібно було витерти одну мережу, всі абоненти з неї були перенесені в іншу. Але світить що 6 IP зайняті, хоча вона повністю вільна.
       
      ID    Мережа/CID           RВсього IP        Використано IP ▾           Вільно IPСервіс
      6      172.16.70.0/23        506                    6                                       500
       
      Підкажіть як правильно це підчистити щоб видалити мережу.
    • Від sanyadnepr
      Приветствую всех.
      Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  
      Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.
      Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.
      При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.
      Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.
      После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.
      В openpayz в платежах transactionID и не видно payID.
    • Від nightfly
      Ubilling 1.4.3 rev 9058 The Bladewood Grove
       
      Зміни в структурі БД. alter.ini: нові опції OPHANIMFLOW_ENABLED та OPHANIMFLOW_URLS котрі вмикають та керують інтеграцією з OphanimFlow. alter:ini: нова опція PHOTOSTORAGE_POSTPROCESSING, що вмикає післяобробку зображень при завантаженні в Сховище зображень. alter:ini: нова опція PHOTOSTORAGE_WATERMARK, що вмикає розміщення вотермарки на всіх зображеннях, що завантажуються. alter:ini: нова опція PHOTOSTORAGE_RECOMPRESS, що вмикає зміну компрессії завантажених зображень. alter:ini: нова опція PHOTOSTORAGE_AUTORESIZE, що вмикає автоматичне та лагідне масштабування зображень конячих розмірів. alter:ini: нова опція PHOTOSTORAGE_DRAWIMGINFO, що вмикає вдруковування в зображення відлагоджувальної інформації. alter.ini: нова опція ONDEMAND_CHARTS, що вмикає відкладене завантаження графіків завантаження користувацької смуги. userstats.ini: нова опція OPHANIM_ENABLED, що вмикає інтеграцію OphanimFlow в кабінеті користувача. Модуль Заздрість: тепер авторизаційні дані пристроїв, не відображаються в списку пристроїв. Модуль “Заздрість”: при створенні та редагуванні пристроїв, для полів “пароль” та “enable пароль” тепер використовуються інпути паролів. Модуль “Заздрість”: заздрісним пристроям додано нове поле “Порт”. Тепер в скриптах можна використовувати, відповідний макрос {PORT}. Модуль “Статистика трафіку користувача”: проведено радикальний рефакторинг. Модуль “Статистика трафіку користувача”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Статистика трафіку користувача”: виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Модуль “Статистика трафіку користувача”: додано можливість відображення графіків за останню годину з OphanimFlow. Модуль “Користувачі”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Сховище зображень”: тепер додатково перевіряє завантажувані зображення на тему їх валідності. Модуль “Фінансові операції”: виправлено відображення суми платежів користувача. Remote API: новий виклик ophanimtraff, який просто бере і синхронізує локальну БД з віддаленими джерелами OphanimFlow. Remote API: виклик userbynum тепер також опційно містить поле з “Платіжним ID” користувача. Глобально: у всіх полях вводу паролів, окрім форми входу, тепер відображається елемент керування “показати/приховати” пароль. Кабінет користувача: в модулі “Трафік” додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Кабінет користувача: в модулі “Трафік” виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Кабінет користувача: в модулі “Відеоспостереження” для NVR WolfRecorder замінено розділювач попередньо заповнених даних авторизації. OpenPayz: додано frontend portmonemulti, для отримання платежів від різних контрагентів. Інформацію по контрагентам бере з біллінгу, також використовую розширену інформацію контрагента. Платіжна система в контрагенті мусить бути створена, як PORTMONE 1984tech: додано функціонал генерації RPZ для isc-bind, спасибі @misterromanbush  
      Повний чейнджлог
      Оновлена демка
       

×
×
  • Створити нове...