harry390625

Попробую c src. Нет, в tcpdump редирект был как раз с интерфейса ppp0. Да, обсуждали именно эту проблему, но решения так и не нашли... Неужели никто не решил проблему?

Вы не очень внимательно читали предыдущие посты. Процитирую: впновский айпи клиента - 10.0.0.7 #!/bin/sh modprobe ifb ip link set dev ifb0 up ip addr add 172.16.10.1/32 dev ifb0 tc qdisc del dev ifb0 root 2> /dev/null > /dev/null tc qdisc del dev ifb0 ingress 2> /dev/null > /dev/null tc qdisc del dev ppp0 root 2> /dev/null > /dev/null tc qdisc del dev ppp0 ingress 2> /dev/null > /dev/null tc qdisc add dev ppp0 ingress handle ffff: tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0 tc

jugernault, если я заворачиваю ppp+ интерфейсы на ifb0, то данные правила не срабатывают: tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.1 flowid 1:101 tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.2 flowid 1:102 tc filter add dev ifb0 parent 1: protocol ip u32 match ip src 192.168.1.3 flowid 1:104 Я об этом уже писал тут в данной теме. Думал вы предлагаете какое-то другое решение...

jugernault, не догоняю я что-то... Можно пример или ссылку где почитать можно?

jugernault, заворачиваю я интерфейсы ppp+ на ifb0, строю на нем структуру классов htb - а как назначить одному клиенту 101 класс, а другому 102?

(( так не хотелось патчить... помучаю еще ifb спасибо за обсуждение, может еще кто что подскажет

а если отлавливать на eth0, то не по src, не по dst клиентский айпи мы не увидим... метки через iptables для ifb не работают. Возникает вопрос - как идентифицировать пользователя?

Пробовал и так, но по айпи (впновский айпи клиента - 10.0.0.7) все равно не отлавливает: tc filter add dev ifb0 parent 1: protocol all prio 2 u32 match ip dst 10.0.0.7/32 flowid 1:40 А tcpdump -i ifb0 выдает следующее: 16:57:43.156952 00:28:d2:23:40:00 (oui Unknown) > c0:a8:00:21:45:00 (oui Unknown), ethertype Unknown (0x8006), length 44: 0x0000: 006d 0a00 0007 5e64 bfd4 0624 0050 3070 .m....^d...$.P0p 0x0010: 3fbd 627f 5f64 5010 ffff 4f10 0000 ?.b._dP...O... 16:57:43.156955 00:28:d2:24:40:00 (oui Unknown) > c0:a8:00:21:45:00 (oui Unknown), ethertype U

Разделять мир и ua не нужно, поэтому вполне устроит ifb. Помогите тогда с реализацией, а то второй день бъюсь и не пойму где туплю... Нашел такой пример (eth0 - инет, eth2 - локалка), то тут отлавливают пользователей по айпи, у меня же пользователи подключаются по ВПН (pptp), поэтому по айпи отловить их не получается. Как быть? #!/bin/sh modprobe ifb ip link set dev ifb0 up ip addr add 172.16.10.1/32 dev ifb0 tc qdisc del dev ifb0 root 2> /dev/null > /dev/null tc qdisc del dev ifb0 ingress 2> /dev/null > /dev/null tc qdisc del dev eth0 root 2> /dev/null > /

т.е. средствами ifb, без лишних патчей нужных для imq, такую схему реализовать нельзя?

twg, у меня тоже сейчас так реализовано, но тогда получается что у каждого пользователя жестко задан гарантированный канал интернета и в случае если в данный момент качает только один пользователь, то канал у него не расширяется до общей ширины. Я же хотел перейти на "динамический" шейпер, т.е. чтобы можно было задавать гарантированную полосу и максимальную в случае простоя линии.

Возникла похожая задача - тоже пытаюсь написать шейпер для ppp+ интерфесов с помощью ifb. Поделитесь пожалуйста своими решениями данного вопроса