[Dimka88]

А как тогда через init-скрипт это сделать?

для обычного pptp

у меня было так

 

 

netcat(ом) послать на [cli] tcp=127.0.0.1:2001 команду shutdown

 

echo 'shutdown' | nc -q0 127.0.0.1 2001

[Abram]

А как тогда через init-скрипт это сделать?

для обычного pptp

у меня было так

 

 

netcat(ом) послать на [cli] tcp=127.0.0.1:2001 команду shutdown

 

echo 'shutdown' | nc -q0 127.0.0.1 2001

Фу так. Есть же accel-cmd:

accel-cmd 'shutdown'

[u.s.s.r]

...

Фу так. Есть же accel-cmd:

accel-cmd 'shutdown'

эта команда доступна из git

[u.s.s.r]

Тут у меня возник вопрос, можно ли как то сказать accel-ppp, чтобы не отключал сессии ppp если радиус не доступен? или хотя бы задать явно таймаут?

[xeb]

[radius]

acct-timeout=

 

но при этом должен присутсововать атрибут Acct-Interim-Interval

[morfair]

kayot

У меня b02e7ad2059416b2d8b1b4e6e8c12132ed4a6cc3 вылетает постоянно. Причем в данный момент accel-ppp просто зависсает и не отвечает на запросы пользователей, не вываливаясь при этом в корку.

Эээ, не пугайте меня =) У меня как раз b02e7ad2059416b2d8b1b4e6e8c12132ed4a6cc3 на самой боевой машине стоит.

[Dimka88]

Фу так. Есть же accel-cmd:

accel-cmd 'shutdown'

 

Внезапно утром вспомнил, что есть accel-cmd, зашёл написать, но уже поправили =)

[purecopper]

morfair Вы наверное lua не пользуете :)

[morfair]

morfair Вы наверное lua не пользуете :)

lua? =)

[purecopper]

Как-то так:

http://sourceforge.net/apps/trac/accel-ppp/wiki/IPoE_dhcp_lua_ru

 

Мы выдираем из пакета opt82 и скармливаем его в качестве username радиусу.

[it1804]

У меня есть подозрение, что неправильно работают следующие параметры:

 

[radius]
max-try=3
acct-timeout=400

 

Судя по документации, при таких установках должно произвестись три попытки отправить аккаутинг до радиуса с таймаутом каждой 400 сек, и при неудаче всех через 20 мин. отрубить сессию. У нас сейчас есть небольшие проблемы на биллинге (радиус+база данных), при которых ровно в полночь база данных не успевает обработать все запросы и, соответственно, радиус не все аккутинг-пакеты отрабатывает. При этом сессии начинают отбиваться уже около 00:10 ч. Не понимаю как это может начать происходить раньше 00:20 ч.

 

У меня получилось, что max-try для interim-update не учитывается. Сессия рвется через acct-timeout + acct-interim-interval секунд, а timeout определяет время между повторными посылками. Это при fail-time=0, если это имеет значение.

[replicant]

Насколько опасны ворнинги при сборке версии 1.7.3? Ядро 3.2.54.

 

Scanning dependencies of target radius
[ 54%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/stat_accm.c.o
[ 56%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/dict.c.o
[ 57%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/req.c.o
[ 58%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/packet.c.o
[ 60%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/auth.c.o
[ 61%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/acct.c.o
[ 62%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/serv.c.o
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c: In function 'load_config':
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:394:33: warning: 'acct_secret' may be used uninitialized in this function [-Wmaybe-uninitialized]
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:366:8: note: 'acct_secret' was declared here
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:395:16: warning: 'acct_port' may be used uninitialized in this function [-Wmaybe-uninitialized]
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:365:6: note: 'acct_port' was declared here
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:391:15: warning: 'auth_port' may be used uninitialized in this function [-Wmaybe-uninitialized]
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:362:6: note: 'auth_port' was declared here
[ 64%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/dm_coa.c.o
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/dm_coa.c: In function 'coa_request':
/usr/src/accel-ppp-1.7.3/accel-pppd/radius/dm_coa.c:180:7: warning: 'prev_class' may be used uninitialized in this function [-Wmaybe-uninitialized]
[ 65%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/radius.c.o
Linking C shared library libradius.so
[ 65%] Built target radius

 

И можно ли как-то этого избежать?

[u.s.s.r]

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

 

20:20:58.root@accel-ppp:(~) echo "terminate sid 07101cdcd752dc3f" | nc 127.0.0.1 2000
accel-ppp version 1.7.3
▒▒▒▒▒▒"accel-ppp# 20:21:24.root@accel-ppp:(~)

 

Если телнетом, то все нормально

 

20:24:48.root@accel-ppp:(~)telnet 127.0.0.1 2000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
accel-ppp version 1.7.3
accel-ppp# terminate sid 07101cdcd752dc3f

Изменено 14 февраля, 2014 пользователем u.s.s.r

[xeb]

echo "terminate sid 07101cdcd752dc3f" | nc 127.0.0.1 2000

echo "terminate sid 07101cdcd752dc3f" | nc 127.0.0.1 2001

 

[u.s.s.r]

echo "terminate sid 07101cdcd752dc3f" | nc 127.0.0.1 2000

echo "terminate sid 07101cdcd752dc3f" | nc 127.0.0.1 2001

Спасибо огромное, а я все не понимал, что это у всех 2001 порт, а у меня 2000.

[cdi]

Странная ситуация с шейпером, почему то шейпит весь трафик, а не каждому pppoe . В чем проблема может быть?

[srg555]

tc qdisc show

[replicant]

[shaper]
vendor=Cisco
attr=Cisco-AVPair

up-limiter=htb
down-limiter=htb
cburst=153400
ifb=ifb0
r2q=10
quantum=1500
verbose=0
down-burst-factor=0.1
up-burst-factor=1.0

 

В dmesg валится примерно такое

 

[ 996.498553] HTB: quantum of class 10001 is big. Consider r2q change.

[ 996.498578] HTB: quantum of class 1001A is big. Consider r2q change.

[ 1059.947421] HTB: quantum of class 10001 is big. Consider r2q change.

[ 1059.947445] HTB: quantum of class 1001B is big. Consider r2q change.

[ 1088.011856] HTB: quantum of class 10001 is big. Consider r2q change.

 

Как это отключить? Уменьшить quantum (MTU на туннелях 1400) или где-то в другом месте (r2q) подкрутить?

 

Скорости такого порядка

class htb 1:35 root prio 0 rate 41920Kbit ceil 41920Kbit burst 41920b cburst 153390b
class htb 1:34 root prio 0 rate 104800Kbit ceil 104800Kbit burst 104800b cburst 153374b
class htb 1:3b root prio 0 rate 20960Kbit ceil 20960Kbit burst 20960b cburst 153395b
class htb 1:3a root prio 0 rate 20960Kbit ceil 20960Kbit burst 20960b cburst 153395b
class htb 1:39 root prio 0 rate 41920Kbit ceil 41920Kbit burst 41920b cburst 153390b
class htb 1:38 root prio 0 rate 41920Kbit ceil 41920Kbit burst 41920b cburst 153390b
class htb 1:3f root prio 0 rate 20960Kbit ceil 20960Kbit burst 20960b cburst 153395b
class htb 1:3e root prio 0 rate 41920Kbit ceil 41920Kbit burst 41920b cburst 153390b
class htb 1:3d root prio 0 rate 20960Kbit ceil 20960Kbit burst 20960b cburst 153395b
class htb 1:3c root prio 0 rate 62880Kbit ceil 62880Kbit burst 62880b cburst 153387b

Изменено 18 февраля, 2014 пользователем replicant

[NiTr0]

r2q крутите.

r2q = max rate/512k (512k = 64kB*8 - max quantum)

[replicant]

r2q крутите.

r2q = max rate/512k (512k = 64kB*8 - max quantum)

Попробую посидеть с калькулятором. Разброс скоростей всего в 5 раз от 20 Мбит до 100 Мбит.

Хотя и при таких настройках шейпит все красиво и правильно.

Изменено 19 февраля, 2014 пользователем replicant

[kayot]

replicant

А еще правильнее - выставлять везде quantum вручную. Это одно из legacy-сообщений линуксового TC, на работу никак не влияет но логи мусорит.

Для вашего диапазона скоростей ставьте максимальный quantum=65535, где-то встречал такую официальную рекомендацию для скоростей от 1-2мбит и выше и практика такой алгоритм успешно подтверждает.

[replicant]

replicant

А еще правильнее - выставлять везде quantum вручную. Это одно из legacy-сообщений линуксового TC, на работу никак не влияет но логи мусорит.

Для вашего диапазона скоростей ставьте максимальный quantum=65535, где-то встречал такую официальную рекомендацию для скоростей от 1-2мбит и выше и практика такой алгоритм успешно подтверждает.

 

Тут другая засада вылезает. Расчет показывает оптимальный r2q в диапазоне от 1000 до 1700, я ставлю 1500. Тогда quantum красивый, но мессаджи все равно ползут из-за вот этого

 

qdisc htb 1: dev ifb0 root refcnt 2 r2q 10 default 0 direct_packets_stat 0 - тут не красиво с r2q

qdisc htb 1: dev ppp0 root refcnt 2 r2q 1500 default 1 direct_packets_stat 0 - тут все красиво

 

т.е. на ifb0 r2q=10, т.е. по-дефолту. Вот его ХЗ где изменить. Явно где-то не в accel-ppp.conf

 

Даже, если я закомментирую в accel-ppp.conf параметр r2q, а quantum сделаю =65535, то все равно r2q на ifb0 будет =10.

 

Отдельного скрипта для шейпера нет. Шейплю средствами accel.

[kayot]

replicant

Я ж об этом и говорю. Важен только quantum. Если он не задан он рассчитывается по ceil и r2q. И при дефолтном значении r2q=10 и ceil>1M получаются слишком большие цифры и варнинг, при этом система ставит quantum=max=65k.

Не считайте r2q, ставьте сразу quantum=65k.

 

Если в accel параметры задавать нельзя - поправьте в исходнике, делов то))

Изменено 19 февраля, 2014 пользователем kayot

[replicant]

kayot, а как же рекомендации к 1500 < quantum < 60000 ?

 

В accel-ppp.conf ставится r2q и quantum, но это касается только pppX, а на ifb это не распространяется.

Для ifb это где-то в другом месте изменяется. Возможно в исходниках в shaper.c, но не уверен что так будет правильно.

 

Именно ifb источник сообщений в dmesg. Теоретически можно забить на dmesg, но неприятно.

[replicant]

В итоге решил сделать так (пока по идиотски, но работает):

 

стартую аксель, он добавляет такую строку (видно ее в tc qdisc show dev ifb0)

tc qdisc add dev ifb0 root handle 1: htb default 0 r2q 10

 

я ее прибиваю

tc qdisc del dev ifb0 root handle 1: htb default 0 r2q 10

и тут же стартую с r2q 1500, а только потом разрешаю юзерам коннекты к 1723 порту, чтобы не создавали туннели раньше времени пока на ifb0 ничего в tc не повисло

 

после этого в dmesg тишина

--------------------------

 

Также пересобрал изменив в shaper.c r2q=1000 ... вроде бы стало нормально.

 

Было бы роскошно, если бы xeb вынес r2q для ifb тоже в конфиг, чтобы не мучать исходник.

 

quantum для разных скоростей выглядит при r2q=1000 так

class htb 1:22 root prio 0 quantum 7860 rate 62880Kbit ceil 62880Kbit burst 62880b/8 mpu 0b overhead 0b cburst 153387b/8 mpu 0b overhead 0b level 0
class htb 1:23 root prio 0 quantum 5240 rate 41920Kbit ceil 41920Kbit burst 41920b/8 mpu 0b overhead 0b cburst 153390b/8 mpu 0b overhead 0b level 0
class htb 1:27 root prio 0 quantum 10480 rate 83840Kbit ceil 83840Kbit burst 83840b/8 mpu 0b overhead 0b cburst 153385b/8 mpu 0b overhead 0b level 0
class htb 1:24 root prio 0 quantum 13100 rate 104800Kbit ceil 104800Kbit burst 104800b/8 mpu 0b overhead 0b cburst 153374b/8 mpu 0b overhead 0b level 0
class htb 1:25 root prio 0 quantum 2620 rate 20960Kbit ceil 20960Kbit burst 20960b/8 mpu 0b overhead 0b cburst 153395b/8 mpu 0b overhead 0b level 0

 

Соответственно и tc -s qdisc sh dev ifb0

qdisc htb 1: root refcnt 2 r2q 1000 default 0 direct_packets_stat 0

 

 

Теперь dmesg молчит как и должен, т.к. quantum в порядке. Если разброс скоростей по тарифам большой, то красоту наводить немного сложнее. Надо просто точнее считать.

Т.е. если есть 100 Мбит/с и 2 Мбит/с, то будет ловить либо small, либо big, если юзать htb средствами accel-ppp. Разброс не более чем 40 раз в пределах диапазона допустимых значений quantum.

Изменено 20 февраля, 2014 пользователем replicant