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
Closed

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

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

Comments

@gopherbot
Copy link

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
Copy link
Contributor

mikioh commented Sep 7, 2012

@mikioh
Copy link
Contributor

mikioh 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
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 5:

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

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 6:

Labels changed: added go1.1maybe.

@mikioh
Copy link
Contributor

mikioh commented Sep 26, 2012

Comment 7:

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

Status changed to Fixed.

@mikioh
Copy link
Contributor

mikioh commented Jun 7, 2014

Comment 8:

Issue #8164 has been merged into this issue.

@gopherbot
Copy link
Author

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
Copy link
Contributor

mikioh 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(...)

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants