Problem with redirecting traffic via ifb device

Problem with redirecting traffic via ifb device

[Egor Duda]

I have a linux router which is connected via pppoe to my ISP. My
provider limits aggregate upload+download rate to some fixed amount of
kbps, so to perform shaping on my router i'm trying to do the same on my
router (to "own the queue", so to say). Since standard tbf accounts to
the packets going only one way, i wanted to create virtual ifb
interface, which will gather all incoming and outgoing packets, and then
perform appropriate shaping on it.

I'm doing it roughly in the following way:

-------------------------------------------------------------------------
tc qdisc add dev $iface ingress
tc qdisc add dev $iface parent ffff: handle 1: prio

tc filter add dev $iface parent 1: protocol ip prio 10 \
u32   match u32 0 0 flowid 1:1 \
action ipt -j MARK --set-mark 1  \
action mirred egress redirect dev ifb0

tc qdisc add dev $iface root handle 2: prio

tc filter add dev $iface parent 2: protocol ip prio 10 \
u32   match u32 0 0 flowid 2:1 \
action ipt -j MARK --set-mark 1 \
action mirred egress redirect dev ifb0
-------------------------------------------------------------------------

The strange thing is, when i run this script over vtun interface, it
works as expected, i can later attach qdiscs on ifb0 interface and
perform shaping i need. But when i try to do the same on ppp interface
(which is my primary outbound interface), packets go to ifb0 (tcpdump
shows them) but not being returned to userspace. So, when i run

ping somehost &
tcpdump -p -n -i ifb0

i see both icmp request and icmp reply packtes in tcpdump output. But
ping seems to never receive icmp replies.

My kernel version is 2.6.16.19, pppd version 2.4.4b1-1 from debian.

Am i totally misguided about how all this stuff works? In this case i'd
appreciate some links to description of 'action mirred egress redirect'.
Or is it some specific of ppp interface which prevents my setup from
working? In fact, i'd be thankful for any advice on handling my
situation (upload+download rate is limited).

As as side note, ifb implementation sets dev type to ARPHRD_ETHER to ifb
device, which prevents tcpdump from parsing packets (it treats them as
ethernet frames, while they are, in fact ip packets). I've patched ifb.c
to set device type to ARPHRD_VOID, and it fixed tcpdump problem.

egor.

Re: Problem with redirecting traffic via ifb device

[jamal]

On Mon, 2006-26-06 at 14:48 +0400, Egor Duda wrote:
> I have a linux router which is connected via pppoe to my ISP. My
> provider limits aggregate upload+download rate to some fixed amount of
> kbps, so to perform shaping on my router i'm trying to do the same on my
> router (to "own the queue", so to say). Since standard tbf accounts to
> the packets going only one way, i wanted to create virtual ifb
> interface, which will gather all incoming and outgoing packets, and then
> perform appropriate shaping on it.
> 
> I'm doing it roughly in the following way:
> 
> -------------------------------------------------------------------------
> tc qdisc add dev $iface ingress
> tc qdisc add dev $iface parent ffff: handle 1: prio
> 

The above line doesnt seem to make a lot of sense and maybe the cause of
your problems. You cant have queues on ingress.

You probably want:
tc qdisc add dev $iface root handle 1: prio
?
> tc filter add dev $iface parent 1: protocol ip prio 10 \
> u32   match u32 0 0 flowid 1:1 \
> action ipt -j MARK --set-mark 1  \
> action mirred egress redirect dev ifb0
> 

Above will mark all packets arriving on 1:0 (egress??) and mark them
with fwmark 1 and then redirect to ifb0.
If you are trying to do ingress do "parent ffff:"

> tc qdisc add dev $iface root handle 2: prio
> 

wtf? is this the egress?

> tc filter add dev $iface parent 2: protocol ip prio 10 \
> u32   match u32 0 0 flowid 2:1 \
> action ipt -j MARK --set-mark 1 \
> action mirred egress redirect dev ifb0
> -------------------------------------------------------------------------
> 

I think you need to get you scripts intent correct first. I am sorry, my
limited time would be more valuable if you narrow things down a little.
Ask questions in the user list and then come back if you have found a
bug. You definitely have bugs in the script and if you can help reducing
the variables i can help.
Some other ideas to try in narrowing down the issue:
--> Just do ingress alone first and see if that works
--> Just do egress alone and see if that works
---> do both.
--> dont use ipt - i dont trust it; the netfilter folks changed things
on me again. Pablo is helping me out resolving things. 

cheers,
jamal