From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Subject: Fw: [Bug 196469] New: UDPv4+UDPv6 receive silently fails after heavy UDP load
Date: Tue, 25 Jul 2017 11:40:25 -0700 [thread overview]
Message-ID: <20170725114025.14ab6616@xeon-e3> (raw)
Begin forwarded message:
Date: Mon, 24 Jul 2017 20:52:01 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 196469] New: UDPv4+UDPv6 receive silently fails after heavy UDP load
https://bugzilla.kernel.org/show_bug.cgi?id=196469
Bug ID: 196469
Summary: UDPv4+UDPv6 receive silently fails after heavy UDP
load
Product: Networking
Version: 2.5
Kernel Version: 4.12.2
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: CFSworks@gmail.com
Regression: No
I have a system that's performing heavy SNMP monitoring on various devices over
IPv6. After upgrading it from 4.11.5 to 4.12.2 last week, I noticed this
weekend that all UDP packets received by the system were being silently
dropped.
The problem happened this weekend, after the system had been running for about
2 days with no issue, and without any human intervention at the time (i.e. it
broke on its own - no configuration changes were made). I verified UDP replies
were coming in via tcpdump, and checked netfilter and conntrack to make sure
nothing was blocking it (indeed netfilter/conntrack is able to see the traffic,
indicating the problem is deeper in the network stack). There is no relevant or
even unusual output whatsoever in dmesg.
This affects ALL received UDPv4/UDPv6 packets, even traffic on a loopback
interface: opening a pair of Python sessions and trying to send UDP traffic
back and forth on 127.0.0.1 results in the traffic getting dropped as well.
ICMP and TCP are unaffected.
My gut says it's a race condition somewhere in the UDP receive queue(s). What
puzzles me is why heavy UDPv6 load caused the kernel to shut out all UDPv4
traffic too.
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2017-07-25 18:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20170725114025.14ab6616@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=netdev@vger.kernel.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).