Проблемы с шейпером?

[l1ght 377]

Вот недавно взял на вооружение UBilling. Очень им доволен, за исключением одной вещи. В последнее время началось нечто мистическое, а именно: у меня прикручен mpd5 с pppoe для авторизации, при подключении пользователя в 98% всё проходит нормально, но есть идивидуумы, которые не получают пайп. В таблице видно tablearg, допустим : table 4 10.10.10.2 8102, пишу комманду ipfw pipe 8102 show и получаю пустой вывод. Поковырял логи и пришёл к выводу, что скрипт GetSpeed и GetUpSpeed выдают не правильные результаты. 

Нормальный вывод:

2013.06.04 15:05:19 CONNECT: ID-0;LOGIN-%user_login%;IP-10.10.10.134;CASH-0.000000;SPEED-10000;UPSPEED-10000,MAC-14:88:70:11:43:30

Не нормальный вывод:

2013.06.04 18:04:13 CONNECT: ID-3;LOGIN-%user_login%;IP-10.10.10.178;CASH-0.000000;SPEED-20002000;UPSPEED-20002000,MAC-14:88:11:31:73:28

Взято из лога /var/stargazer/allconnect.log

Помогите побороть это.

[nightfly 1 239]

Да. Но такого быть в принципе не должно. Да и пайпы с такими странными скоростями физически создаваться не должны, что логично.

 

Для начала следует убедиться, что у пользователя %user_login% ничего странного не нарисовано в поле "Переназначение скорости".

 

Также очень хорошо бы увидеть:

1. вывод /etc/stargazer/GetSpeed %user_login%

2. было бы хорошо узнать что у вас нарисовано в OnConnect

[l1ght 377]

Да. Но такого быть в принципе не должно. Да и пайпы с такими странными скоростями физически создаваться не должны, что логично.

 

Для начала следует убедиться, что у пользователя %user_login% ничего странного не нарисовано в поле "Переназначение скорости".

 

Также очень хорошо бы увидеть:

1. вывод /etc/stargazer/GetSpeed %user_login%

2. было бы хорошо узнать что у вас нарисовано в OnConnect

я там в принципе ничего не менял. Версия Ubilling: 0.4.1 rev 2603.

[nightfly 1 239]

Окей, если OnConnect дефолтный - остаются открытыми вопросы только по поводу /etc/stargazer/GetSpeed %user_login% и значения параметра "Переназначение скорости"

[l1ght 377]

 

Да. Но такого быть в принципе не должно. Да и пайпы с такими странными скоростями физически создаваться не должны, что логично.

 

Для начала следует убедиться, что у пользователя %user_login% ничего странного не нарисовано в поле "Переназначение скорости".

 

Также очень хорошо бы увидеть:

1. вывод /etc/stargazer/GetSpeed %user_login%

2. было бы хорошо узнать что у вас нарисовано в OnConnect

я там в принципе ничего не менял. Версия Ubilling: 0.4.1 rev 2603.

# /etc/stargazer/GetSpeed gai

20022002

 

 

 

Да. Но такого быть в принципе не должно. Да и пайпы с такими странными скоростями физически создаваться не должны, что логично.

 

Для начала следует убедиться, что у пользователя %user_login% ничего странного не нарисовано в поле "Переназначение скорости".

 

Также очень хорошо бы увидеть:

1. вывод /etc/stargazer/GetSpeed %user_login%

2. было бы хорошо узнать что у вас нарисовано в OnConnect

я там в принципе ничего не менял. Версия Ubilling: 0.4.1 rev 2603.

# /etc/stargazer/GetSpeed gai

20022002

Переназначение скорости тоже не трогал

[l1ght 377]

Окей, если OnConnect дефолтный - остаются открытыми вопросы только по поводу /etc/stargazer/GetSpeed %user_login% и значения параметра "Переназначение скорости"

Есть ещё такой прикол /etc/stargazer/GetSpeed vd176 и пусто

[nightfly 1 239]

 

# /etc/stargazer/GetSpeed gai

20022002

Ок, будем теперь считать, что проблема с юзером

 

А теперь немного магии. Идете в "Консоль разработчика", и тыцаете в "SQL консоль" следующие запросы:

 

SELECT * from `userspeeds` where `login`='gai'

SELECT *
FROM `users`
LEFT JOIN tariffs
ON users.Tariff=tariffs.name WHERE login='gai'

Відредаговано 2013-06-04 16:56:45 nightfly

[l1ght 377]

 

 

# /etc/stargazer/GetSpeed gai

20022002

Ок, будем теперь считать, что проблема с юзером

 

А теперь немного магии. Идете в "Консоль разработчика", и тыцаете в "SQL консоль" следующие запросы:

 

SELECT * from `userspeeds` where `login`='gai'

SELECT *
FROM `users`
LEFT JOIN tariffs
ON users.Tariff=tariffs.name WHERE login='gai'

array (

0 =>

array (

'id' => '179',

'login' => 'gai',

'speed' => '0',

),

1 =>

array (

'id' => '187',

'login' => 'gai',

'speed' => '0',

),

)

 

вот вывод с первого запроса

[l1ght 377]

 

 

 

# /etc/stargazer/GetSpeed gai

20022002

Ок, будем теперь считать, что проблема с юзером

 

А теперь немного магии. Идете в "Консоль разработчика", и тыцаете в "SQL консоль" следующие запросы:

 

SELECT * from `userspeeds` where `login`='gai'

SELECT *
FROM `users`
LEFT JOIN tariffs
ON users.Tariff=tariffs.name WHERE login='gai'

array (

0 =>

array (

'id' => '179',

'login' => 'gai',

'speed' => '0',

),

1 =>

array (

'id' => '187',

'login' => 'gai',

'speed' => '0',

),

)

 

вот вывод с первого запроса

но у меня там у всех юзеров 0

 

 

 

 

 

# /etc/stargazer/GetSpeed gai

20022002

Ок, будем теперь считать, что проблема с юзером

 

А теперь немного магии. Идете в "Консоль разработчика", и тыцаете в "SQL консоль" следующие запросы:

 

SELECT * from `userspeeds` where `login`='gai'

SELECT *
FROM `users`
LEFT JOIN tariffs
ON users.Tariff=tariffs.name WHERE login='gai'

array (

0 =>

array (

'id' => '179',

'login' => 'gai',

'speed' => '0',

),

1 =>

array (

'id' => '187',

'login' => 'gai',

'speed' => '0',

),

)

 

вот вывод с первого запроса

но у меня там у всех юзеров 0

но то что там 2 ид, мне очень не нравится

[nightfly 1 239]

вот вывод с первого запроса

Хорошо, только почему их два?

 

Сделайте по дороге

DELETE from `userspeeds` where `id'='179'

[l1ght 377]

 

вот вывод с первого запроса

Хорошо, только почему их два?

 

Сделайте по дороге

DELETE from `userspeeds` where `id'='179'

Неверный запрос:

 

DELETE from `userspeeds` where `id'='179'

 

а я вот понятия не имею, почему их там два..

[l1ght 377]

 

 

вот вывод с первого запроса

Хорошо, только почему их два?

 

Сделайте по дороге

DELETE from `userspeeds` where `id'='179'

Неверный запрос:

 

DELETE from `userspeeds` where `id'='179'

 

а я вот понятия не имею, почему их там два..

ммм, доглядел и исправил запрос

Console debug data

Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /usr/local/www/apache22/data/billing/modules/general/sqlconsole/index.php on line 172

 

Результат

Запрос вернул пустой результат

[l1ght 377]

 

вот вывод с первого запроса

Хорошо, только почему их два?

 

Сделайте по дороге

DELETE from `userspeeds` where `id'='179'

это решило проблему. GetSpeed теперь выдаёт нужный результат. спасибо, вам, добрый человек 

[l1ght 377]

 

вот вывод с первого запроса

Хорошо, только почему их два?

 

Сделайте по дороге

DELETE from `userspeeds` where `id'='179'

а теперь вопрос следующий, GetSpeed vd176 в ответ пусто. проверил, ид только один у него

[l1ght 377]

 

 

вот вывод с первого запроса

Хорошо, только почему их два?

 

Сделайте по дороге

DELETE from `userspeeds` where `id'='179'

а теперь вопрос следующий, GetSpeed vd176 в ответ пусто. проверил, ид только один у него

пардон, не то спорол, там тариф не назначен, человек ещё не подключен

[nightfly 1 239]

 

а я вот понятия не имею, почему их там два..

ммм, доглядел и исправил запрос

 

    Console debug data

Хорошо, лишний оверрайд грохнули.

 

это решило проблему. GetSpeed теперь выдаёт нужный результат. спасибо, вам, добрый человек 

Внезапно.

 

а теперь вопрос следующий, GetSpeed vd176 в ответ пусто. проверил, ид только один у него

Окей, давайте посмотрим на

 

SELECT Tariff,Login,IP from `users` WHERE `login`='vd176'

 

Из того что вижу, есть чувство, что у вас слегка крякнута целостность данных. Могу предположить, что вы вырубили настоятельно(!) рекомендуемую и заведомо опасную опцию SAFE_REGMODE и пытались либо дважды зарегистрировать одного и того же пользователя, либо попытались его регистрировать удалив такого-же, но не дождавшись полного удаления предыдушего (описано в FAQ).

[nightfly 1 239]

пардон, не то спорол, там тариф не назначен, человек ещё не подключен

Ну значит я был очень прав в своем желании увидеть SELECT Tariff,Login,IP from `users` WHERE `login`='vd176'

 

В любом случае такие артефакты не критичны, поскольку при смене тарифов и чего только можно вызывается событие reset() которое всеравно подымет правильный пайп. Это к слову тоже описано в FAQ