Ну слепо копировать из примеров не стоит, не факт, что они рабочие :) Покажите ls -lR, например. Включите VERBOSE и PROGRESS и в /var/log/messages загляните

А, Вова, это ты...Ну может и не работает что, кто его знает.

Ну я и по документации на wiki пробовал делать, и по аналогии с примерами. Где-то затык там явно.

В сизифе кстати скорее всего такая же проблема.

Ты ls -lR всё-таки покажи и в messages глянь, что пишет. У меня, например, всё работает.

В общем, поковырялся вчера с этим и обнаружил, что в классе 1:1 требуется создать фильтры, заворачивающие в него весь трафик:
% cat /etc/net/ifaces/ppp0/qos/1/1/filter
proto ip prio 1 u32 match ip src 0.0.0.0/0
proto ip prio 2 u32 match ip src 0.0.0.0/0
proto ip prio 5 u32 match ip src 0.0.0.0/0
proto ip prio 6 u32 match ip src 0.0.0.0/0

без этого фильтры вида
% cat /etc/net/ifaces/ppp0/qos/1/1/10/filter
protocol ip prio 1 u32  match ip tos 0x10 0xff

не добавляются вовсе, причём tc ошибок не выдаёт, и код завершения 0 :(

Перевешиваю на сизиф и меняю summary. Нужно исправить примеры, идущие в пакете.

QoS-HTB-user-guide, как нетрудно догадаться, --- адаптация иерархии из HTB user guide к синтаксису /etc/net. В своё время этот пример был рабочим, насколько я помню. Смотреть нужно.

Прошло пять лет...

Проблема по прежнему актуальна. Я отписался по ее поводу здесь:

http://lists.altlinux.org/pipermail/community/2014-November/683086.html

Я даже испугался, что как это до меня этого никто не обнаружил. Примеры в документации правильные и они до сих пор работают. Беда в самом etcnet.

Дело в том, что при настройке iproute фильтры должны иметь своим родителем базовый класс HTB (например, с идентификатором 1:0), а поток пакетов направлять в его дочерний класс (например, с идентификатором 1:11). В этом случае правильная команда для настройки tc должна быть:

tc filter add dev $1 protocol ip parent 1:0 prio 1 handle 1 fw flow 1:11

И здесь возникает противоречие. С одной стороны, etcnet-описание фильтр должен быть размещен в каталоге родительского класса, чтобы ему был правильно назначен parent. С другой стороны, согласно предлагаемой идеологии etcnet фильтр должен быть размещен в каталоге класса, куда направляется поток.

Попытка вынести описание на уровень родительского класса не дает нужного результата --- etcnet автоматически указывает направление в сам родительский класс.

Я решил проблему, сломав слегка файл /etc/net/scripts/config-qos. А именно, убрал из этого скрипта автоматическое направление в дочерние классы при задании фильтра, а нужное направление указал явно в файле filter на уровне родительского класса. При этом, однако, пришлось перенести инициализацию фильтров в конец процесса инициализации, иначе при задании фильтра дочерние классы еще не созданы и фильтр не может найти нужное направление. Правда, есть еще глюки с созданием лишних записей, сейчас воюю с этим. Может быть, позже опубликую патч с таким вот промежуточным решением.

Но как решить проблему идеологически грамотно --- пока не знаю...

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

Поэтому я поставил зависимость от

https://bugzilla.altlinux.org/show_bug.cgi?id=30523

и считаю, что эту проблему можно закрыть.

(В ответ на комментарий №10)
> Думаю, что эта проблема не связана с документацией. По крайней мере, в
> документации все настройки описаны именно так, как ожидается, чтобы они
> работали. Просто фильтр привязывается к некорректному родителю.
> 
> Поэтому я поставил зависимость от
> 
> https://bugzilla.altlinux.org/show_bug.cgi?id=30523
> 
> и считаю, что эту проблему можно закрыть.

Ну так и надо было закрыть.