DatagramSocket Multicast functionality on Windows 8.1 throws an error 0x80072AF9 (WSAHOST_NOT_FOUND)
We have noticed multiple customer reports of using the Multicast functionality of the Windows.Networking.Sockets.DatagramSocket class on Windows 8.1.
Most of the reported issues are with sending Multicast packets to the Multicast DNS address of 224.0.0.251 and port 5353, however the same could be true for any multicast address/port.
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. RFC 6762 covers the details of the protocol in further detail and can be found here: https://tools.ietf.org/html/rfc6762 for further reference.
A typical usage pattern of the code that demonstrates this issue is as below.
1. Create a DatagramSocket
2. Call DatagramSocket.BindServiceNameAsync(localServiceName)
3. Call DatagramSocket.JoinMulticastGroup
4. Call DatagramSocket.GetOutputStreamAsync
5. If successful, send data over the stream
Customers have reported that the asynchronous call to GetOutputStreamAsync completes with an error code of 0x80072AF9 = WSAHOST_NOT_FOUND which means: “No such host is known.”
The above logic worked just fine on Windows 8 and it has only been reported with the general availability (GA) of Windows 8.1. If you experience this same problem with Windows 8 system, then there is no workaround on Windows 8 and you can upgrade your system to Windows 8.1. If you continue to see this issue even after upgrading to Windows 8.1, you can use the approach mentioned below. The problem has only been reported for users with systems connected through Wi-Fi rather than being connected through Ethernet.
The problem happens due to an issue in the route selection logic inside the tcpip.sys driver, where a wrong interface (either disabled or an inactive interface) is returned to the caller. When the Multicast packet is sent over that faulty route, the 0x80072AF9 error is returned because there is no active route to that IP Address.
To workaround the issue, you can implement your code logic to select a specific network adapter in Step 2 above, instead of letting the OS choose it for you.
Windows 8.1 has introduced a new overload for the function BindServiceNameAsync(localServiceName, adapter) which you can use to specify a particular network adapter (second parameter).
For example, you can use the NetworkInformation.GetInternetConnectionProfile() function to retrieve the internet connected profile and use the NetworkAdapter of the returned profile in the call to BindServiceNameAsync(localServiceName, adapter) overload of the function. This two parameter overload is new on Windows 8.1 and not available on Windows 8.
Here is a C# version of the implementation which does the same. The DemoProjects.zip at the end of this article contains four zip files, TestMCAppCSharp, TestMCAppVB, TestMCAppCPlusPlus and TestMCAppJS. Each of these contains the projects in C#, VB.Net, C++ and JS language for your reference.
DatagramSocket socket = new DatagramSocket();
///...other code...
///
/// retrieve the best network adapter to use
///
ConnectionProfile connectionProfile = NetworkInformation.GetInternetConnectionProfile();
///
/// call BindServiceNameAsync overload with 2 parameters. This overload is ONLY available on Windows 8.1
/// Don't specify a local port unless you have some type of dependency on that local port.
/// If the local port is being used by some other app, you'll get an exception
///
await socket.BindServiceNameAsync("", connectionProfile.NetworkAdapter);
socket.JoinMulticastGroup(new HostName(ipAddress));
IOutputStream outputStream = await socket.GetOutputStreamAsync(new HostName(ipAddress), port);
///...other code...
Hopefully this blog will help resolve the above issue for you!
Follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.
Comments
Anonymous
February 04, 2014
Thanks for posting. This issue had me stumped.Anonymous
February 11, 2014
We saw this today on a PC where the hardware Wi-Fi switch was off. Adapter in Windows showed enabled but not connected. PC had an active Ethernet connection only. Is there a hotfix/Windows Update coming for this? Under 8.0 the UDP broadcast is made against every adapter on the PC over IPV4 and 6. By specifying only one adapter the discovery process is less and means that custom 8.1 builds are required to work around the bug.Anonymous
February 11, 2014
Note also that the workaround won't help a bunch of PCs running offline which is what we often have. Because getInternetConnectionProfile returns NULL when there is no Internet connection... something to watch out for. A true fix to restore 8.0 operation is definitely required here.Anonymous
April 20, 2014
Thank for the workaround. I had the same issue for Windows 8 and 8.1 for some machines, not for the others. Here is one more workaround for the case without Internet connection in my application to get the network adapter. public class MyIPAddress { //developer.nokia.com/.../How_to_get_the_device_IP_addresses_on_Windows_Phone public static string FindIPAddress() { List<string> ipAddresses = new List<string>(); var hostnames = NetworkInformation.GetHostNames(); foreach (var hn in hostnames) { //IanaInterfaceType == 71 => Wifi //IanaInterfaceType == 6 => Ethernet (Emulator) if (hn.IPInformation != null && (hn.IPInformation.NetworkAdapter.IanaInterfaceType == 71 || hn.IPInformation.NetworkAdapter.IanaInterfaceType == 6)) { string ipAddress = hn.DisplayName; ipAddresses.Add(ipAddress); } } if (ipAddresses.Count < 1) { return null; } else if (ipAddresses.Count == 1) { return ipAddresses[0]; } else { //if multiple suitable address were found use the last one //(regularly the external interface of an emulated device) return ipAddresses[ipAddresses.Count - 1]; } } public static NetworkAdapter GetNetworkAdapterByIP(string ipAddress) { NetworkAdapter adapter = null; var hostnames = NetworkInformation.GetHostNames(); foreach (var hn in hostnames) { if (hn.IPInformation != null && hn.DisplayName == ipAddress) { adapter = hn.IPInformation.NetworkAdapter; break; } } return adapter; } }Anonymous
October 25, 2014
Thank you very much, that's the right solution!Anonymous
January 21, 2015
We believe this problem also affects the SSTP VPN client in Windows 8 & 8.1. Our SSTP setup has run fine for years we regularly have remote Win7 VPN clients connected in for hours on end without fault. On a number of Windows 88.1 systems (not all but a large proportion, > 75%) they report error 0x80072AF9 and won't connect, it happens quite quickly and leaves the impression the system never actually even tried to connect to the VPN, packet analysis (wireshark) proves this. We can affect this although the steps in the process do seem to change around some, but generally, disable Wireless NIC reboot, connect LAN cable check SSTP works via LAN cable, then you can switch back to wireless and generally all works until the next restart. I've tested this extensively, being both an MCSE (in every version since NT4) and a MSCD with over 25 years of setting up MS systems, I believe this is a fault in the Win8 OS. Please can someone from MS please confirm this and also advise to when this will be patched? (so our Win8 users can connect in remotely). Also this has totally stopped any further Win8 deployment And finally, sorry to say this as years back I was a huge MS fan, Win8 now worse than both Vista and WindowsME. I don't understand why MS isn't following it's previous designs and I'm feed up of UI elements that just don't do what the old UI did. And the Win8 start menu, that's like Ford changing the steering wheel for 2 levels, although I'm sure Ford wouldn't be that stupid.Anonymous
January 31, 2015
Same thing happened here on an HTML/JavaScript app. Works fine on Windows Phone, but on my PC over WiFi, I had to use this workaround.Anonymous
May 27, 2015
Thanks, this seemed to solve the "host not found" datagram multicasting problem in winRT. This should be fixed for DatagramSocket or included in the msdn class documentation.