Potential u32 classifier bug.

Potential u32 classifier bug.

[Waskiewicz Jr, Peter P]

I've recently been trying to use tc with u32 classifiers to filter
ethernet traffic based on ethertype.  Although we found and fixed an
issue in the sch_prio call to tc_classify() (thanks Patrick!), this
didn't fix the actual filtering issue.  For those of you who are curious
or are tc-savy, I'm really in a bind and need some help.  This is what I
have so far:
 
Filter to identify and move traffic to a different flow:
 
# tc qdisc add dev eth2 root handle 1: rr bands 8 priomap 7 7 6 6 5 5 4
4 3 3 2 2 1 1 0 0 multiqueue
# tc filter add dev eth2 parent 1: protocol 802_3 prio 1 u32 match u32
0x00000800 0x0000ffff at 12 flowid 1:6

Now this hits tc_classify(), and tp->protocol and skb->protocol match
(be16 of 8 - ETH_P_802_3, which is what I expect), so u32_classify() is
called through the tp->classify() func pointer.  This is where things
get weird.

In net/sched/cls_u32.c, u32_classify() grabs a reference to part of the
network header.  This is question number one: how can the filter look at
the ethernet (mac) header if it's grabbing a reference to the network
header:

	u8 *ptr = skb_network_header(skb);

I would think that for a protocol of 802.3, one would want:

	u8 *ptr = skb_mac_header(skb);

Changing this though doesn't fix the filter.  Further down is a rather
horrible match criteria to make sure the filter is looking at the right
data before it applies the whole filter list on the skb:

	if
((*(u32*)(ptr+key->off+(off2&key->offmask))^key->val)&key->mask) {

Now if this matches (meaning it evaluates to zero), we can move on.  If
not, we go to the next key node and try again.  Run out of key nodes, we
return -1 and take the default mapping from IP TOS to Linux priority,
and get queued to a band.

My big question is: Has anyone recently used the 802_3 protocol in tc
with u32 and actually gotten it to work?  I can't see how the
u32_classify() code can look at the mac header, since it is using the
network header accessor to start looking.  I think this is an issue with
the classification code, but I'm looking to see if I'm doing something
stupid before I really start digging into this mess.

Thanks in advance,

PJ Waskiewicz
Intel Corporation
peter.p.waskiewicz.jr@intel.com <mailto:peter.p.waskiewicz.jr@intel.com>

Re: Potential u32 classifier bug.

[Thomas Graf]

* Waskiewicz Jr, Peter P <peter.p.waskiewicz.jr@intel.com> 2007-08-09 18:07
> My big question is: Has anyone recently used the 802_3 protocol in tc
> with u32 and actually gotten it to work?  I can't see how the
> u32_classify() code can look at the mac header, since it is using the
> network header accessor to start looking.  I think this is an issue with
> the classification code, but I'm looking to see if I'm doing something
> stupid before I really start digging into this mess.

There is this very horrible way of using the u32 classifier with a
negative offset to look into the ethernet header.

You might want to look into the cmp ematch which can be attached to
almost any classifier. It allows basing offsets on any layer thus
making ethernet header filtering trivial.

RE: Potential u32 classifier bug.

[Waskiewicz Jr, Peter P]

> * Waskiewicz Jr, Peter P <peter.p.waskiewicz.jr@intel.com> 
> 2007-08-09 18:07
> > My big question is: Has anyone recently used the 802_3 
> protocol in tc 
> > with u32 and actually gotten it to work?  I can't see how the
> > u32_classify() code can look at the mac header, since it is 
> using the 
> > network header accessor to start looking.  I think this is an issue 
> > with the classification code, but I'm looking to see if I'm doing 
> > something stupid before I really start digging into this mess.
> 
> There is this very horrible way of using the u32 classifier 
> with a negative offset to look into the ethernet header.

Based on this, it sounds like u32 using protocol 802_3 is broken?

> You might want to look into the cmp ematch which can be 
> attached to almost any classifier. It allows basing offsets 
> on any layer thus making ethernet header filtering trivial.

I'll look at this.  Thanks Thomas for the response!

-PJ

Re: Potential u32 classifier bug.

[Thomas Graf]

* Waskiewicz Jr, Peter P <peter.p.waskiewicz.jr@intel.com> 2007-08-15 11:02
> > There is this very horrible way of using the u32 classifier 
> > with a negative offset to look into the ethernet header.
> 
> Based on this, it sounds like u32 using protocol 802_3 is broken?

You might be expecting too much from u32. The protocol given
to u32 is just a filter, it doesn't imply anything beyond that.
u32 has its usage the way it is, that's way we've added an ematch
rather than extending u32 itself.

RE: Potential u32 classifier bug.

[Waskiewicz Jr, Peter P]

> * Waskiewicz Jr, Peter P <peter.p.waskiewicz.jr@intel.com> 
> 2007-08-15 11:02
> > > There is this very horrible way of using the u32 
> classifier with a 
> > > negative offset to look into the ethernet header.
> > 
> > Based on this, it sounds like u32 using protocol 802_3 is broken?
> 
> You might be expecting too much from u32. The protocol given 
> to u32 is just a filter, it doesn't imply anything beyond that.
> u32 has its usage the way it is, that's way we've added an 
> ematch rather than extending u32 itself.

Ok, that clarifies it a bit.  I've just found a few examples on the net,
one of which is in a TC filter manual
(http://tcn.hypert.net/tcmanual.pdf, section 2.2.1.3 at the bottom of
the section), that was using u32 to simply filter on dest MAC address
without anything elaborate.  Either it worked way back when, or it was a
bogus example.

Thanks again Thomas,

-PJ