Can't receive Multicast UDP on WinRT tablets over a wireless network connection RRS feed

  • Question

  • Changed the title to be Multicast UDP (not USB).

    I am trying to implement a MDNS library to discover networked devices and am having a problem.  My library works well from Intel products over both wired and wireless networks and it works from an ARM device (one of the original NVidia tablets) over a wired network connection.  It does not detect any of the multicast traffic over a wireless network from an ARM tablet (both an NVidia and a Surface).

    My code looks like the following:

    private async void InitializeSocket()
            _socket = new DatagramSocket();
            _socket.MessageReceived += HandleMessageReceived;
            await _socket.BindServiceNameAsync("5353");
            _multicastGroupJoined = true;
            _multicastJoinTask = null;
        catch (Exception e)
            Debug.WriteLine("MDNSIOChannel.InitializeSocket: Exception: ", e.Message);
    private void HandleMessageReceived(DatagramSocket aSocket,
                                       DatagramSocketMessageReceivedEventArgs anArgs)
        if (_disposed || (null == MessageReceived) || (null == anArgs.RemoteAddress))
            MessageReceived(this, new DatagramEventArgs(anArgs));
        catch (Exception e)
            Debug.WriteLine("MDNSIOChannel.HandleMessageReceived: Exception: " + e.Message);

    As I say, this works everywhere except for a wireless connection on an ARM-based tablet.  

    Any Suggestions?

    • Moved by Aaron Xue Friday, November 2, 2012 8:42 AM (From:Building Windows Store apps with C# or VB )
    • Edited by LarryBoi Monday, November 26, 2012 5:22 PM
    Wednesday, October 31, 2012 4:40 PM

All replies

  • I am having the exact same problem.  Multicast UDP sends packets fine to the multicast group on ARM (Surface), however, it does not receive any packets from the multicast group.  Whereas this works absolutely fine on x86 and x64.  Other private network access works absolutely fine.

    Using similar code to the fragment above, so are we doing something wrong?

    Larry: subject should be Multicast UDP not Multicast USB!

    Friday, November 23, 2012 5:45 PM
  • This issue seems to be related to the network state.  I have seen it work on The Microsoft Surface tablet and the ASUS tablet for a while.  When I try it later it doesn't work.  No changes except for other testing going on (these are shared devices).
    Monday, November 26, 2012 5:24 PM
  • I am seeing exact the same problem on Windows Surface tablets. For multicast UDP, it can send data, but never receives data from other devices. Multicast UDP is working fine on Windows 8 Laptop and Snapdragon ARM tablets. I guess it has something related to the firewall configuration.  Unfortunately we have no way to configure the firewall setting.
    Thursday, December 13, 2012 12:20 AM
  • Please comment on this issue. Thanks.

    Friday, December 14, 2012 1:35 AM
  • There have been times with the Surface tablet where I could get incoming datagrams over a wireless connection.  However, that was always a very temporary situation.  Given that, I have concluded that it really isn't a firewall issue - I would expect that to consistently fail.  I think that there is something about the network stack (drivers and NIC) that is blocking the traffic but that is my guess at this point.  I don't have the evidence to point at anything.  The one time that I remember that is worked was immediately after there was a an update for the tablet OS.  At that point, it worked for a few hours and then stopped working.  I don't remember the date for sure but it was in early November.

    Friday, December 14, 2012 5:06 PM
  • Latest windows update does not solve the problem. Temporariliy I use Broadcast to replace multicast. It really surprises me that the issue does not get any attention from MSFT after two months. It should be just a small bug in the networking stack.
    Friday, January 4, 2013 1:33 AM
  • Even IPv4 broadcast doesn't work for me :-(

    I've posted a similar problem (UDP communication between Intel and ARM devices) and after updating the attached VS2012 solution to support IPv4 broadcast I've confirmed that it doesn't work either (at least in my environment, that is).

    Palo Mraz

    • Edited by Palo Mraz Friday, January 4, 2013 10:01 AM corrected small typo
    Friday, January 4, 2013 10:01 AM
  • Is your intel device connected to both wifi and ethernet? If so, disconnect ethernet and try again.

    There is another thread that discusses the broadcast http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/75dfa774-54a0-43a4-b489-ddc753d00ca4

    Of course, many other factors may affect broadcast.

    Friday, January 4, 2013 6:09 PM
  • In my testing, both devices were connected through WiFi only...

    Palo Mraz

    Sunday, January 6, 2013 4:07 PM
  • have you tried to write to it with a DataWriter after you do the JoinMulticastGroup?


    Thursday, January 17, 2013 3:09 AM
  • Hello James, thank you for your suggestion. I've modified the code to send a message to the socket right after the JoinMulticastGroup call:

    receiverSocket.JoinMulticastGroup(new HostName(this._multicastGroupAddress));
    var stream = await receiverSocket.GetOutputStreamAsync(new HostName(this._multicastGroupAddress), this._port);
    var bytes = new byte[100 + random.Next(1000)];
    uint bytesSent = await stream.WriteAsync(bytes.AsBuffer());
    await stream.FlushAsync();

    Unfortunately, this didn't change the behavior - the RT device still doesn't receive any UDP packets...

    Palo Mraz

    Thursday, January 17, 2013 8:11 PM
  • Actually it would be like this:

    using (var writer = new DataWriter(await receiverSoccekt.GetOutputStreamAsync(address, port)))
                        await writer.StoreAsync();
                        await writer.FlushAsync();

    I struggled with this for a while, but eventually got it.


    Thursday, January 17, 2013 11:24 PM
  • Please do not confuse the people here. Although obviously you code makes no difference, I still gave it a try. With that code multicast do not work between two surface tablets.

    Do not make your claim unless you are sure about it, otherwise it will waste people's time to try it out.

    Friday, January 18, 2013 10:21 PM
  • The difference between Palo's code is mine is that I do

                        await writer.StoreAsync();

    compared to just a write async. 

    I do this inside of my app to communicate and return settings. I also do this to implement wake on lan capabilities via UDP broadcast.

    I wouldn't post something unless I was trying to help, as I spent a lot of time on this and it took me multiple different attempts and days to get it working properly. I copied this code straight out of my app.


    Saturday, January 19, 2013 5:18 AM
  • The problem with multicasting seems to be in the Broadcom Wi-Fi drivers - FMI see the answer in the following post:

    UDP communication between Intel and ARM devices

    @James: Renjie is not saying that your DataWriter code is wrong - it is not. But, it doesn't fix the problem discussed in this thread. It doesn't matter if you send the UDP datagram writing directly to the output stream, or wrap the stream using DataWriter - until Broadcom fixes the Wi-Fi stack, it won't work.

    Wednesday, January 23, 2013 7:20 AM
  • Hello,

    The issue of not being able to receive UDP Multicast packets is currently being investigated on the Acer Windows RT and Surface Windows RT device.

    The problem is with the hardware network device driver on both the devices and we are working with the vendors of the drivers for a fix. The Acer tablet uses Broadcom drivers, whereas the Surface uses Marvell drivers.

    We have contacted both the vendors and hope to have a resolution that will be pushed via Windows Update as soon as possible (I have no dates for you unfortunately).



    Wednesday, February 6, 2013 8:46 PM
  • Problems aside, WinRT mDSN library is something I'm interested in... Ready to collaborate - let me know if you're still working on it or have anything to share.
    Tuesday, February 12, 2013 1:02 AM
  • I have the same issue here. My metro app does't receive any UDP multicast using DatagramSocket.  Is there a solution to fix this problem yet?

    Saturday, June 22, 2013 9:14 AM
  • Yes, the problem was found to be in the network drivers for both the Surface and Asus tablets.  I don't know if any other tablets were using the same network chips and drivers or not.  Anyway, there was an update to the Surface driver in the April patch that fixed the problem I was having (Marvell network adapter driver v
    Monday, June 24, 2013 3:01 PM
  • Hi,

    I'm facing the same problem.

    My Surface RT does not receive any UDP multicast packages with DatagramSockets. The latest Marvell Drivers ( are installed.

    Is this problem really fixed?



    Sunday, February 23, 2014 10:42 AM
  • Any news on this issue - has this been going on for nearly 2 years without workaround or a resolution?

    Sample project is here.

    Instructions for repro:

    1. install app on two or more devices with factory config.  One must be a Surface RT, with newest Marvell AVASTAR Wireless-N Network Controller (which is currently V 14.62.17215.91). 
    2. Make sure the devices are single-homed and on only one connected network. (Windows phones can have cellular on, but all Windows 8 devices should have only 1 active, enabled, joined network)
    3. Use wireshark or network monitor.  Note that all devices are sending UDP packets, including the RT.
    4. Note that the Surface RT does not ever receive packets the others send.

    I have a business app that needs this exact feature in the near future, but I actually happened upon this post instead trying to help a new user in the forums.   I thought I'd whip up a quick sample for them, and then spent three hours trying to figure out why my RT wasn't working properly.

    Any suggestions as to the best way to get this fixed?

    Darin R.

    Sunday, October 19, 2014 8:28 PM
  • Hi Darin,

    The previously reported issue with the Marvell Network adapter was confirmed to be resolved, so if you are still seeing issues with UDP Multicast not working with the Marvell Network adapter, then this might be a problem (regression?) with the Marvell Driver.

    I am checking into this problem right now and will keep you updated.



    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Friday, October 24, 2014 7:10 PM
  • Can you tell which version had the fix?  I'm using Marvell AVASTAR Wireless-N Network Controller (SDIO) Ver 14.62.17215.91 on my RT which exhibits the problem.

    The Marvell AVASTART 350-N on my Surface pro 2, ver 14.69.24054.176 seems to work.

    I've also tried to update the driver via windows update on the RT, and it says it has the latest.  I can't find the AVASTAR download for RT on the Marvell site, so I can't see which is newest.

    Darin R.

    Friday, October 24, 2014 7:19 PM
  • It looks like the latest version is 14.62.17215.91 - which had resolved the previously reported issue (see the response from LarryBoi in June 2013). The April 2013 Windows Update cycle had updated the driver version to XXX.91 and had fixed the old issue.

    I am currently investigating into this further, but it may take a while though to understand what is going on...

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Friday, October 24, 2014 7:31 PM
  • I'm experiencing the same problem on a Windows Phone 8.1 device (Lumia 635).


    It doesn't receive UDP multicast packet unless it is connected with USB cable.

    I thought it was some kind of Windows Phone 8.1 policy to save battery that disabled the reception of ONLY UDP Multicast data when battery is low.

    Please can we have a statement about this thing from a Microsoft Employee in order to make the situation and the causes more clear.

    Thanks in advance for the help.

    Wednesday, October 29, 2014 1:25 PM
  • @G.Developer...the problem reported in this thread is that the Surface RT (and the Acer Windows RT) is not receiving UDP multicast packets.

    On the Phone this could be a different problem or scenario that you are running into and possibly a different cause. Have you tried running your scenario on a different Phone (same model or a different model). That should be able to isolate whether the single device is faulty (if the other 635 works fine) or whether it is a problem with the generic Nokia Lumia 635 (all 635's fail, meaning it could be a driver specific problem for the 635) or if all Windows Phones have this problem (you can reproduce the same problem on another Phone, which then can mean that the problem is with the API).

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Wednesday, October 29, 2014 7:27 PM
  • Ok, thanks for the answer, I will try my app on a different phone as soon as possible.

    However I would like to know from you if it does exist (or doesn't) some kind of policy on Windows Phone 8.1 which makes the WIFI network interface discard some packets if the phone battery is running low?

    Thanks for the help.

    Thursday, October 30, 2014 11:13 AM
  • Hi Darin (and others),

    I was able to successfully run the app that was provided by Darin in the sample project here: https://onedrive.live.com/redir?resid=57E87AB396BA138!65095&authkey=!AGgaAxl5BiPXNVs&ithint=file%2czip on a Surface RT Generation 1.

    See screenshot below. I am unable to reproduce the problem, so it looks like an environmental issue.

    I used a NETGEAR  Double 108 Mbps Wireless Router WGU624 to simulate the multicast network and used a Surface RT as the first system and a regular x64 Windows 8.1 system as the other system. Both systems are able to successfully send & receive packets.

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    • Proposed as answer by Darin Rousseau Friday, October 31, 2014 8:04 PM
    Friday, October 31, 2014 6:01 PM
  • I took the afternoon and dug deeper.  Using your success as a rule, I worked through and found the problem.

    I'd gone back to my setup to see if I could spot anything different.  The specs from sysinfo (at least at the top) are all similar if not exactly what you have.

    I then updated my router's firmware (Linksys E3200), and then used a different router, just in case.

    I thought I was at a complete loss, after that and re-built the app to use a UDP port in the 3000s, and even removed the multicast join.  Still nothing.  I then popped the WP version on the phone to try and rule out one of the Surfaces, and the phone and RT were now communicating!  Pro?  Receiving but not sending.

    I reset the port to ensure that wasn't a cause, and then put the multicast join back in.  The RT and phone were still talking.

    I tracked it down to three things that conspired to make it tough to solve:

    1. While testing initially on my first post here, the firewall for the RT was misconfigured.  I found that later during some other UPNP project device testing.  Resetting it to factory worked for the UPNP on the RT, and I didn't test this project.  (The UPNP and most of the UDP stuff was set to OFF for domain and private networks, and ON for public, opposite to what you'd expect.)
    2. When I got the phone and RT working, but not the Pro, I used network monitor to find that the broadcasts for the pro were being sent on the HyperV virtual network for the Windows Phone Emulators instead of the Wifi... probably a result from the WiFi router update and all the WiFi hopping and interface auto-metrics.
    3. These posts.  I admit that a search to see how others fixed the issue landed on mostly "UDP RT doesn't work".

    Thanks again Prashant for your help; I can confirm that the driver and UDP multicast does work on the RT.

    Darin R.

    Friday, October 31, 2014 8:03 PM
  • Awesome, thanks for providing the details Darin! I am glad to hear that you have a working scenario now!

    Btw, although you can't run Network Monitor on Windows RT systems, you can collect network traces using netsh. I've written a blog about tracing network activity on Windows RT here: http://blogs.msdn.com/b/wsdevsol/archive/2013/10/10/tracing-network-activity-on-windows-rt.aspx

    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Friday, October 31, 2014 8:39 PM
  • Ok, I took some time to perform more tests with the exact same Winphone application using different Access Point/WLAN routers.

    I used 3 different models and the results were:

    Using an Intellinet AP  the app didn't receive any multicast at all.

    Using a TPLINK router TD-W8970 the app lost some multicast packets (it seemed like 1 every 2).

    Using a TPLINK router TL-MR3420 the app didn't lose ANY multicast packet.

    I'm beginning to think there's some kind of strange interaction between the telephone and the AP/router to which it is connected?

    Can someone confirm the possibility of such a behaviour?

    Thanks in advance for the help.

    Friday, November 7, 2014 5:11 PM
  • I wonder if the network packet is sent out to an AP if there is a lot of noise, or if the AP is busy.  Does the nature of UDP make it bad for wireless, or is the wireless client->AP UDP transmit guaranteed, and the router is the thing that drops it?

    I don't know if there's a complete list, but some things that could block UDP or multicast come to mind:

    • Multicast/Broadcast Storm control
    • Access point isolation
    • No multicast support on the router?  (do routers have to do this?)
    • client firewalls?  I know my RT's was messed up for this.

    You actually don't have to go very far to find people complaining about APs and their multicast support.  I just tried "Home Router Multicast route."  Blah.

    So much for multicast being a "put this in an app and it'll work with minimal support" solution.

    Darin R.

    Friday, November 7, 2014 7:22 PM