одновременная работа /sbin/tc handle .. fw и u32 match невозможна?

опс, не ту клавишу нажал :)

ПРоблема следующая.
Не могу заставить работать несколько правил, в части из которых
используются handle fw директивы (т.е. направляем в нужные цепочки уже промаркированные заранее в iptables пакеты), а в других - u32 match
директивы.

Т.е. к примеру команды
/sbin/tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x1 fw flowid 2:32

/sbin/tc filter add dev eth0 parent 2:0 protocol ip prio 1 u32 match ip protocol 6 0xff match u8 0x00 0xff at 2 flowid 2:31

одновременно работать не будут.
Первая вводится успешно, после ввода второй - 
RTNETLINK answers: Invalid argument

Можно ввести сколько угодно команд u32 match, все они проглотятся.
Но если после этого вводить команду с использованием handle fw - она выдаст туже ошибку.
Аналогичная ситуация произойдет, если сначала ввести н-цеть handle fw.

Как можно заставить эти команды работать одновременно?
используется iproute2-20010824-r5 (на Gentoo)

Мне лично кажеться, что второе правило просто не правильно написано
в htb tutorial пример:
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
match ip src 1.2.3.4 flowid 1:11

Нет, правила написаны верно.
Оба вышеприведенных правила взяты из реально работающих скриптов.

Если вводить любое из этих правил (первым) - то они принимаются (видны по ip filter show) и работают.

Но вот одновременно два ввести не получается.

Даже если упростить пример и взять за одно из правил
/sbin/tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x1 fw flowid 2:32

за второе 
/sbin/tc filter add dev eth0 protocol ip parent 2:0 prio 1 u32 \ 
match ip src 1.2.3.4 flowid 2:32

все равно вылезает ошибка
RTNETLINK answers: Invalid argument

При вводе сначала второго, потом первого правила - аналогично.
Не спасает даже ip filter del введенного первым правила.


p.s.
а команда

/sbin/tc filter add dev eth0 parent 2:0 protocol ip prio 1 u32 match ip protocol 6 0xff match u8 0x00 0xff at 2 flowid 2:31

абсолютно правильная :-)
она отлавливает мелкие пакеты (<256 байт) и отправляет их в высокоприорететный канал. 
Но тут выяснилось, что довольно большая часть p2p трафики (edonkey/overnet) так же использует мелкие пакеты. Вот их то и не хотчелось бы отправлять в скоростной канал (а то подобный трафик его полностью забивает). 
Ловить p2p трафик можно модулем p2p для iptables или просто маркировать пакеты (в iptables) для -m owner --uid-owner mldonkey.

Только вот не получается совместить множество команд u32 match 
и одну-две - handle fw.

я лично всегда думал, что uid_owner это что-то ближе к user_id самого linux usera создавшего клиентский socket что-то типа:
uid=501(marats) gid=501(marats) groups=501(marats)
uid=504(java131) gid=504(java131) groups=504(java131)

для ограничения p2p трафика я использую модуль ipt_p2p http://sourceforge.net/projects/iptables-p2p, так-же пропатчил ядро 2.4.24 добавив из iptables patch-o-matic (http://www.netfilter.org/patch-o-matic/) возможности connlimit, CONNMARK, CLASSIFY.
Особенно мне нравиться опция CLASSIFY и не нужны ни какие фильтры в tc,iptables сама распределяет пакеты по очередям (классам).

Но всё замечательно работает, даже при использовании стандартного limit скрипта из ipt_p2p/example, где используеться CONNMARK для пометки p2p трафика, а далее fw фильтр в tc.

Сейчас пробую ограничить max кол-во одновременных p2p соединений с одного клиентского хоста, но не очень получаеться. Хотя для одного хоста на котором провожу эксперементы всё работает, как только добовляю ещё 30 правил для 30 компов, всё начинает глючить, но это уже другая история.
Можем объединить усилия :)
Я делаю следующим образом:

создаю цепочку в которую будет поподать весь p2p трафик
iptables -t mangle -N my_p2p_chain

направляю весь p2p трафик в эту цепочку
iptables -t mangle -A PREROUTING -m p2p --p2p all -j my_p2p_chain

далее для каждого хоста добовляю правило
iptables -t mangle -A my_p2p_chain -s x.x.x.x -p tcp -m connlimit --connlimit-above 5 -j DROP
(пробовал так-же вместо DROP ставить -j MARK --set-marks 0x100 и потом в цепочке FORWARD делал REJECT всем помеченным пакетам, результат тот-же) всё ужасно глучить, может есть какие мысли?

>я лично всегда думал, что uid_owner это что-то ближе к user_id самого >linux usera создавшего клиентский socket что-то типа: >uid=501(marats) gid=501(marats) groups=501(marats) >uid=504(java131) gid=504(java131) groups=504(java131)

Да это так. Только я не вижу противоречий с моим сообщением. p2p программа (mldonkey) запускается из под юзера mldonkey (sudo ...) Соответственно, весь трафик от нее ловится по -m owner.

>Особенно мне нравиться опция CLASSIFY и не нужны ни какие фильтры в tc,iptables сама распределяет пакеты по очередям (классам). спасибо, сегодня-завтра посмотрю этот модуль.

Но все разрулить им у меня не выйдет - дело в том, что изначально mark-и используются для роутинга трафика на три различных интерфейса. (ip rule add fwmark 0xHHH table zzz)

Т.е. весь трафик уже имеет определенные метки-марки, его нельзя перемеркировывать - а то упадет весь роутинг. Если бы в mark-ах можно было бы не только ставить абсолютные значения MARK, а еще и суммировать (прибавлять к существующему) или даже (идеальный вариант) была бы бинарная арифметика (AND, OR, XOR), то ситуацию можно было бы разрулить. А так... если MARK поставлен единожды, то нельзя к нему ни прибавить, ни отнять - только установить заново.

А по поводу iptables -t mangle -A my_p2p_chain -s x.x.x.x -p tcp -m connlimit --connlimit-above 5 -j DROP

может имеет смысл делать это действие на этапе таблицы filter? Для -t nat не рекомендуют использовать DROP и подобные команды, возможно и для -t mangle не стоит?

на счёт user id, я думал, что речь идёт о роутере, у которого одна задача роутить, а на счёт -t filter я сам узнал перечетав в очередной раз iptables-tutorial и сообщение из этого форума которое выше :)
Приду домой буду пробывать, но наверно не сегодня о результатах напишу