netdev - Re: [PATCH net 13/17] selftests: forwarding: tc_tunnel

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-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 2 Aug 2023 11:37:40 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Davide Caratti <dcaratti@...hat.com>
Cc: Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org,
	davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
	edumazet@...gle.com, petrm@...dia.com, razor@...ckwall.org,
	mirsad.todorovac@....unizg.hr
Subject: Re: [PATCH net 13/17] selftests: forwarding: tc_tunnel_key: Make
 filters more specific

On Wed, Aug 02, 2023 at 10:30:52AM +0200, Davide Caratti wrote:
> On Wed, Aug 02, 2023 at 10:51:14AM +0300, Ido Schimmel wrote:
> > The test installs filters that match on various IP fragments (e.g., no
> > fragment, first fragment) and expects a certain amount of packets to hit
> > each filter. This is problematic as the filters are not specific enough
> > and can match IP packets (e.g., IGMP) generated by the stack, resulting
> > in failures [1].
> 
> [...]
> 
> > --- a/tools/testing/selftests/net/forwarding/tc_tunnel_key.sh
> > +++ b/tools/testing/selftests/net/forwarding/tc_tunnel_key.sh
> > @@ -104,11 +104,14 @@ tunnel_key_nofrag_test()
> >  	local i
> >  
> >  	tc filter add dev $swp1 ingress protocol ip pref 100 handle 100 \
> > -		flower ip_flags nofrag action drop
> > +		flower src_ip 192.0.2.1 dst_ip 192.0.2.2 ip_proto udp \
> > +		ip_flags nofrag action drop
> >  	tc filter add dev $swp1 ingress protocol ip pref 101 handle 101 \
> > -		flower ip_flags firstfrag action drop
> > +		flower src_ip 192.0.2.1 dst_ip 192.0.2.2 ip_proto udp \
> > +		ip_flags firstfrag action drop
> >  	tc filter add dev $swp1 ingress protocol ip pref 102 handle 102 \
> > -		flower ip_flags nofirstfrag action drop
> > +		flower src_ip 192.0.2.1 dst_ip 192.0.2.2 ip_proto udp \
> > +		ip_flags nofirstfrag action drop
> 
> 
> hello Ido, my 2 cents:
> 
> is it safe to match on the UDP protocol without changing the mausezahn
> command line? I see that it's generating generic IP packets at the
> moment (i.e. it does '-t ip'). Maybe it's more robust to change
> the test to generate ICMP and then match on the ICMP protocol?

My understanding of the test is that it's transmitting IP packets on the
VXLAN device and what $swp1 sees are the encapsulated packets (UDP).