Skip to contentSkip to conversation

Problem with redirecting traffic via ifb device

DISCUSSION Egor Duda 2 participants 2 messages Jun 26, 2006 – Jun 27, 2006

Subsystems (2)
lore
Share & tools
lore

Egor Duda

author
#0 lore raw

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.

#1 lore raw
Quoted 8 lines · 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.

Quoted 6 lines

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
?

Quoted 5 lines

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:"

Quoted 2 lines

tc qdisc add dev $iface root handle 2: prio

wtf? is this the egress?

Quoted 6 lines

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