On 16-02-15 03:59 PM, Daniel Borkmann wrote:
On 02/15/2016 08:49 PM, Jamal Hadi Salim wrote:
From: Jamal Hadi Salim <j...@mojatatu.com>
actions could change the etherproto in particular with ethernet
tunnelled data. Typically such actions, after peeling the outer header,
will ask for the packet to be reclassified. We then need to restart
the classification with the new proto header.
Example setup used to catch this:
sudo tc qdisc add dev $ETH ingress
sudo tc filter add dev $ETH parent ffff: prio 2 protocol 0xbeef \
u32 match u32 0 0 flowid 1:1 \
action ife decode reclassify
ife action is out of tree, but I believe this should be possible with
vlan action and using reclassify as tc opcode.
Ok, let me do some test with vlan example.(Note: Caught this when i was
trying to test the IFE code for submission on the flight home).
Fixes: 3b3ae880266d ("net: sched: consolidate tc_classify{,_compat}")
Signed-off-by: Jamal Hadi Salim <j...@mojatatu.com>
Has kbuild bot issues, I'd probably just move this under 'reset' label,
like:
>
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index b5c2cf2..af1acf0 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1852,6 +1852,7 @@ reset:
}
tp = old_tp;
+ protocol = tc_skb_protocol(skb);
goto reclassify;
#endif
}
The polite bot is confused in its report. I had to look at .config to
figure it out. I guess this is the point where human intervention is
needed. Basically the problem is it turned off CONFIG_NET_CLS_ACT
and recompiled; for a second i thought it was i386 specific.
I will juggle things around to make it happy.
cheers,
jamal
Thanks,
Daniel
