Subject: Problem with redirecting traffic via ifb device

From: Egor Duda <[email-masked]>
Date: Mon, 26 Jun 2006 14:48:00 +0400

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.