Перейти до

UHW vs Должники


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

вот допустим человек поменял мак адрес, его скинуло на страницу активации нового мака

он проактивировался, переподключил соединение - всё работает

 

но если у человека долг и он активировал новый мак, то не работает ничего

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

если человек при деньгах, OnConnect пришивает новый мак

в итоге должниковый пользователь после смены мак адреса не может попасть на свою страницу и вогнать себя в кредитный ад

 

пруф:

 

May  7 10:17:32 isp kernel: arp: 00:11:22:33:44:59 attempts to modify permanent entry for 10.10.8.2 on vlan10
наверное в OnDisconnect надо добавить очистку мака или типо того

 

arpcmd="/usr/sbin/arp"
${arpcmd} -d $IP
Ссылка на сообщение
Поделиться на других сайтах

 

пруф:

Это не пруф а банальное не понимание механики.

 

 

наверное в OnDisconnect надо добавить очистку мака или типо того

Тоже бред сивой кобылы. less OnConnect / man arp

 

 

 

May 7 10:17:32 isp kernel: arp: 00:11:22:33:44:59 attempts to modify permanent entry for 10.10.8.2 on vlan10

У вас банально reset пользователя не происходит. Смотрите соседний топик на тему.

Ссылка на сообщение
Поделиться на других сайтах

я понимаю всю механику (наверное)

при конекте пользователя привязывается его текущий мак к ип в фришке, через скрипт ОнКонект (арп -С ип мак)

если пользователь неактивен (нехватает денег), то привязка не происходит

однако старая привязка не снимается, и при смене мак адреса должника система его отвергает

прописав те две строки в ОнДисконект, при входе в долг привязка ип к маку во фришке снимается и его можно свободно менять (арп -д ип)

 

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

Ссылка на сообщение
Поделиться на других сайтах

 

при конекте пользователя привязывается его текущий мак к ип в фришке, через скрипт ОнКонект (арп -С ип мак)

Угу - убивается старая привязка и заменяется новым.

 

 

если пользователь неактивен (нехватает денег), то привязка не происходит

поскольку для неактивных пользователей в принципе не может вызваться OnConnect

 

 

однако старая привязка не снимается, и при смене мак адреса должника система его отвергает

усе верно

 

 

прописав те две строки в ОнДисконект, при входе в долг привязка ип к маку во фришке снимается и его можно свободно менять (арп -д ип)

....и мы получаем отсутствие привязки вообще для всех неактивных пользователей... что при безпарольном входе в ЛК как минимум чревато.

 

Поэтому оно все есть, такое как есть.

Логика - следующая  нету бабок, нефиг менять железо, и так работать не будет. Оплатишь долг - тебя автоматом подымет с новым МАС-ом.

Ссылка на сообщение
Поделиться на других сайтах

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

надо чтоб и должники имели возможность вписать свой мак в систему (чтоб не делал это админ)

впринципе я в первом посте вопрос задал, сам себе на него и ответил как

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

Ссылка на сообщение
Поделиться на других сайтах

 

надо чтоб и должники имели возможность вписать свой мак в систему (чтоб не делал это админ)

Да, вполне себе традиционно. Как правило люди следуют одним из двух путей:

 

1. Конвертируют уже вместе с MAC-ами

2. На этапе конвертации, втыкают всем кредит с просрочкой достаточной для работы юзера некоторое время.

 

 

впринципе я в первом посте вопрос задал, сам себе на него и ответил как

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

Ага ;)

Ссылка на сообщение
Поделиться на других сайтах

1. Конвертируют уже вместе с MAC-ами

вот только в старой базе треть маков не заполнена, а треть уже не актуальна

такое бывает когда провайдер сделал ставку на впн  :facepalm:

Ссылка на сообщение
Поделиться на других сайтах

 

1. Конвертируют уже вместе с MAC-ами

вот только в старой базе треть маков не заполнена, а треть уже не актуальна

такое бывает когда провайдер сделал ставку на впн  :facepalm:

 

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

Ссылка на сообщение
Поделиться на других сайтах

заметил очень неприятный момент

если я в админке кидаю пользователя в другой диапазон ип адресов, то для него скрипт дисконекта не вызывается

тоесть старая арп запись в системе и в таблице старый ип остаётся

 

вот например кидаю юзера с 10 сети в 13 сеть

был ип 10.10.8.2, присвоило клиенту новый 10.13.8.3

 

? (10.13.8.3) at 00:11:22:33:44:54 on vlan13 permanent [vlan]
? (10.10.8.2) at 00:11:22:33:44:54 on vlan10 permanent [vlan] 

---table(3)---
10.10.8.2/32 102
10.13.8.3/32 102
---table(4)---
10.10.8.2/32 8102
10.13.8.3/32 8102
это конечно хорошо что пользователь может дальше пользоваться услугой, пока я ему влан на порту не переключу, но имхо так не должно быть

остаются нежелательные хвосты

я не силён в рнр, так что найти куда пихнуть ОнДисконект немогу  :unsure:

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

Ссылка на сообщение
Поделиться на других сайтах

заметил очень неприятный момент

если я в админке кидаю пользователя в другой диапазон ип адресов, то для него скрипт дисконекта не вызывается

тоесть старая арп запись в системе и в таблице старый ип остаётся

 

вот например кидаю юзера с 10 сети в 13 сеть

был ип 10.10.8.2, присвоило клиенту новый 10.13.8.3

 

? (10.13.8.3) at 00:11:22:33:44:54 on vlan13 permanent [vlan]
? (10.10.8.2) at 00:11:22:33:44:54 on vlan10 permanent [vlan] 

---table(3)---
10.10.8.2/32 102
10.13.8.3/32 102
---table(4)---
10.10.8.2/32 8102
10.13.8.3/32 8102
это конечно хорошо что пользователь может дальше пользоваться услугой, пока я ему влан на порту не переключу, но имхо так не должно быть

остаются нежелательные хвосты

я не силён в рнр, так что найти куда пихнуть ОнДисконект немогу  :unsure:

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

 

Странно.  По идее старгейзер при смене IP пользователя всегда сначала последовательно вызывает для него OnDisconnect после чего OnConnect.

В любом случае тыканье по менялке айпишек вызывает следующий результат:

 

/var/stargazer/allconnect.log

2014.05.12 15:32:02 DISCONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000
2014.05.12 15:32:02 CONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000;SPEED-5120;UPSPEED-5120,MAC-14:88:67:87:40:21
2014.05.12 15:32:41 DISCONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.5;CASH-180.000000
2014.05.12 15:32:41 CONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.5;CASH-180.000000;SPEED-5120;UPSPEED-5120,MAC-14:88:67:87:40:21
2014.05.12 15:33:01 DISCONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000
2014.05.12 15:33:01 CONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000;SPEED-5120;UPSPEED-5120,MAC-14:88:67:87:40:21


/var/log/stargazer.log

2014-05-12 15:30:09 -- Admin 'admin', 127.0.0.1: User 'ap_p3iu': 'IP' parameter changed from '172.30.0.7' to '172.30.0.5'. 
2014-05-12 15:32:01 -- Admin 'admin', 127.0.0.1: User 'ap_p3iu': 'IP' parameter changed from '172.30.0.5' to '172.30.0.7'. 
2014-05-12 15:32:41 -- Admin 'admin', 127.0.0.1: User 'ap_p3iu': 'IP' parameter changed from '172.30.0.7' to '172.30.0.5'. 
2014-05-12 15:33:01 -- Admin 'admin', 127.0.0.1: User 'ap_p3iu': 'IP' parameter changed from '172.30.0.5' to '172.30.0.7'. 
Відредаговано nightfly
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

В любом случае тыканье по менялке айпишек вызывает следующий результат:

 

2014-05-12 15:32:01 -- Admin 'admin', 127.0.0.1: User 'ap_p3iu': 'IP' parameter changed from '172.30.0.5' to '172.30.0.7'. 

2014.05.12 15:32:02 DISCONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000
2014.05.12 15:32:02 CONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000;SPEED-5120;UPSPEED-5120,MAC-14:88:67:87:40:21 

 

как видно из результата - дисконнект вызывается уже с новым ип :)

 

тоесть биллинг отправляет старгайзеру команду на смену ип, а уже потом вызывает ресет (дисконнект/конеект)

а надо другая последовательность: дисконект -> смена ип -> коннект

Відредаговано RockManX
Ссылка на сообщение
Поделиться на других сайтах

 

В любом случае тыканье по менялке айпишек вызывает следующий результат:

как видно из результата - дисконнект вызывается уже с новым ип :)

 

тоесть биллинг отправляет старгайзеру команду на смену ип, а уже потом вызывает ресет (дисконнект/конеект)

а надо другая последовательность: дисконект -> смена ип -> коннект

 

Эммм. Логично. Надо бы посмотреть что можно с этим сделать.

Ссылка на сообщение
Поделиться на других сайтах

Собственно слегка причесал модуль, начиная с 0.5.4 rev 3456.

Если очень спичит затестить - следует утащить себе вот эту либу: https://github.com/nightflyza/Ubilling/blob/master/api/libs/api.compat.php (вот в прямом виде) а также сам обновленный модуль https://github.com/nightflyza/Ubilling/blob/master/modules/general/pl_ipchange/index.php (опять же вот чистый сорс).

 

Результат:

2014.05.12 16:39:18 DISCONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000
2014.05.12 16:39:19 CONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.5;CASH-180.000000;SPEED-5120;UPSPEED-5120,MAC-14:88:67:87:40:21

Ссылка на сообщение
Поделиться на других сайтах

вот после очередного ковыряния ОнКонекта возникла идея

вгонять всех не в пайпы, а в очередя

чтоб например торренты и прочие ботнеты имели низкий приоритет, а вконтактик и контра у юзверей высокий

 

вот не найду точку откуда делать, создавать очередя в фаерволе, а ОнКонект вгоняет в них пайпы

или очередя конфигурировать в нёмже 

 

куда начал копать (пока не проверял):

онконект

${fwcmd} pipe `expr $ID + 101` config bw $UPSPEED$SCOUNT queue 32Kbytes
${fwcmd} pipe `expr $ID + 8101` config bw $SPEED$SCOUNT queue 32Kbytes
${fwcmd} queue `expr $ID + 101` config pipe `expr $ID + 101` weight 30 queue 20 mask dst-addr 0xffffffff
${fwcmd} queue `expr $ID + 8101` config pipe `expr $ID + 8101` weight 30 queue 20 mask src-addr 0xffffffff
${fwcmd} queue `expr $ID + 1101` config pipe `expr $ID + 101` weight 60 queue 20 mask dst-addr 0xffffffff
${fwcmd} queue `expr $ID + 18101` config pipe `expr $ID + 8101` weight 60 queue 20 mask src-addr 0xffffffff

${fwcmd} table 3 add $IP `expr $ID + 101`
${fwcmd} table 4 add $IP `expr $ID + 8101`
${fwcmd} table 13 add $IP `expr $ID + 1101`
${fwcmd} table 14 add $IP `expr $ID + 18101`
а в файрволе

${FwCMD} add queue tablearg ip from any to table\(14\) src-port 80 via vlan* out
${FwCMD} add queue tablearg ip from table\(13\) to any dst-port 80 via vlan* in
${FwCMD} add queue tablearg ip from any to table\(4\) via vlan* out
${FwCMD} add queue tablearg ip from table\(3\) to any via vlan* in
в ту сторону копаю или нет? ибо очередей разных хотю создать много  :rolleyes:
Ссылка на сообщение
Поделиться на других сайтах

 

вгонять всех не в пайпы, а в очередя

Да хоть в стамбул.

 

Биллинг для того и опенсорс.

 

 

чтоб например торренты и прочие ботнеты имели низкий приоритет, а вконтактик и контра у юзверей высокий

...а еще иметь нах@р не нужный геморрой, с ручным рассчетом размеров таблиц дамминета и прочих буферов.

По этой причине в дефолтных заготовках и натыкано пайпов для юзеров. Плюс на эту же механику завязаны динамические шейпера.

Ссылка на сообщение
Поделиться на других сайтах

...а еще иметь нах@р не нужный геморрой, с ручным рассчетом размеров таблиц дамминета и прочих буферов.

По этой причине в дефолтных заготовках и натыкано пайпов для юзеров. Плюс на эту же механику завязаны динамические шейпера.

и действительно, слишком громоздко всё будет, хотя в необозримом будущем я вернусь к этому вопросу и запилю как надо

 

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

буду локальный ретрекер ставить, чтоб юзеры через друг-друга качали свой дом2, а от вирусов пусть сами избавляются

Ссылка на сообщение
Поделиться на других сайтах

 

...а еще иметь нах@р не нужный геморрой, с ручным рассчетом размеров таблиц дамминета и прочих буферов.

По этой причине в дефолтных заготовках и натыкано пайпов для юзеров. Плюс на эту же механику завязаны динамические шейпера.

и действительно, слишком громоздко всё будет, хотя в необозримом будущем я вернусь к этому вопросу и запилю как надо

 

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

буду локальный ретрекер ставить, чтоб юзеры через друг-друга качали свой дом2, а от вирусов пусть сами избавляются

 

Простота - залог здоровья ;)

Ссылка на сообщение
Поделиться на других сайтах

ради эксперемента была раньше добавлена сеть в билинге

теперь она мне больше не нужна, да и на самом сервере её уже нету

пытаюсь удалить сеть в биллинге - жалуется на пользователей живых в этой сети

я проверил всех двух пользователей и оба в других сетях

я удалил эту сеть из услуг, из нас, из dhcp, но всёравно ссылается на живых пользователей

можно както форсировать этот процесс? или просто удалить запись в базе?

Ссылка на сообщение
Поделиться на других сайтах

 

я удалил эту сеть из услуг, из нас, из dhcp, но всёравно ссылается на живых пользователей

Это сигнализирует о том, что каких-то пользователей у вас в процесе перекосило и их нетхосты остаются прибитыми к этой сети.

 

 

я проверил всех двух пользователей и оба в других сетях

а покажите ка

SELECT * from `nethosts`

из консоли разработчика.

Ссылка на сообщение
Поделиться на других сайтах

а покажите ка

SELECT * from `nethosts`
из консоли разработчика.

 

угу, ктото сидит

array (
  0 => 
  array (
    'id' => '2',
    'netid' => '1',
    'ip' => '10.0.0.3',
    'mac' => '00:11:22:33:44:f5',
    'option' => 'NULL',
  ),
  1 => 
  array (
    'id' => '16',
    'netid' => '2',
    'ip' => '10.10.8.2',
    'mac' => '00:11:22:33:44:55',
    'option' => 'NULL',
  ),
  2 => 
  array (
    'id' => '10',
    'netid' => '3',
    'ip' => '10.13.8.2',
    'mac' => '00:19:e0:61:00:1d',
    'option' => 'NULL',
  ),
)
но реальных пользователей только два последних
Ссылка на сообщение
Поделиться на других сайтах

 

0 =>

array (

'id' => '2',

'netid' => '1',

'ip' => '10.0.0.3',

'mac' => '00:11:22:33:44:f5',

'option' => 'NULL',

),

если  этого пользователя действительно не существует в природе, и первая подсеть занята только им - просто сделайте

DELETE from `nethosts` WHERE `id`='2'

удалите по нормальному сеть и живите себе счастливо.

 

Хотя такой еффект не может не настораживать - при нормальном удалении нормального пользователя нетхосты и прочие такие штуки чистятся в первую же очередь.

Ссылка на сообщение
Поделиться на других сайтах

Хотя такой еффект не может не настораживать - при нормальном удалении нормального пользователя нетхосты и прочие такие штуки чистятся в первую же очередь.

а я вроди никого не удалял, только изменял существующих

причём часто и по разному, но руками в базу не лез, ручной сменой ип не страдал, ещё когда на компе тестовом начал гонять это дело, было весело наблюдать как старгайзер переставал реагировать на команды биллинга

 

запрос помог - сеть удалилась

Ссылка на сообщение
Поделиться на других сайтах

при ребутах в логи сыплется такое, мож из-за этого

root@isp:/home/test # cat /var/log/stargazer.log | grep stat
2014-05-13 15:57:23 -- Cannot write stat for user enkur6ap4_t7as.
2014-05-13 15:57:23 -- Couldn't save user stat:
2014-05-13 15:57:23 -- Cannot write stat for user enkur6ap42_71c7.
2014-05-13 15:57:23 -- Couldn't save user stat:
2014-05-13 16:06:00 -- Cannot write stat for user enkur6ap4_t7as.
2014-05-13 16:06:00 -- Couldn't save user stat:
2014-05-13 16:06:00 -- Cannot write stat for user enkur6ap42_71c7.
2014-05-13 16:06:00 -- Couldn't save user stat:
2014-05-13 16:28:37 -- Cannot write stat for user enkur6ap4_t7as.
2014-05-13 16:28:37 -- Couldn't save user stat:
2014-05-13 16:28:37 -- Cannot write stat for user enkur6ap42_71c7.
2014-05-13 16:28:37 -- Couldn't save user stat:
Ссылка на сообщение
Поделиться на других сайтах

 

при ребутах в логи сыплется такое, мож из-за этого

Это вопли store_mysql о невозможности записать в базу изменения состояния юзера и его статистики. Почему такое происходит, лучше спросить у madf-a.

Хотя на установках собранных UBinstaller я такого в принципе не видел.

Ссылка на сообщение
Поделиться на других сайтах

 

при ребутах в логи сыплется такое, мож из-за этого

Это вопли store_mysql о невозможности записать в базу изменения состояния юзера и его статистики. Почему такое происходит, лучше спросить у madf-a.

Хотя на установках собранных UBinstaller я такого в принципе не видел.

 

Ясен пень почему — MySQL же.

Может база побилась.

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Вхід

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

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

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

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

    • Від Sir_Prikol
      Доброго времени суток.
      Было-бы шикарно реализовать следующую фичу:
      Используем модуль uhw для смены мак, а что если добавить туда функционал полной регистрации абонента с выбором тарифа.
      Кому-то может показаться это бесполезным занятием, но бывают моменты когда данный функционал просто необходим. В тех-же общагах, когда львиная доля времени уходит на регистрацию пользователей, а не на мониторинг сети.
       
      В какую сторону копать? 
      Может там достаточно просто, на PHP передать параметр в биллинг через API?
    • Від alienkras
      Доброго времени суток! прошу у вас помощи по UHW настроил все по гайду , не перенаправляет на страницу uhw, ip выдает 
      OS freebsd 9.3
      может что-то с фаерволом ? я просто в фаерволах не оч разбираюсь.
      зарание спасибо!!!!
    • Від Golthana
      Устанавливаем JavaScript редирект с умолчательного VirtualHost на URL где расположен UHW в /usr/local/www/apache24/data/index.php:
       
      Там нет указанного файла. Есть только index.xml (it's work) Можно просто туда добавить в тело сайта редирект?
    • Від awg
      просьба сразу не пинать. только пытаюсь начать разбираться с UHW. начал читать документацию: http://wiki.ubilling.net.ua/doku.php?id=uhw, сразу обратил внимание на отличия в путях, например:  /usr/local/www/apache22/data/index.php такого нет, а есть /usr/local/www/apache24/data/billing/index.php
      такого /usr/local/www/apache22/data/.htaccess нет вовсе, и т.д. Понимаю что дока старая и версия аппача 22 а сейчас 24
       
      Пожалуйста, скажите эта документация актуальна только пути подкорректировать? Или может я зря себе ломаю голову а оно уже из коробки работает?
    • Від ruslyk123
      Доброго дня шановна громадо. Цікавить наступне питання.
      Вирішили ми сьогодні скористатися сервісом самоактивація в модулі UHW. Самоактивація проходить добре в білінг прописуєця новий мак клієнта, але в dhp конфігах мак не міняєця... Підскажіть, куди дивитися? Що правити? В uhw.ini включена опція selfact_enabled=1 , в php.ini також включена allow_url_fopen. Буду вдячний за будь-які поради.
×
×
  • Створити нове...