sfstudio Опубликовано 9 октября, 2009 · Жалоба В общем в процессе работы над прошивкой столкнулся с проблемой невозможности нормально прикрутить IMQ (привернуть то привернул но из-за закрытых моудей есть неисправимые глюки). Решил таки приюзать IFB, поправил сырцы чтобы структуры не съезжали, вставил парочку "фильтров" чтоб wifi не падал при "летящих" на него с ifb пакетов, всё вроде OK. Делаю: tc qdisc add dev $OUTIFACE ingress tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 Если $OUTIFACE это физический ифейс или скажем vlan то всё ОК, траффик редиректиться, если делам миррор с pppX (pppoe/l2tp/pptp) то видим что редкая птица/пакет долетит до середины днепра (ifb0 ифейса). Разборки показали, что на pppoe mirror на входе получает инкапсулированный в pppoe/l2tp/pptp траффик (в зависимости от типа туннеля) и ессно отсекается match u32. Вот сижу чешу репу что делать. Чинить wifi драйвер с дизасмом или придумывать что-то для ifb или может есть ещё аналоги псевоустройства какие куда модно зарулить ВХОДЯЩИЙ на ифейс туннеля траффик? Кто решал сию проблему? На всякий, ядро 2.6.19.7, обновиться выше не реально держат бинарные блобы и крепко держат. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 9 октября, 2009 · Жалоба на вскидку - до версии 2.6.20 (или 21) с ifb было много глюков Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 октября, 2009 · Жалоба на вскидку - до версии 2.6.20 (или 21) с ifb было много глюков IFB я бэкпортил из 2.6.31, проблема в том что mirror делает ровно то что должен, берёт фрэйм и обрабатывает его заданным классификатором в нашем случае ip u32 который ессно этот фрэйм в жизнь не поймёт т.к. ожидает на входе ip а не ip инкапсулированный в pppoe. На 2.6.31 только что проверил на ноуте - ситуация ровно та же. Вывод egres mirror для обработки входящего потока с pppX интерфейсов туннелей не подходит %( Авторы советуют юзать IMQ, но беда в том, что оно не живёт по селовечьи с блобами от производителя чипа wifi как итог имеем хаотичные потери на всех интерфейсах и чтобы это полечить нуно либо иметь сырцы на руках вайфай модуля либо сидеть с дизасмом что нереально долго с учётом размера кода. Может есть ещё какие-нить псевдодевайсы или другой метод замиррорить ip с ppp+ на ifb или иной другой псевдодевайс? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 9 октября, 2009 · Жалоба Я конечно дико извиняюсь, но на ядре 2.6.18-164.el5 вот такая вот конструкция работает: /sbin/tc qdisc del dev ppp0 root 1>/dev/null 2>/dev/null /sbin/tc qdisc del dev ppp0 ingress 1>/dev/null 2>/dev/null /sbin/ip link set dev ifb0 up 1>/dev/null 2>/dev/null /sbin/tc qdisc del dev ifb0 root 1>/dev/null 2>/dev/null /sbin/tc qdisc add dev ppp0 root handle 1: htb r2q 10 /sbin/tc class add dev ppp0 parent 1: classid 1:1 htb rate 1095Kbit prio 1 quantum 1514 /sbin/tc class add dev ppp0 parent 1:1 classid 1:101 htb rate 1094Kbit ceil 1095Kbit prio 1 quantum 1514 /sbin/tc class add dev ppp0 parent 1:1 classid 1:102 htb rate 1Kbit ceil 1095Kbit prio 7 quantum 1514 /sbin/tc qdisc add dev ppp0 parent 1:101 sfq perturb 10 /sbin/tc qdisc add dev ppp0 parent 1:102 sfq perturb 10 /sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip src 0.0.0.0/0 flowid 1:102 /sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip tos 0x10 0xff flowid 1:101 /sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 1 0xff flowid 1:101 /sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 17 0xff match ip sport 53 0xffff flowid 1:101 /sbin/tc filter add dev ppp0 parent 1: protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:101 /sbin/tc qdisc add dev ppp0 handle ffff: ingress /sbin/tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid ffff: action mirred egress redirect dev ifb0 1>/dev/null 2>/dev/null /sbin/tc qdisc add dev ifb0 root handle 1: htb r2q 10 /sbin/tc class add dev ifb0 parent 1: classid 1:1 htb rate 1095Kbit prio 1 quantum 1514 /sbin/tc class add dev ifb0 parent 1:1 classid 1:101 htb rate 1094Kbit ceil 1095Kbit prio 1 quantum 1514 /sbin/tc class add dev ifb0 parent 1:1 classid 1:102 htb rate 1Kbit ceil 1095Kbit prio 7 quantum 1514 /sbin/tc qdisc add dev ifb0 parent 1:101 sfq perturb 10 /sbin/tc qdisc add dev ifb0 parent 1:102 sfq perturb 10 /sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip dst 0.0.0.0/0 flowid 1:102 /sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip tos 0x10 0xff flowid 1:101 /sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 1 0xff flowid 1:101 /sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 17 0xff match ip dport 53 0xffff flowid 1:101 /sbin/tc filter add dev ifb0 parent 1: protocol ip u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:101 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 9 октября, 2009 (изменено) · Жалоба Чем не устраивает обычный ingress policing, работающий без каких-либо IFB? В этой теме http://forum.nag.ru/forum/index.php?showtopic=51367 был неплохой пример как раз для ppp-интерфейсов. tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 Почему здесь какие-то нули? Если нужно заворачивать весь IP-трафик, то наверное лучше так: match ip src 0.0.0.0/0 Изменено 9 октября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 октября, 2009 · Жалоба Чем не устраивает обычный ingress policing, работающий без каких-либо IFB? В этой теме http://forum.nag.ru/forum/index.php?showtopic=51367 был неплохой пример как раз для ppp-интерфейсов. Тем что у меня 8мь входящих ppp интерфейсов, а шейпить нужно в сторну юзера. Внимательнее прочитайте исходный пост, сказано что это железный мелкий SOHO роутер. tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0Почему здесь какие-то нули? Если нужно заворачивать весь IP-трафик, то наверное лучше так: match ip src 0.0.0.0/0 Нули потому что это пример их документации прекрасно работающий с ethX и нифига не работающий с pppX в виде интерфейса c которого нужно миррорить!!! Мне нужно завернуть с PPP+ на IFB а не шейпить в сторону PPP, вот тут и возникает проблема с тем что match ip не будет отрабатывать т.к. на входе в итоге ip in pppoe. С pptp обшибся там действительно проблем нет. Проблема с kernel level pppoe/l2tp. Ваш пример будет вести себя аналогично. Я конечно дико извиняюсь, но на ядре 2.6.18-164.el5 вот такая вот конструкция работает: ppp0 в вашем случае это что? Для понимания процесса http://mailman.ds9a.nl/pipermail/lartc/2007q3/021561.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 9 октября, 2009 · Жалоба Я правильно понял что на ifb0 навешен u32 фильтр и он не срабатывает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 октября, 2009 · Жалоба нет, не срабатывает вот эта строка tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 т.к. protocol там получается не ip, а pppoe что прекрасно видно tcpdump`ом, по ссылке чётко всё расписано. OUTIFACE=ppp0 к примеру который pppoe до аплинка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 9 октября, 2009 · Жалоба Хм, у меня на куче PPTP-интерфейсов наложен фильтр: tc filter add dev $DEV parent 1: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 > /dev/null 2>&1 и все прекрасно срабатывает, хотя при этом в tcpdump вообще пакеты с неизвестным ethertype: listening on ifb0, link-type EN10MB (Ethernet), capture size 96 bytes 21:20:33.589313 40:00:2e:06:51:4a > 45:00:00:28:38:4e, ethertype Unknown (0x5e64), length 40: 0x0000: b634 ac1f 0280 07f9 04a6 613e 7001 83b8 .4........a>p... 0x0010: 7066 5010 0036 1a69 0000 pfP..6.i.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 9 октября, 2009 · Жалоба А может попробовать protocol 0x8864 .... чтоб pppoe заворачивать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 октября, 2009 · Жалоба А толку если мне нуно будет на ifb разбирать всё это дело, хотя мысль интересная. А то что у вас срабатывает у мну на pptp тоже срабатывает, а вот на ядреных l2tp/pppoe фигушки, на юзерспэйсных pppoe/l2tp тоже всё отрабатывает как часы. Чую там сам механизм напильника просит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 9 октября, 2009 · Жалоба accel-pptp не ядреный?? через pppox-модуль работает же Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 9 октября, 2009 · Жалоба pptp срабатывает хоть с ядерным хоть с обычным, с l2tp/pppoe сложнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 12 октября, 2009 (изменено) · Жалоба Я конечно дико извиняюсь, но на ядре 2.6.18-164.el5 вот такая вот конструкция работает:ppp0 в вашем случае это что? В моем случае это pppoe.Для понимания процесса http://mailman.ds9a.nl/pipermail/lartc/2007q3/021561.html Прочитал... Проникся... Перепугался и сделал следующий эксперимент (коннекчусь тестовому брасу): [root@bras1 ~]# uname -a Linux bras1.test 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 athlon i386 GNU/Linux [root@bras1 ~]# rpm -qa | grep rp-pppoe rp-pppoe-3.10-1 [root@bras1 ~]# ps ax | grep pppoe-server 2729 ? S 0:00 /usr/sbin/pppoe-server -k -I eth0 -L 172.26.0.64 -R 172.26.0.65 -N 32 -x 1 -S test 2987 ? Ss 0:00 pppd plugin /etc/ppp/plugins/rp-pppoe.so nic-eth0 rp_pppoe_sess 1:00:24:8c:73:f2:49 rp_pppoe_service test file /etc/ppp/pppoe-server-options 172.26.0.64:172.26.0.130 nodetach noaccomp nobsdcomp nodeflate nopcomp novj novjccomp default-asyncmap 3044 pts/0 S+ 0:00 grep pppoe-server [root@bras1 ~]# ip addr show dev ppp0 5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast qlen 3 link/ppp inet 172.26.0.64 peer 172.26.0.130/32 scope global ppp0 [root@bras1 ~]# modprobe ifb [root@bras1 ~]# ip link set dev ifb0 up [root@bras1 ~]# tc qdisc del dev ifb0 root RTNETLINK answers: No such file or directory [root@bras1 ~]# tc qdisc add dev ppp0 handle ffff: ingress [root@bras1 ~]# tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid ffff: action mirred egress redirect dev ifb0 Action 4 device ifb0 ifindex 6 [root@bras1 ~]# tc qdisc add dev ifb0 root handle 1:0 htb default 12 [root@bras1 ~]# tc class add dev ifb0 parent 1:0 classid 1:1 htb rate 2Mbit [root@bras1 ~]# tc class add dev ifb0 parent 1:1 classid 1:11 htb rate 1Mbit [root@bras1 ~]# tc class add dev ifb0 parent 1:1 classid 1:12 htb rate 1Mbit ceil 2Mbit [root@bras1 ~]# tc filter add dev ifb0 protocol ip parent 1:0 pref 5 u32 match ip src 172.26.0.130 match ip dst 172.26.0.6 flowid 1:11 [root@bras1 ~]# tc filter add dev ifb0 protocol ip parent 1:0 pref 5 u32 match ip dst 172.26.0.6 flowid 1:11 После этого с хоста 172.26.0.130 (хост подключен по pppoe к интерфейсу ppp0) гоню трафик iperf-ом на 172.26.0.6, который являет некстхопом для данного браса. Имею следующее: C:\Util>iperf.exe -c 172.26.0.6 -t 30 -i 5 ------------------------------------------------------------ Client connecting to 172.26.0.6, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1912] local 172.26.0.130 port 3786 connected with 172.26.0.6 port 5001 [ ID] Interval Transfer Bandwidth [1912] 0.0- 5.0 sec 544 KBytes 891 Kbits/sec [1912] 5.0-10.0 sec 544 KBytes 891 Kbits/sec [1912] 10.0-15.0 sec 536 KBytes 878 Kbits/sec [1912] 15.0-20.0 sec 544 KBytes 891 Kbits/sec [1912] 20.0-25.0 sec 536 KBytes 878 Kbits/sec [1912] 25.0-30.0 sec 536 KBytes 878 Kbits/sec [1912] 0.0-30.2 sec 3.17 MBytes 881 Kbits/sec На барасе вижу следующее: [root@bras1 ~]# tc -s -d class show dev ifb0; tc -s -d filter show dev ifb0 class htb 1:11 parent 1:1 prio 0 quantum 12500 rate 1000Kbit ceil 1000Kbit burst 1725b/8 mpu 0b overhead 0b cburst 1725b/8 mpu 0b overhead 0b level 0 Sent 3477264 bytes 2440 pkt (dropped 0, overlimits 0 requeues 0) rate 563224bit 49pps backlog 0b 0p requeues 0 lended: 2440 borrowed: 0 giants: 0 tokens: -5359 ctokens: -5359 class htb 1:1 root rate 2000Kbit ceil 2000Kbit burst 1850b/8 mpu 0b overhead 0b cburst 1850b/8 mpu 0b overhead 0b level 7 Sent 3499095 bytes 2519 pkt (dropped 0, overlimits 0 requeues 0) rate 567224bit 50pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: -1135 ctokens: -1135 class htb 1:12 parent 1:1 prio 0 quantum 12500 rate 1000Kbit ceil 2000Kbit burst 1725b/8 mpu 0b overhead 0b cburst 1850b/8 mpu 0b overhead 0b level 0 Sent 21831 bytes 79 pkt (dropped 0, overlimits 0 requeues 0) rate 24bit 0pps backlog 0b 0p requeues 0 lended: 79 borrowed: 0 giants: 0 tokens: 13352 ctokens: 7176 filter parent 1: protocol ip pref 5 u32 filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:11 (rule hit 2445 success 2440) match ac1a0082/ffffffff at 12 (success 2445 ) match ac1a0006/ffffffff at 16 (success 2440 ) Т.е. наблюдается явное попадание в фильтр и заворачивание трафика в класс 1:11 на интерфейсе ifb. При аплоаде трафика в Интернет (т.е. за хост 172.26.0.6) наблюдается скорость 1.85 МБит/сек и явное попадание в дефолтный класс 1:12. [root@bras1 ~]# tc -s -d class show dev ifb0; tc -s -d filter show dev ifb0 class htb 1:11 parent 1:1 prio 0 quantum 12500 rate 1000Kbit ceil 1000Kbit burst 1725b/8 mpu 0b overhead 0b cburst 1725b/8 mpu 0b overhead 0b level 0 Sent 3477264 bytes 2440 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 2440 borrowed: 0 giants: 0 tokens: -5359 ctokens: -5359 class htb 1:1 root rate 2000Kbit ceil 2000Kbit burst 1850b/8 mpu 0b overhead 0b cburst 1850b/8 mpu 0b overhead 0b level 7 Sent 5334893 bytes 7396 pkt (dropped 0, overlimits 0 requeues 0) rate 11416bit 4pps backlog 0b 0p requeues 0 lended: 501 borrowed: 0 giants: 0 tokens: 7176 ctokens: 7176 class htb 1:12 parent 1:1 prio 0 quantum 12500 rate 1000Kbit ceil 2000Kbit burst 1725b/8 mpu 0b overhead 0b cburst 1850b/8 mpu 0b overhead 0b level 0 Sent 1857629 bytes 4956 pkt (dropped 35, overlimits 0 requeues 0) rate 11416bit 4pps backlog 0b 0p requeues 0 lended: 4455 borrowed: 501 giants: 0 tokens: 13256 ctokens: 7176 filter parent 1: protocol ip pref 5 u32 filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:11 (rule hit 7357 success 2440) match ac1a0082/ffffffff at 12 (success 7357 ) match ac1a0006/ffffffff at 16 (success 2440 ) Результаты замера скорости несколько ниже заявленных, но я думаю что данное явление можно отнести на счет того, что вся тестовая система крутится на VMware. Т.е., как по мне, ожидаемые результаты достигнуты. - Что я делаю не так? Изменено 12 октября, 2009 пользователем Jugernault Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 12 октября, 2009 · Жалоба А вам в голову не приходило что 2.6.18-164.el5 (это кто шапка?) моги это и пофиксить или сломали после 18го.. Nuclearcat повторил и подтвердил багу. Багрепорт отправлен. Считайте что вам повезло. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 12 октября, 2009 · Жалоба А вам в голову не приходило что 2.6.18-164.el5 (это кто шапка?) моги это и пофиксить или сломали после 18го..Это CentOS 5.3.Приходило конечно - просто я не могу понять на каком этапе у Вас затык происходит? Nuclearcat повторил и подтвердил багу. Багрепорт отправлен. Считайте что вам повезло.В ближайшее время проверю на 2.6.30. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 12 октября, 2009 · Жалоба Центось уже не шапка, асп уже не федора =) Ну ну. Затык локализован буду разбираться по коду дальше, ядро сменить не выйдет, бинарные блобы увы и ах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
x86 Опубликовано 14 октября, 2009 · Жалоба Пара мыслей по вопросу. Пример tc filter add dev $OUTIFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 работает в 2.6.25.17 с iproute2-ss080417 - возможно в более поздних версиях iproute2 чего-то наломали. При этом tcpdump на ifbX действительно показывает инкапсулированный трафик, но tc filter работает :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 октября, 2009 · Жалоба попробуйте теперь навесить на ibf пару фильтров по src/dst адресам. Сработает? У меня как на 2.6.31 так и на 2.6.19 наблюдается бага хот и несколько по разному проявляется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 14 октября, 2009 · Жалоба в netdev сказали могут сделать патч, если очень хочится, но это неправильно Лучше шейпить типа такого: /sbin/tc filter add dev eth1 protocol 0x8864 parent 2:0 prio 1 u32 \ match u32 0x$IPREMOTE_HEX 0xffffffff at 24 flowid 2:$ID Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 октября, 2009 · Жалоба Не совсем понял что предлагается накостылить. А вот патч нужен однозначно. Неплохо бы иметь при сборке ядра возможность выбора поведения. Почему неправильно не пояснили? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 14 октября, 2009 · Жалоба Многим нужно аккаунтить траффик с заголовками. Если их отрезать - то у них такой возможности не будет вообще. Если не отрезать - то неудобно нам, но именно просто неудобно, не более того, приходится задавать offset. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 октября, 2009 · Жалоба Почему не сделать возможность выбора алгоритма при загрузке модуля? Неудобно это слабо сказано, учитывая что один и тотже ифейс может быть как pppoe так и l2tp и прочие, т.е. при автоматизации этого дела придётся городить проверки и выставлять офсет для каждого из возможных типов. В общем изврат. Таки возможность выбора алгоритма при загрузке модуля было бы более удобно, ну или выбор алгоритма при сборке ядра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 14 октября, 2009 (изменено) · Жалоба pptp-интерфейс: # tc -s -d filter ls dev ppp30 filter parent 1: protocol all pref 2 u32 filter parent 1: protocol all pref 2 u32 fh 801: ht divisor 1 filter parent 1: protocol all pref 2 u32 fh 801::800 order 2048 key ht 801 bkt 0 terminal flowid ??? (rule hit 246 success 246) match 00000000/00000000 at 0 (success 246 ) action order 1: mirred (Egress Redirect to device ifb0) stolen index 1136 ref 1 bind 1 installed 112 sec used 30 sec Action statistics: Sent 58595 bytes 123 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 На нем определенно IP (4500 0028): #tcpdump -enXvi ppp30 14:35:45.216683 Out ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 217.73.200.221.80 > 172.31.2.146.12404: ., cksum 0x8bc2 (correct), ack 687 win 6850 0x0000: 4500 0028 0000 4000 3506 f4f7 d949 c8dd E..(..@.5....I.. 0x0010: ac1f 0292 0050 3074 0ef4 f0ab 1c31 6be2 .....P0t.....1k. 0x0020: 5010 1ac2 8bc2 0000 На IFB куда-то делись 6 6айт: #tcpdump -eni ifb0 14:34:09.301064 40:00:35:06:f4:f7 > 45:00:00:28:00:00, ethertype Unknown (0xd949), length 40: 0x0000: c8dd ac1f 0292 0050 303a 080f 48f9 fcc7 .......P0:..H... 0x0010: a285 5010 1a31 23eb 0000 что-то тут нечисто.... чешу репу :) UPD может дело в datalinktype, который интерпретирует tcpdump? tcpdump: listening on ppp30, link-type LINUX_SLL (Linux cooked) tcpdump: listening on ifb0, link-type EN10MB (Ethernet) но тогда все-равно не понятно, куда делись 6 байт - 4500 0028 0000 Изменено 14 октября, 2009 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
x86 Опубликовано 14 октября, 2009 · Жалоба попробуйте теперь навесить на ibf пару фильтров по src/dst адресам. Сработает?У меня как на 2.6.31 так и на 2.6.19 наблюдается бага хот и несколько по разному проявляется. Сейчас работают фильтры по протоколу и размеру пакета. Добавил по src адресу:tc filter add dev ifb1 parent 1:1 protocol ip prio 1 u32 match ip src 213.180.204.8 flowid 1:6 - тоже работает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...