All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Cong Wang <xiyou.wangcong@gmail.com>, netdev@vger.kernel.org
Cc: Martin Olsson <martin.olsson+netdev@sentorsecurity.com>,
	Jiri Pirko <jiri@resnulli.us>, Lucas Bates <lucasb@mojatatu.com>
Subject: Re: [Patch net] net_sched: refetch skb protocol for each filter
Date: Sat, 12 Jan 2019 10:41:24 -0500	[thread overview]
Message-ID: <2c84f3cc-b1ad-5316-4813-e7e433bf9f5e@mojatatu.com> (raw)
In-Reply-To: <b7c845f1-be54-79a2-694d-f9db78bcad69@mojatatu.com>

On 2019-01-12 7:23 a.m., Jamal Hadi Salim wrote:

> Do we have a test case for a setup like this in tdc?
> i.e incoming tagged and then vlan popped by action?
> Otherwise a test with IFE which resets the ethertype
> would be sufficient i.e just something that will messup
> with skb->protocol.

And here is a slightly complex test with IFE.
Wanted to show both reclassify and continue in play
as well as something that change skb->protocol.

I used VMs to test, but two hosts or two containers
with veth between them will do.
Martin, if you have the cycles please test this out.

TLDR: Suspect is the vlan part.

-----------
#Sender side egress setup. We are going to encode
#all outgoing pings(icmp) to carry an skbmark 17 on the wire
#and set the ethertype  to 0xDEAD
sudo $TC qdisc del dev $ETH root
sudo $TC qdisc add dev $ETH root handle 1: prio
sudo $TC filter add dev $ETH parent 1: protocol ip prio 10 u32 \
match ip protocol 1 0xff \
flowid 1:2 \
action skbedit mark 17 \
action ife encode type 0xDEAD allow mark

#receiver side ingress setup

sudo $TC qdisc del dev $ETH ingress
sudo $TC qdisc add dev $ETH ingress
#decapsulate based on skb proto and then
#reclassify
sudo $TC filter add dev $ETH parent ffff: prio 2 protocol 0xdead u32 \
match u32 0 0 flowid 1:1 action ife decode reclassify
#match icmp
sudo $TC filter add dev $ETH parent ffff: prio 4 protocol ip u32 \
match ip protocol 1 0xff flowid 1:1 action continue
#
#now classify based on mark 17 (hex 11).
#
sudo $TC filter add dev $ETH parent ffff: prio 5 protocol ip \
handle 0x11 fw flowid 1:1 \
action ok

On sender side, send 10 pings to receiver. Now lets see
the receiver stats:

---------------
root@jhs-foobar:# uname -a
Linux jhs-foobar 4.20.0-rc7+ #2 SMP Fri Jan 12 9:29:35 EST 2019 x86_64 
x86_64 x86_64 GNU/Linux

root@jhs-foobar:# $TC -s filter ls dev $ETH parent ffff:
filter protocol [57005] pref 2 u32
filter protocol [57005] pref 2 u32 fh 800: ht divisor 1
filter protocol [57005] pref 2 u32 fh 800::800 order 2048 key ht 800 bkt 
0 flowid 1:1  (rule hit 10 success 10)
   match 00000000/00000000 at 0 (success 10 )
	action order 1: ife decode action reclassify type 0x0
	 allow mark allow prio
	 index 1 ref 1 bind 1 installed 40 sec used 19 sec
	Action statistics:
	Sent 1080 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
	backlog 0b 0p requeues 0

filter protocol ip pref 4 u32
filter protocol ip pref 4 u32 fh 801: ht divisor 1
filter protocol ip pref 4 u32 fh 801::800 order 2048 key ht 801 bkt 0 
flowid 1:1  (rule hit 33 success 10)
   match 00010000/00ff0000 at 8 (success 10 )
	action order 1: gact action continue
	 random type none pass val 0
	 index 1 ref 1 bind 1 installed 40 sec used 19 sec
  	Action statistics:
	Sent 1080 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
	backlog 0b 0p requeues 0

filter protocol ip pref 5 fw
filter protocol ip pref 5 fw handle 0x11 classid 1:1

	action order 1: gact action pass
	 random type none pass val 0
	 index 2 ref 1 bind 1 installed 39 sec used 19 sec
  	Action statistics:
	Sent 1080 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
	backlog 0b 0p requeues 0
---------------


As can be observed all the rules are hit as expected.

cheers,
jamal

  reply	other threads:[~2019-01-12 15:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-12  2:55 [Patch net] net_sched: refetch skb protocol for each filter Cong Wang
2019-01-12 12:23 ` Jamal Hadi Salim
2019-01-12 15:41   ` Jamal Hadi Salim [this message]
2019-01-13 21:08     ` Cong Wang
2019-01-15 15:59       ` Jamal Hadi Salim
2019-01-15 16:21         ` Jamal Hadi Salim
2019-01-15 17:57           ` Cong Wang
2019-01-16 14:02             ` Jamal Hadi Salim
2019-01-15 17:52         ` Cong Wang
2019-01-13 20:58   ` Cong Wang
2019-01-15 15:14     ` Jamal Hadi Salim
2019-01-14  9:15   ` Martin Olsson
2019-01-15 15:19     ` Jamal Hadi Salim
2019-01-14 23:13   ` Lucas Bates
2019-01-14  9:23 ` Daniel Borkmann
2019-01-14 19:55   ` Cong Wang
2019-01-16 13:59 ` Jamal Hadi Salim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c84f3cc-b1ad-5316-4813-e7e433bf9f5e@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=lucasb@mojatatu.com \
    --cc=martin.olsson+netdev@sentorsecurity.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.