From: Matthias Treydte <mt@waldheinz.de>
To: Paolo Abeni <pabeni@redhat.com>
Cc: stable@vger.kernel.org, netdev@vger.kernel.org,
regressions@lists.linux.dev, davem@davemloft.net,
yoshfuji@linux-ipv6.org, dsahern@kernel.org,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
David Ahern <dsahern@gmail.com>
Subject: Re: [regression] UDP recv data corruption
Date: Fri, 02 Jul 2021 16:31:48 +0200 [thread overview]
Message-ID: <20210702163148.Horde.OPbmfqdhfEMDjt3Q2A7ru7c@mail.your-server.de> (raw)
In-Reply-To: <39df657bee89e56c704782e0c061383d276d2f7c.camel@redhat.com>
Quoting Paolo Abeni <pabeni@redhat.com>:
Finally got your mail, seems it was delayed, sorry.
> - check, if possibly, how exactly the pkts are corrupted. Wrong size?
> bad csum? what else?
>
> - ideally a short pcap trace comprising the problematic packets would
> be great!
While trying to produce something I came up with an interesting
observation which seems to indicate that the problem lies in the
combination of GRO and fragmented UDP packets:
Tuning the sending side (for my testing purposes also FFMpeg) to send
UDP packets of 1316 bytes tops makes the problem go away in the
receiver. The value must be an exact multiple of 188 (the MPEG TS
frame size) to cause FFMpeg not to send fragmented packets at all.
Using this we were able to do the following on our normal desktop machines:
The sending side uses an command like this:
ffmpeg \
-stream_loop -1 \
-re -i "$video" \
-c:v copy -c:a copy \
-f mpegts "udp://239.12.23.0:1935"
and the receiver (in our case using Linux 5.12.14) "mpv
udp://239.12.23.0:1935" to see the stream. For our test $video was
just some h264 encoded MKV I had laying around. The receiver sees
compression artifacts and the "Packet corrupt" messages in the
console. Now there are two ways to improve this situation:
1) The receiver uses ethtool to disable GRO
2) The sender changes the URL to be "udp://239.12.23.0:1935?pkt_size=1316"
At this point I assume there are better ways to reproduce this using
netcat or the like. But being a video guy, well, here we are. ;-)
My knowledge about the inner workings of Linux' IP stack are lacking,
but because tcpdump "sees" packets before they are reassembled and the
problem seems to exist only with packets that were fragmented and
reassembled (as they are presented to libav), I have the feeling that
a pcap file would not be that helpful with this, right?
Regards,
-Matthias
next prev parent reply other threads:[~2021-07-02 14:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-01 10:47 [regression] UDP recv data corruption Matthias Treydte
2021-07-01 15:39 ` David Ahern
2021-07-02 0:31 ` Willem de Bruijn
2021-07-02 11:42 ` Paolo Abeni
2021-07-02 14:31 ` Matthias Treydte [this message]
2021-07-02 12:36 ` Matthias Treydte
2021-07-02 14:06 ` Paolo Abeni
2021-07-02 14:21 ` Paolo Abeni
2021-07-02 15:23 ` Matthias Treydte
2021-07-02 15:32 ` Paolo Abeni
2021-07-02 16:07 ` Matthias Treydte
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=20210702163148.Horde.OPbmfqdhfEMDjt3Q2A7ru7c@mail.your-server.de \
--to=mt@waldheinz.de \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=dsahern@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=regressions@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
--cc=yoshfuji@linux-ipv6.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).