netdev - Re: [PATCH net] ip_tunnel: allow to inherit from VLAN encapsulated IP frames

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, 20 Jul 2022 09:50:02 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Matthias May <matthias.may@...termo.com>
Cc:     <netdev@...r.kernel.org>, <davem@...emloft.net>,
        <yoshfuji@...ux-ipv6.org>, <dsahern@...nel.org>,
        <edumazet@...gle.com>, <pabeni@...hat.com>,
        <nicolas.dichtel@...nd.com>, Eyal Birger <eyal.birger@...il.com>
Subject: Re: [PATCH net] ip_tunnel: allow to inherit from VLAN encapsulated
 IP frames

On Wed, 20 Jul 2022 17:24:17 +0200 Matthias May wrote:
> I finally got around to do the previously mentioned selftest for gretap, vxlan and geneve.
> See the bash-script below.
>
> Many of the vxlan/geneve tests are currently failing, with gretap working on net-next
> because of the fixes i sent.
> What is the policy on sending selftests that are failing?
> Are fixes for the failures required in advance?
> 
> I'm not sure i can fix them.
> Geneve seems to ignore the 3 upper bits of the DSCP completely.
> 
> My other concern is:
> The whole test is... slow.
> I tried to figure out what takes so long, and the culprit seem to be tcpdump.
> It just takes ages to start capturing, more so when it is capturing IPv6.
> Does anyone know of a better way to capture traffic and analyze it afterwards?
> I used tcpdump because other tests seem to use it, and i guess this is a tool
> that most everyone has installed (that works with networks).

Yeah, tcpdump is not great, there's a bunch of flags that make it a
little less bad (--immediate-mode?) 

Looking at the last test I wrote I ended up with:

tcpdump --immediate-mode -p -ni dummy0 -w $TMPF -c 4
sleep 0.05 # wait for tcpdump to start