Bug 437937

Summary: udp packet duplication in localhost with multicast sendto()
Product: Red Hat Enterprise Linux 4 Reporter: keisuke kuzukawa <kzzu>
Component: kernelAssignee: Neil Horman <nhorman>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: low    
Version: 4.0   
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-23 11:11:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description keisuke kuzukawa 2008-03-18 10:28:06 UTC 
Description of problem:
UDP Packet duplication occurs when sendto() called within many process
at the same time. each processes are joined to different multicast addr,port.
ratio of duplication is around 0.6%-2.0% of all sent packet per 1 addr.
(verified by tcpdump)


Version-Release number of selected component (if applicable):
uname -a
Linux xxxxxxx 2.6.9-5.EL #1 Wed Jan 5 19:21:57 EST 2005 x86_64 x86_64 x86_64
GNU/Linux

How reproducible:
As the number of the processes increases, the packet repetition rate rises.

Steps to Reproduce:
1.send multicast packet with sendto().
2.capture any multicast group with tcpdump
3.
  
Actual results:
when 20 process startup, each process sent 10000 udp packet.
captured 1 multicast addr with tcpdump, and received 10003packet. 
3 packets was the same one sent just before.

Expected results:


Additional info:
it never happen if sendto() called sequential.
Comment 1 Neil Horman 2008-05-12 18:29:36 UTC 
I'm going to set up a system to reproduce this.  In the interim, if you have a
copy of the tcpdump that you captured for me to review, that would be helpful. 
Thanks!
Comment 2 Neil Horman 2008-08-07 12:48:15 UTC 
ping, any word on that tcpdump?
Comment 3 Neil Horman 2009-03-23 11:11:20 UTC 
closing, no response