Bug 2162 - UDP Multicast Does not receive packets
Summary: UDP Multicast Does not receive packets
Status: RESOLVED NORESPONSE
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 1.9.2
Hardware: All All
: Highest normal
Target Milestone: 4.8 (async)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-11-22 16:00 UTC by Shawn Lewis
Modified: 2013-06-28 14:09 UTC (History)
6 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Multicast failure (350.41 KB, application/octet-stream)
2011-12-21 10:31 UTC, Shawn Lewis
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NORESPONSE

Description Shawn Lewis 2011-11-22 16:00:54 UTC
Creating a UDP Socket, joinging a multicast group works with no errors.

Doing a receive on the same socket yields 0 packets.  All the code needed to reproduce is below:

It is required to OPEN UP MULTICAST packets to the device, as by default Multicast packets are ignored by Android.


        var multiLock = ((Android.Net.Wifi.WifiManager)this.GetSystemService(Context.WifiService)).CreateMulticastLock("noknokPublisher");

        if (!multiLock.IsHeld)
             multiLock.SetReferenceCounted(true);
	     multiLock.Acquire();

Then establish the socket: (This is the UPNP Multicast, so lots of traffic here)
239.255.255.250 port 1900

_LocalIP = System.Net.IPAddress.Parse("192.168.2.10");
_LocalEndpoint =new System.Net.IPEndPoint(System.Net.IPAddress.Any,1900);

mCastSocketRX = new System.Net.Sockets.Socket(System.Net.Sockets.AddressFamily.InterNetwork, System.Net.Sockets.SocketType.Dgram, System.Net.Sockets.ProtocolType.Udp);
mCastSocketRX.EnableBroadcast = true;
mCastSocketRX.ExclusiveAddressUse = false;
mCastSocketRX.MulticastLoopback = _LoopbackSend;
mCastSocketRX.Blocking = blocking;
mCastSocketRX.SetSocketOption(System.Net.Sockets.SocketOptionLevel.Socket, System.Net.Sockets.SocketOptionName.ReuseAddress, true);
mCastSocketRX.UseOnlyOverlappedIO=false;
mCastSocketRX.ReceiveBufferSize=64000;
mCastSocketRX.Ttl = 128;
mCastSocketRX.SetSocketOption(System.Net.Sockets.SocketOptionLevel.IP, System.Net.Sockets.SocketOptionName.AddMembership, new System.Net.Sockets.MulticastOption(mCastAddress.Address, _LocalIP));
mCastSocketRX.Bind(_LocalEndpoint);


byte[] myBuffer = new byte[1023];
EndPoint ep = new IPEndPoint(IPAddress.Any,0);
int nBytes = mCastSocketRX.ReceiveFrom(myBuffer,SocketFlags.None,ref ep);


It will wait here forever, no matter how many UDP Multicast Packets on that group are sent.

Further, I have watched the debug output (DALVIK) when the ACQUIRE is done, no errors, both phone and tablet process fine. Additionally I have other apps (native) which are on the devices, which accept the same packets no problem.
Comment 1 Shawn Lewis 2011-12-14 23:43:34 UTC
Anyone look at this yet? This is a pretty big show stopper... :(
Comment 2 Shawn Lewis 2011-12-21 10:30:07 UTC
Attached now is a full MonoDroid application, which demonstrates the problem.

It is set to LISTEN on the DLNA/UPNP mulitcast address of 239.255.255.250:1900

If you have anything like a wireless router, a Windows PC, a NAS drive, it will be broadcasting on that multicast.

You can also confirm network packets by using wireshark, and just filter for for UDP Port 1900.
Comment 3 Shawn Lewis 2011-12-21 10:31:26 UTC
Created attachment 1073 [details]
Multicast failure

MonoDroid Application to demonstrate MD failure to receive packets.

Android has its OWN multicast socket class, which differs from the normal socket class, so Im not sure if you need to implement that.
Comment 4 Eric Maupin 2011-12-21 11:09:09 UTC
Shawn,

I just tried your test case. You have _Running perpetually set to false. When I change this to true, your test case works as intended (I see packet messages).
Comment 5 Shawn Lewis 2011-12-21 11:11:06 UTC
Will also mention this is when running on a physical device (not emulator)

(And changed _Running = true)

Which is important in how the LOCK works for multicast.

Tested devices:

Android S
Acer A500
HTC EVO 4G
Comment 6 Eric Maupin 2011-12-21 11:13:16 UTC
Shawn,

I tried this on a Sony Tablet S. I'll try to test this on one of those devices.
Comment 7 Shawn Lewis 2011-12-21 11:18:01 UTC
Also a:

Samsung Galaxy S

3 phones, 1 tablet
Comment 8 Shawn Lewis 2011-12-27 14:17:02 UTC
Any chance you have tested on another device?
Comment 9 Miguel de Icaza [MSFT] 2012-02-13 10:47:59 UTC
I wonder if this is related to the Android permission:

CHANGE_WIFI_MULTICAST_STATE

http://developer.android.com/reference/android/Manifest.permission.html
Comment 10 Shawn Lewis 2012-02-13 11:17:43 UTC
We have this in our app, as required, and still have the issue
Comment 11 Jonathan Pryor 2012-02-22 17:03:18 UTC
I'm now confused. What's the bug?

If I take Attachment 1073 [details] (from Comment 3) and changed as per Comment 5 and Comment 9, it works on my N1 and my Xoom. It is most certainly not hanging at mCastSocketRX.ReceiveFrom() for me. :-(

It does fail on the emulator. Further tracing shows that the reason why it fails on the emulator is that Get_IP_List() "fails" on the emulator, returning "0.0.0.0" instead of a sane/real IP address. Investigation by others suggests that multicasting on the emulator is "known-broken."

What I've also found helpful for diagnostic purposes is an explicit "broadcast" command which writes a broadcast on port 1900:

	using System;
	using System.Net;
	using System.Net.Sockets;
	using System.Text;

	class Test {
		const int Port = 1900;
		public static void Main (string[] args)
		{
			Console.WriteLine("Sending message...");
			var pingUDP = new UdpClient (Port);
			var pingGroup = new IPEndPoint (IPAddress.Parse ("255.255.255.255"), Port);
			foreach (string s in args) {
				byte[] data = Encoding.ASCII.GetBytes(s);
				pingUDP.Send(data, data.Length, pingGroup);
			}
			pingUDP.Close ();
			Console.WriteLine("Message sent");
		}
	}

Running this command allows me to test that the handler is being invoked.
Comment 13 PJ 2013-06-28 14:09:12 UTC
There has been no response to this NEEDINFO for over a year. RESOLVING as NORESPONSE.

Shawn, please feel free to REOPEN or re-file if you are still seeing the issue.