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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
