I don't know whether the iptable filter works in this circumstance, we filter by ip address, more like this: /sbin/tc filter add dev ifb0 parent 1:0 protocol ip prio 100 u32 match ip src 172.20.0.0/20 classid 1:200 You need to use "tc -s filter show dev ifb0" to see if there is traffic going through any of the rules, and you can then try to debug that rule. There have been several mentions about problems with iptables marks not being seen by tc, except this depends on the kernel. Oh, also note that ifb's ideas of what is source and destination are the opposite of br0, so you might try both ways to begin. Once you see traffic flowing in the filters, you can adjust your speed accordingly. On Mon, Sep 15, 2014 at 1:09 AM, Teresa e Junior <teresaejunior@xxxxxxxxx> wrote: > On Mon, 15 Sep 2014 00:18:43 -0400, Mike Schmidt wrote: >> >> Basically, you cannot control inbound traffic with tc, except through >> policing, which is what the wondershaper rule does. Policing does not >> shape traffic, it simply drops the excess, which is why it is so >> unreliable. That is why the throttling works when only you set the >> src to 192.168.0.5. The solution is to use an intermediate device, >> like ifb, or imq, depending on the distribution you are running. A >> typical example is here: >> http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb > > > Thank you so much for your answer, Mike! > > I had a look at the link you gave to me, and after wrestling against > some errors, I came up with this: > > #!/bin/sh > > tc qdisc del dev ifb0 root > tc qdisc del dev wlan0 ingress > > modprobe ifb > > tc qdisc add dev ifb0 root handle 1: prio > tc qdisc add dev ifb0 parent 1:1 handle 10: sfq > tc qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 20kbit \ > buffer 1600 limit 3000 > tc qdisc add dev ifb0 parent 1:3 handle 30: sfq > tc filter add dev ifb0 protocol ip pref 1 parent 1: handle 1 fw classid 1:1 > tc filter add dev ifb0 protocol ip pref 2 parent 1: handle 2 fw classid 1:2 > > ifconfig ifb0 up > > tc qdisc add dev wlan0 ingress > tc filter add dev wlan0 parent ffff: protocol ip prio 10 u32 \ > match u32 0 0 flowid 1:1 \ > action xt -j MARK --set-mark 1 \ > action mirred egress redirect dev ifb0 > > I'm using xt instead of ipt because ipt gives me the error "bad action > type ipt" and, as mentioned in Debian bug #710450, ipt is just a symlink > to xt: > $ readlink /usr/lib/tc/m_ipt.so > m_xt.so > > The problem with this approach is that it doesn't work, actually, but > probably because I'm doing something wrong. I suppose download and > upload would have to be limited to 20kbit, right? When I run the above > script, the speeds are not limited at all. I get only: > > tablename: mangle hook: NF_IP_PRE_ROUTING > target: MARK set 0x1 index 0 -- Mike SCHMIDT CTO Intello Technologies Inc. mike.schmidt@xxxxxxxxxxx Canada: 1-888-404-6261 x320 USA: 1-888-404-6268 x320 Mobile: 514-409-6898 www.intello.com -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
