etcnet-0.9.7-alt0.M40.1 4.0/branch от конца августа 2008. # pwd /etc/net/ifaces/eth0/qos # cp -rp /usr/share/doc/etcnet-0.9.7/examples/QoS-HTB-user-guide/1 . # eqos eth0 start # tc filter show dev eth0 # Самописные скрипты для конфигурирования шейперов всё добавляют.
Ну слепо копировать из примеров не стоит, не факт, что они рабочие :) Покажите 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 > > и считаю, что эту проблему можно закрыть. Ну так и надо было закрыть.
