More details on why received UDP packets are treated as errors?
Subsystems (2)
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 11 lines · Ben Greear
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+.
Quoted 7 lines
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?
You could try dropwatch for this kind of obscure drops
Quoted 17 lines · Eric Dumazet
Quoted 16 lines · Ben Greear
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.
Quoted 6 lines
Quoted 2 lines
Is there any way to get more details about what these 'packet receive errors' are caused by using normal-ish tools?
You could try dropwatch for this kind of obscure drops
If the drop happens in __udp_queue_rcv_skb() you can also get some info from the udp_fail_queue_rcv_skb tracepoint. See "296f7ea udp: add tracepoints for queueing skb to rcvbuf (v3.1-rc1)".
Quoted 17 lines · Eric Dumazet
Quoted 16 lines · Ben Greear
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.
Quoted 6 lines
Quoted 2 lines
Is there any way to get more details about what these 'packet receive errors' are caused by using normal-ish tools?
You could try dropwatch for this kind of obscure drops
I had a chance to crank this up today.
dropwatch is pretty sweet...turns out it's dropping due to bad UDP checksums, due to the VETH bug/issue where it claims to calculate HW checksum but appearantly does not actually do so (see previous email in another thread).
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com