Ingress qdisc via fwmark

[Chris Elston <celston@katalix.com>]

Hello,

I'm having a little trouble getting ingress policing working, filtering
based on an iptables fwmark. The iptables fwmark is being set with a new
L2TP packet classifier:

# iptables -A INPUT -t mangle -s 192.168.101.20 -m l2tp --tidR380 --sid4787 --typeÚta -j MARK --set-mark 1

(Note that I have also tried adding to the PREROUTING mangle table
too...)

I have confirmed that the classifier is marking packets:

# iptables -L INPUT -t mangle -v
Chain INPUT (policy ACCEPT 59641 packets, 44M bytes)
 pkts bytes target     prot opt in     out     source               destination         
  172  7912 MARK       all  --  any    any     lns                  anywhere             l2tp tid 52380 sid 34787 type data MARK set 0x1

I have set up an ingress qdisc with:

# tc qdisc add dev eth1 handle ffff: ingress

And a filter to police the marked packets:

# tc filter add dev eth1 protocol ip parent ffff: prio 1 handle 1 fw police rate 32768 burst 10k drop flowid :1

But none are getting dropped:

# tc -s qdisc show dev eth1
<snip>
qdisc ingress ffff: parent ffff:fff1 ---------------- 
 Sent 15712712 bytes 186225 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

I believe from the HOWTO:
(http://www.linuxdocs.org/HOWTOs/Adv-Routing-HOWTO-14.html section 14.2)
that this should be possible, but I've also found mention
(http://www.spinics.net/lists/lartc/msg18021.html) that the new-style
policer happens before PREROUTING.

Also, this diagram suggests that queueing to the ingress qdisc happens
before classification takes place:
http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

I'm using kernel 3.2.x, with CONFIG_NET_ACT_POLICE=m. 

A previous scheme I had DID manage to drop ingress L2TP packets matching
the specification using the tc u32 filter - but the tc commands were
becoming very complicated and would be difficult to manage dynamically,
hence the switch to an iptables classifier.

I'm hoping that someone on the list can let me know whether this is
actually possible with contemporary kernels, and if so, where I'm going
wrong.

Thanks,

Chris.