Перейти к содержимому
Калькуляторы

Действительно, ступил. Простите :)

 

В ядре исходники действительно есть - ./drivers/net/ppp/pptp.c

в menuconfig так и не смог найти где включить, странно.

 

Вставил руками в .config строчку

CONFIG_PPTP=m

 

однако после make строчка которую я вставил - исчезла, и модуль так и не собрался, что за черт =\

 

 

 

Оказалось всё просто, нужно было включить CONFIG_NET_IPGRE_DEMUX, ибо CONFIG_PPTP от него зависим. Бардак :)

Изменено пользователем KotikBSd

Поделиться сообщением


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

надо сначала в netwotking support->networking options включить IP: GRE demultiplexer

Поделиться сообщением


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

ДадА, я уже нашел, копаясь в ядре, что без этой зависимости он не покажется из норки! Но спасибо!! :)

Поделиться сообщением


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

Ещё вопрос один, он изначально всплыл, но пока тестит - был не критичен.

 

По какой причине так часто повторяются номера сессий?

вот пример:

номер 0040de0f53556379

 

он вылезал много раз при подключениях:

 

Wed Feb 8 11:51:06 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 11:52:41 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 11:53:26 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:03:04 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:05:13 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:09:57 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:12:04 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:17:45 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:18:03 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:24:43 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:39:57 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 12:44:16 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 13:20:53 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 13:27:14 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 13:59:50 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 14:57:24 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 16:32:25 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 16:35:45 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 17:25:46 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 17:39:54 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 17:41:01 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 17:55:24 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 17:56:46 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 18:13:30 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 20:03:11 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Thu Feb 9 18:30:08 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Fri Feb 10 15:40:26 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

 

п.с. это точно не одна сессия, это новые подключения.

 

В биллингЕ ведутся логи каждой сессии, и если она повторяется - это вызывает у него негодования. При работе с mpd и mikrotik это встречалось очень-очень редко. А в моей ситуации через раз вылезает номер сессии который уже был, и это при том что я пока один это тестирую =\ т.е. без нагрузки.

 

 

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

 

 

mysql> select session_id from radius_sessions;

+------------------+

| session_id |

+------------------+

| 0040de0f53556379 |

| 0040de0f5355637a |

| 0040de0f5355637b |

| 0040de0f5355637f |

| 0040de0f53556381 |

| 0040de0f53556386 |

| 0040de0f53556387 |

| 0040de0f53556388 |

| 0040de0f53556395 |

+------------------+

9 rows in set (0.00 sec)

Изменено пользователем KotikBSd

Поделиться сообщением


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

Ребят, по поводу пост 1, Пост 2, нет мыслей?

Может ещё какой лог показать, или ткните куда копать.

Изменено пользователем Dimka88

Поделиться сообщением


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

Wed Feb 8 11:51:06 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

Wed Feb 8 11:52:41 2012 radius: Accounting Request attributes Acct-Session-Id: ['0040de0f53556379']

я так думаю это Interim-Update пакеты

 

вот таблица за 2 дня, попыток подключения было порядка 50, а записей всего ничего, ибо номера сессий повторяются...
давайте лучше в логах accel-ppp посмотрим

 

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

Поделиться сообщением


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

xeb, в понедельник tcpdump с двух машин сниму(client - server). После погоняю трафик на 1.4.0 В понедельник вечером отпишусь.

Поделиться сообщением


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

Давайте :) У меня пока что отсылаются только Start\Stop пакеты, в процессе сессии - ничего не отсылается. Давайте посмотрим на старт пакеты:

 

 

# cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |wc -l

202

Всего было 202 пакета.

 

берем номера из базы которые я опубликовал ранее:

 

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f53556379">' |wc -l

65

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f5355637a">' |wc -l

46

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f5355637b">' |wc -l

27

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f5355637f">' |wc -l

5

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f53556381">' |wc -l

5

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f53556386">' |wc -l

2

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f53556387">' |wc -l

2

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f53556388">' |wc -l

2

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f53556395">' |wc -l

1

 

 

Убираем 2 последних символа сессии:

 

deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |grep -i '<Acct-Session-Id "0040de0f535563' |wc -l

202

 

И получаем что в номере кроме 2 последних знаков ничего за эти дни не менялось :))

 

 

Первая запись датирована:

Deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |head

[2012-02-08 11:36:16]: info: ppp0: send [RADIUS(1) Accounting-Request id=1 <User-Nam.....

 

Последняя:

Deathstar1 ~ # cat /var/log/accel-ppp/accel-ppp.log |grep '<Acct-Status-Type Start>' |tail

2012-02-10 19:50:09]: info: ppp0: send [RADIUS(1) Accoun....

Поделиться сообщением


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

интересно, а каталог /var/run/accel-ppp в системе есть, и в нём файл seq ?

Поделиться сообщением


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

accel-ppp version 211f028919138cd2c6e3ddfb1fd8221a1273d894
accel-ppp# show stat
uptime: 3.22:44:53
cpu: 0%
mem(rss/virt): 339576/565288 kB
core:
 mempool_allocated: 3777717
 mempool_available: 1170473
 thread_count: 4
 thread_active: 1
 context_count: 137
 context_sleeping: 0
 context_pending: 0
 md_handler_count: 466
 md_handler_pending: 0
 timer_count: 439
 timer_pending: 0
ppp:
 starting: 0
 active: 110
 finishing: 0
pptp:
 starting: 0
 active: 44
l2tp:
 starting: 0
 active: 66
radius(1, 127.0.0.1):
 request count: 0
 queue length: 0
 auth sent: 13628
 auth lost(total/5m/1m): 0/0/0
 auth avg query time(5m/1m): 0/0 ms
 acct sent: 8992
 acct lost(total/5m/1m): 0/0/0
 acct avg query time(5m/1m): 0/0 ms
 interim sent: 891887
 interim lost(total/5m/1m): 3/0/0
 interim avg query time(5m/1m): 0/0 ms

...и так не хочется обратно на 1.4.0, опять конфиг вручную, опять абонентов дёргать. мда...

Поделиться сообщением


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

После недели относительно стабильной работы проблемы вернулись

https://sourceforge.net/tracker/?func=detail&aid=3486590&group_id=390718&atid=1622576

версия accel-ppp 1.5.0

 

P.S. Есть версия, которую я пока еще не подтвердил, что падение случается во время возникновения колец/флуда в некоторых сегментах/vlan-ах сети, где побороть эту проблему пока не получается по разным причинам (старое оборудование и т.д.) ...

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

 

P.P.S. Можно ли добавить меняемый на лету и определяемый в конфиге параметр и функционал в программу, ограничивающий максимальное количество подключенных клиентов. Причина: пока еще не унифицировано полностью железо (имеется разное железо с разными возможностями), один роутер может вытянуть до тысячи коннектов а некоторым после 400 плохо становится. Если бы можно было бы настроить так, что бы когда сервер набрал количество коннектов до указанного лимита, он перестал принимать новые входящие соединения, при отключении их/снижении количества ниже указанного порога, он снова начинает их принимать.

Изменено пользователем vinnipux

Поделиться сообщением


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

lan-viper, у тебя какая ось ? собери у себя пожалуйста с -DCMAKE_BUILD_TYPE=Debug -DMEMDEBUG=TRUE, запакуй и скинь мне вместе с конфигом на xeb@mail.ru

 

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

Поделиться сообщением


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

seq

Каталог есть :)

Файлов там нет :(

 

скопировал туда системный seq (/bin/seq)

Номера сессий пошли по порядку. т.е.

000000000000001 000000000000002 000000000000003 000000000000004 000000000000005 ....

Вот только неприятность, после рестарта процесса accel-ppp номера опять начинаются с 0000000000000001 0000000000000002 ...

 

В биллинге в общем-то пофиксили про дубли, но хотелось бы большего рандома, может где-то что-то подправить можно? :)

Поделиться сообщением


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

lan-viper, у тебя какая ось ? собери у себя пожалуйста с -DCMAKE_BUILD_TYPE=Debug -DMEMDEBUG=TRUE, запакуй и скинь мне вместе с конфигом на xeb@mail.ru

Отправил.

Поделиться сообщением


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

какие типы впнов используются ?

PPTP, L2TP, PPPoE

Изменено пользователем vinnipux

Поделиться сообщением


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

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

 

офлоады точно сейчас не скажу, autonegotiation отключено, сетевые intel igb драйвера, так дело в том что и с обычными сетевыми такой же результат.

 

Сетевые не в бондинге случайно?

Поделиться сообщением


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

Решил проблему подвисания сессии путём рекомпиляции accel-ppp 1.5.0 из гит и выгрузкой модуля ipfw_mod, так как сервер в качестве шейпинга использовал dummynet.

Случайно не поднимался вопрос о шейпинге скорости с выше 30 мегабит? download шейпит как часы, а вот upload завышает на 25 мегабит. При параметрах шейпера 20 и 25 мегабит или меньше всё стабильно. При использовании police теже "яйца только в профиль".

Поделиться сообщением


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

PS

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

Проблема есть.

accel-ppp# show stat
uptime: 5.10:17:54
cpu: 3%
mem(rss/virt): 1653076/2816616 kB
core:
 mempool_allocated: 14404949
 mempool_available: 350873
 thread_count: 11
 thread_active: 1
 context_count: 694
 context_sleeping: 7
 context_pending: 0
 md_handler_count: 1906
 md_handler_pending: 0
 timer_count: 1841
 timer_pending: 0
ppp:
 starting: 0
 active: 610
 finishing: 0
pppoe:
 active: 612
 delayed PADO: 0
 recv PADI: 757975
 drop PADI: 0
 sent PADO: 757975
 recv PADR(dup): 752773(93)
 sent PADS: 752754
radius(1, 78.109.240.8):
 request count: 0
 queue length: 0
 auth sent: 752951
 auth lost(total/5m/1m): 965/0/0
 auth avg query time(5m/1m): 0/0 ms
 acct sent: 50810
 acct lost(total/5m/1m): 1930/0/0
 acct avg query time(5m/1m): 0/1 ms
 interim sent: 2076516
 interim lost(total/5m/1m): 2182/0/0
 interim avg query time(5m/1m): 0/0 ms

постоянно держит в районе 500 (+/- 150) соединений и за 5 дней съел уже весь своп и 1,6 гига оперативы. Пока сидел на 1.3.5 подобного прожорства не наблюдалось - при той же нагрузке кушал 1,1 Гб оперативки а свопа так вообще не больше 50 Мбайт

 

P.S. Поправьте пожалуйста ebuild'ы для gentoo в 1.5.0 версии :) они там для 1.3.5 и архив с исходниками вручную качать приходится...

Поделиться сообщением


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

Какой-то косяк, не могу понять где собака порылась :)

 

Радиус отвечает:

info: ppp0: recv [RADIUS(1) Access-Accept id=1

<Framed-IPv6-Prefix 2a00:1468:8:66::/64>

<Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit output access-group 1 10555000 1979062 1979062 conform-action transmit exceed-action drop">

<Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit input access-group 1 37555000 7041562 7041562 conform-action transmit exceed-action drop">

<Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit output access-group 2 37555000 7041562 7041562 conform-action transmit exceed-action drop">

<Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit input access-group 2 100000000 18750000 18750000 conform-action transmit exceed-action drop">

<Microsoft MS-CHAP2-Success >

<Framed-Protocol PPP>]

 

т.е. по графику один у нас - 37555кбит\10555кбит, по второму - 100000кбит\37555кбит (вход\выход)

 

По факту имею:

 

# tc -s class show dev ppp0
class htb 1:1 root prio 0 rate 10555Kbit ceil 10555Kbit burst 1979059b cburst 1979059b 

 

# tc -s class show dev ifb0
class htb 1:2 root prio 0 rate 10555Kbit ceil 10555Kbit burst 1979059b cburst 1979059b 

в конфиге:

 

[shaper]
vendor=Cisco
attr=Cisco-AVPair
time-range=1,09:00-23:59
time-range=2,00:00-08:59
up-limiter=htb
down-limiter=htb
ifb=ifb0
r2q=10
quantum=1500
verbose=1

 

 

т.е. вход\выход = выход :) Если не передовать скорость на выход, то шейпер не ставится. т.е. вход\выход не ограничивается )))

 

 

 

п.с. а ещё шейпер не срабатывает на ipv6 для исходящей скорости, это связано с маской:

 

tc filter show dev ppp0 parent ffff:

filter protocol ip pref 1 u32

filter protocol ip pref 1 u32 fh 800: ht divisor 1

filter protocol ip pref 1 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid :1

match 00000000/00000000 at 0

 

 

на свякий случай проверил скачал\закачал исошник по ftp, скорость в районе 1.2 мбайта и туда и сюда тотал коммандер выдал. т.е. те самые 10мбит, которые я передал для исходящего шейпера :(

Изменено пользователем KotikBSd

Поделиться сообщением


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

Мне бы Ваши проблемы с шейпером, тут сам по себе демон память жрёт, вот где проблема.

 

accel-ppp version 211f028919138cd2c6e3ddfb1fd8221a1273d894
accel-ppp# show stat
uptime: 8.17:40:00
cpu: 0%
mem(rss/virt): 348892/1224316 kB
core:
 mempool_allocated: 7014343
 mempool_available: 330403
 thread_count: 4
 thread_active: 1
 context_count: 330
 context_sleeping: 0
 context_pending: 0
 md_handler_count: 1178
 md_handler_pending: 0
 timer_count: 1124
 timer_pending: 0
ppp:
 starting: 0
 active: 283
 finishing: 0
pptp:
 starting: 0
 active: 113
l2tp:
 starting: 0
 active: 170
radius(1, 127.0.0.1):
 request count: 0
 queue length: 0
 auth sent: 63825
 auth lost(total/5m/1m): 0/0/0
 auth avg query time(5m/1m): 0/0 ms
 acct sent: 20185
 acct lost(total/5m/1m): 0/0/0
 acct avg query time(5m/1m): 0/1 ms
 interim sent: 1967244
 interim lost(total/5m/1m): 3/0/0
 interim avg query time(5m/1m): 0/0 ms

И ведь не сохранил версию, на которой работали до 31 января. Надо выяснить, с какого коммита начинаются проблемы с утечками. Сегодня поставлю релиз 1.5.0, посмотрим.

Изменено пользователем lan-viper

Поделиться сообщением


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

Какой-то косяк, не могу понять где собака порылась :)

 

Радиус отвечает:

info: ppp0: recv [RADIUS(1) Access-Accept id=1

<Framed-IPv6-Prefix 2a00:1468:8:66::/64>

<Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit output access-group 1 10555000 1979062 1979062 conform-action transmit exceed-action drop">

<Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit input access-group 1 37555000 7041562 7041562 conform-action transmit exceed-action drop">

<Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit output access-group 2 37555000 7041562 7041562 conform-action transmit exceed-action drop">

<Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit input access-group 2 100000000 18750000 18750000 conform-action transmit exceed-action drop">

<Microsoft MS-CHAP2-Success >

<Framed-Protocol PPP>]

 

т.е. по графику один у нас - 37555кбит\10555кбит, по второму - 100000кбит\37555кбит (вход\выход)

 

По факту имею:

 

# tc -s class show dev ppp0
class htb 1:1 root prio 0 rate 10555Kbit ceil 10555Kbit burst 1979059b cburst 1979059b 

 

# tc -s class show dev ifb0
class htb 1:2 root prio 0 rate 10555Kbit ceil 10555Kbit burst 1979059b cburst 1979059b 

в конфиге:

 

[shaper]
vendor=Cisco
attr=Cisco-AVPair
time-range=1,09:00-23:59
time-range=2,00:00-08:59
up-limiter=htb
down-limiter=htb
ifb=ifb0
r2q=10
quantum=1500
verbose=1

 

 

т.е. вход\выход = выход :) Если не передовать скорость на выход, то шейпер не ставится. т.е. вход\выход не ограничивается )))

 

 

 

п.с. а ещё шейпер не срабатывает на ipv6 для исходящей скорости, это связано с маской:

 

tc filter show dev ppp0 parent ffff:

filter protocol ip pref 1 u32

filter protocol ip pref 1 u32 fh 800: ht divisor 1

filter protocol ip pref 1 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid :1

match 00000000/00000000 at 0

 

 

на свякий случай проверил скачал\закачал исошник по ftp, скорость в районе 1.2 мбайта и туда и сюда тотал коммандер выдал. т.е. те самые 10мбит, которые я передал для исходящего шейпера :(

писал и я об этой проблеме о некоректном шейпенге на больших тарифах, и с исходящей пока Хеb особо ничего не ответил.

Поделиться сообщением


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

Сегодня поставлю релиз 1.5.0, посмотрим.

 

Я тоже пожалуй откат сделаю... а то грохнется ночью :)

Поделиться сообщением


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

я хоть в С коде и не разбираюсь, пишу на python, однако проанализировал код accel`a, и нашел следующий кусок:

файл - limiter.c

 

 

<------>if (conf_down_limiter == LIM_TBF)

<------><------>r = install_tbf(&rth, ppp->ifindex, down_speed, down_burst);

<------>else

<------><------>r = install_htb(&rth, ppp->ifindex, down_speed, down_burst);

 

<------>if (conf_up_limiter == LIM_POLICE)

<------><------>r = install_police(&rth, ppp->ifindex, up_speed, up_burst);

<------>else

<------><------>r = install_htb_ifb(&rth, ppp->ifindex, ppp->unit_idx + 1, down_speed, down_burst);

<------>

 

если просто прочесть, то становится ясно, 1 if отвечает за DOWNload, второй за UPload, и во втором if видно, что если в конфиге стоит полисер, то создаем полисеровское правило указывая параметры - up_speed, up_burst, а если указано не полисер, нууу значет это htb, и создавая правило мы передаем параметры - down_speed, down_burst...

 

СТОП! какой нахрен down_speed, down_burst, если это правило для UPload`a :) а вот он и баг по ходу... поменял на up_speed, up_burst... пересобрал,

правда одно но, после пересборки почему-то скорость из radius не хавает, но помойму дело не в моей правке, либо просто скомпилилось криво, либо пока код листал где-то что-то задел.

НО это не важно, я поставил через telnet скорость, и о чудо, шейперы отрабатывают. не знаю что там с большими скоростями, ибо дома сижу с ноута, и файля дает максимум 10\5мбит скорость, завтра на работе затестирую, однако теперь upload начал нормально задаваться, а не ровнятся download`u :)

 

 

accel-ppp# show sessions
ifname | username | calling-sid |      ip      |  rate-limit  | type | state  |  uptime
--------+----------+-------------+--------------+--------------+------+--------+----------
ppp0   | admin    | 10.0.222.2  | 91.206.15.31 | 37555/100000 | pptp | active | 00:23:44

 

deathstar1 shaper # tc -s class show dev ppp0
class htb 1:1 root prio 0 rate 37555Kbit ceil 37555Kbit burst 7041553b cburst 7041553b
Sent 524993 bytes 9811 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 9809 borrowed: 0 giants: 0
tokens: 23437328 ctokens: 23437328

 

 

deathstar1 shaper # tc -s class show dev ifb0
class htb 1:2 root prio 0 rate 100000Kbit ceil 100000Kbit burst 18750000b cburst 18750000b
Sent 11093275 bytes 13245 pkt (dropped 0, overlimits 0 requeues 0)
rate 16bit 0pps backlog 0b 0p requeues 0
lended: 13245 borrowed: 0 giants: 0
tokens: 23437188 ctokens: 23437188

 

 

Подумал шас что может в репах уже пофиксили, ибо качал я оттуда февряла так 7-8, скачал git, нефига, эта бага там досих пор висит :)

Изменено пользователем KotikBSd

Поделиться сообщением


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

если просто прочесть, то становится ясно, 1 if отвечает за DOWNload, второй за UPload, и во втором if видно, что если в конфиге стоит полисер, то создаем полисеровское правило указывая параметры - up_speed, up_burst, а если указано не полисер, нууу значет это htb, и создавая правило мы передаем параметры - down_speed, down_burst...
блин, глаза уже замылились, спасибо что ткнули пальцем :)

 

п.с. а ещё шейпер не срабатывает на ipv6 для исходящей скорости, это связано с маской:
какая должна быть ?

Поделиться сообщением


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

я с tc плохо дружу, но думаю что выглядеть должно как-то так:

... ppp0 parent ffff: protocol ipv6 prio 1 u32 match ip6 protocol 0 0 ....

 

Однако я думаю следует добавить парочку if, если это возможно в коде, добавлять фильтры tc ip и ipv6 только в тех случаях когда у клиента реально есть ip и\или Ipv6, да бы не словить глюков на ядрах где нет ipv6. и не мусорить фильтр в тех случаях когда клиенту ipv4\ipv6 не выдают.

 

 

Правда я так и не смог добиться что-бы трафик шейпился, но скорее всего у меня руки кривые, я попытался добавить так:

tc filter add dev ppp0 parent ffff: protocol ipv6 prio 2 u32 match ip6 protocol 0 0 flowid :1  action mirred egress redirect dev ifb0 

 

 

# tc filter show dev ppp0 parent ffff:
filter protocol ip pref 1 u32 
filter protocol ip pref 1 u32 fh 800: ht divisor 1 
filter protocol ip pref 1 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid :1 
 match 00000000/00000000 at 0
       action order 1:  skbedit priority :1
       action order 2: mirred (Egress Redirect to device ifb0) stolen
       index 33 ref 1 bind 1

filter protocol ipv6 pref 2 u32 
filter protocol ipv6 pref 2 u32 fh 80a: ht divisor 1 
filter protocol ipv6 pref 2 u32 fh 80a::800 order 2048 key ht 80a bkt 0 flowid :1 
 match 00000000/00000000 at 4
       action order 33: mirred (Egress Redirect to device ifb0) stolen
       index 43 ref 1 bind 1

 

у меня появился трафик на ifb0

 

tshark -n -i ifb0
Capturing on ifb0
 0.000000     66.a0.75 -> 68.00.08     FC Unknown frame
 1.001403     66.a0.75 -> 68.00.08     FC Unknown frame
 2.002603     66.a0.75 -> 68.00.08     FC Unknown frame
 3.004486     66.a0.75 -> 68.00.08     FC Unknown frame
...

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

# tc -s class show dev ifb0
class htb 1:2 root prio 0 rate 37555Kbit ceil 37555Kbit burst 7041553b cburst 7041553b 
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
lended: 0 borrowed: 0 giants: 0
tokens: 23437484 ctokens: 23437484

 

 

Если у кого есть мысли чего в команде не хватает, или может что указал не верно, скажите, я проверю с вашими дополнениями :)

Поделиться сообщением


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.