From: Ben Greear <greearb@candelatech.com>
To: netdev <netdev@vger.kernel.org>
Subject: More details on why received UDP packets are treated as errors?
Date: Mon, 29 Jul 2013 11:21:31 -0700 [thread overview]
Message-ID: <51F6B2AB.5050607@candelatech.com> (raw)
We have a test case on 3.9.9+ (local patches applied) where sending from
VETH interface, through peer VETH bridged (with our own emulator bridge module)
to physical interface, which is then looped to another physical interface (B).
The VETH and the wired B interface are sending UDP traffic to each other.
Routing rules should be configured such that this all works appropriately.
Replacing our bridging module with a user-space bridge has same behaviour.
This setup works on the 3.7.y kernel, but we only get one-way traffic
(B to VETH) on 3.9.9+.
I sniffed the B port, and traffic appears to be sent and received
properly (ie, no checksum errors, etc). But, our user-space app
shows no received UDP frames on B, and netstat -s gives the
output below.
Is there any way to get more details about what these 'packet receive errors'
are caused by using normal-ish tools?
Udp:
6827 packets received
0 packets to unknown port received.
6172 packet receive errors
12964 packets sent
0 receive buffer errors
0 send buffer errors
Tcp connections also fail to work, and I see these TCP stats. I'm sure
not all of this is related to the problem at hand, but likely some of it
is.
Tcp:
81 active connections openings
11 passive connection openings
66 failed connection attempts
0 connection resets received
17 connections established
204643 segments received
229686 segments send out
465 segments retransmited
322 bad segments received.
70 resets sent
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next reply other threads:[~2013-07-29 18:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-29 18:21 Ben Greear [this message]
2013-07-29 20:21 ` More details on why received UDP packets are treated as errors? Eric Dumazet
2013-07-30 20:38 ` Benjamin Poirier
2013-08-08 0:10 ` Ben Greear
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=51F6B2AB.5050607@candelatech.com \
--to=greearb@candelatech.com \
--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).