Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: UDP multicast crosstalk when listeners use the same port #3820

Closed
gopherbot opened this issue Jul 13, 2012 · 9 comments

Comments

Projects
None yet
3 participants
@gopherbot
Copy link

commented Jul 13, 2012

by andrew.w.deane:

I have done some testing and seen that a UDP multicast listener will receive data from
another group when there are multiple multicast listeners on the same box. Single
listeners receive message just for their group but once a second listener joins any
other group all listeners receive all groups messages.

The code used in the test is attached.

What steps will reproduce the problem?

I run 1 instance up:
go run ut.go -group 239.1.1.50 -port 10000

and then:
netcat -v -u 239.1.1.50 10000
50   

gives 50 on stdout.

If I then start another instance:
go run ut.go -group 239.1.1.51 -port 10000

and

netcat -v -u 239.1.1.51 10000
51   

both instances get 51 on their stdout.

Likewise if I then
netcat -v -u 239.1.1.50 10000
50   

both instance get 50 on their stdout.

netstat shows:

sudo netstat -napug
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
PID/Program name
udp        0      0 0.0.0.0:10000           0.0.0.0:*                          
3661/a.out      
udp        0      0 0.0.0.0:10000           0.0.0.0:*                          
3650/a.out      
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
eth0            1      239.1.1.51
eth0            1      239.1.1.50

What is the expected output?
Each listener reads their own group data.

What do you see instead?
Data on all groups.


Which compiler are you using (5g, 6g, 8g, gccgo)?


Which operating system are you using?
Linux 64 bit.

Ubuntu 12.04
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04 LTS"

3.2.0

and 

SLES 11
VERSION=11
PATCHLEVEL=1

2.6.32

Which version are you using?  (run 'go version')
go1.0.2

Please provide any additional information below.

Attachments:

  1. ut.go (554 bytes)
@mikioh

This comment has been minimized.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2012

Comment 4:

As mentioned in several places, listening to a group address, bind to a group
address doesn't make sense except for the app want to use bind as kinda traffic 
filters. We will provide IP-level packet identifying API as a part of IP-level socket 
options for IPv4 instead.
Does this make sense to you?
http://golang.org/cl/6482044/
@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 5:

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 6:

Labels changed: added go1.1maybe.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2012

Comment 7:

This issue was closed by revision golang/net@d2e5a12.

Status changed to Fixed.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2014

Comment 8:

Issue #8164 has been merged into this issue.

@gopherbot

This comment has been minimized.

Copy link
Author

commented Jul 2, 2014

Comment 9 by naquad:

This should be reopened. Seriously. go.net/ipv4 and ipv6 don't help here in any kind of
way. Function listenDatagram in net/sock_posix.go at line 161 explicitly throws away
provided multicast address. Filtering packets in the user space is terribly slower than
in kernel when you just bind the socket. At least provide a version of net.ListenUDP
that won't play smart and just do what it was told to.
@mikioh

This comment has been minimized.

Copy link
Contributor

commented Aug 1, 2014

Comment 10:

#9: please open new issue if you really want to have a multicast receiver (usually it
cannot send any packet because 5-tuple namespace handling implementations vary on
platforms; on some platform it's allowed though) PacketConn. fwiw, you can implement you
own multicast receiver PacketConn like the following:
s, err := syscall.Socket() 
lsa := syscall.SockaddrInet4{Port:..., Addr:...}
err = syscall.Bind(s, &lsa)
f := os.NewFile(uintptr(s), "")
c, err := net.FilePacketConn(f)
p := ipv4.NewPacketConn(c)
p.JoinGroup(...)

@gopherbot gopherbot added fixed labels Aug 1, 2014

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015

@rsc rsc removed the go1.1maybe label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.