netdev - Filter matching problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1349459175.18710.112.camel@denise.theartistscloset.com>
Date:	Fri, 05 Oct 2012 13:46:15 -0400
From:	"John A. Sullivan III" <jsullivan@...nsourcedevel.com>
To:	netdev@...r.kernel.org
Subject: Filter matching problems

Hello, all.  Can anyone tell me why this filter does not match anything
when I think it should match everything:

tc filter replace dev bond3 parent ffff: protocol ip prio 1 u32 match u8
0 0 action mirred egress redirect dev ifb0

I get:
tc -s filter show dev bond3 parent ffff:
filter protocol ip pref 1 u32
filter protocol ip pref 1 u32 fh 800: ht divisor 1
filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
(rule hit 1216169263 success 0)
  match 00000000/00000000 at 0 (success 1216169263 )
        action order 1: mirred (Egress Redirect to device ifb0) stolen
        index 2 ref 1 bind 1 installed 11362879 sec used 11362879 sec
        Action statistics:
        Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
        rate 0bit 0pps backlog 0b 0p requeues 0

which I think is telling me I'm not getting any matches.  Here are more
details.

We are redirecting ingress into ifb0 and redirecting egress into ifb1
(because several interfaces, e.g., OpenVPN tun devices) need the exact
same traffic shaping.  We realize that we cannot place the ingress
filter at ffff: and the egress filter at root as those appear to be
treated as one and the same, i.e., the first match of those two filters
will be used and the other will thus never see any packets.

To get around that problem, we inserted a priomap on the interface and
apply the egress redirect filter on it's child like this:

tc qdisc replace dev bond3 root handle 1: prio bands 2 priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc filter replace dev bond3 parent 1:0 protocol ip prio 1 u32 match u8 0 0 flowid 1:1 action mirred egress redirect dev ifb1
tc qdisc replace dev bond3 ingress
tc filter replace dev bond3 parent ffff: protocol ip prio 1 u32 match u8 0 0 action mirred egress redirect dev ifb0

So what have I mangled? Thanks - John

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html