search

novotnyllc / Zeroconf

Bonjour support for .NET Core, .NET 4.6, Xamarin, and UWP
MIT License
368 stars 92 forks source link

ZeroconfResolver.ResolveAsync doesn't work unless the WiFi network adapter is restarted #178

Open AmirMahdiNassiri opened 4 years ago

AmirMahdiNassiri commented 4 years ago

Thank you for your amazing library and all your efforts.

Sometimes when I execute "ZeroconfResolver.ResolveAsync" to discover a specific service over my local network, I get nothing in return, no matter how many times I retry. But interestingly, if I disable and enable the WiFi network adapter, the next "ZeroconfResolver.ResolveAsync" would fetch me the services!

By disabling and enabling the WiFi network adapter I mean executing the following CMD commands:

netsh interface set interface "Wi-Fi" disable

and then

netsh interface set interface "Wi-Fi" enable

Any ideas on how I can fix the problem without restarting the WiFi adapter?! Since restarting the adapter requires administrator privileges that a standard user can not have. I'm no expert in socket programming or the underlying connection, but can't we perform any kind of cleanup that prevents a complete restart of the physical device?

Any help or tips would be greatly appreciated.

clairernovotny commented 4 years ago

I'm not sure, sorry. If there's something in the code we can check, happy to take a PR.

littlefryingpan commented 3 years ago

After hours trying to figure out why it wasn't resolving, I tried disabling and enabling the wifi adapter and found that I am having the same issue.

If I use BrowseDomainsAsync, I can see it every time, but once I try to resolve, same result as above, empty list.

We are using version 3.4.2, this happens for all services that I try to resolve, I always get an empty response, but if I just toggle off and on the adapter, the next response has results....

SuperHugh commented 3 years ago

If I may contribute, I would say that it seems that there is an issue with multicast request, Wi-Fi interface (which only start working again after Disabling/Enabling it) and Windows (10 in my case).

In order to troubleshoot this issue, I have tried another tool on the same network interface and it worked (while another tool didn't). I used wireshark to determine the difference between zeroconf mDNS requests and the tool that worked and I noted that the request that worked was made using unicast request instead of multicast.

Maybe Zeroconf could be modified to do the first query using unicast, then fallback to multicast... I would not know how to do it though but I guess it could be feasible...

I have found another zeroconf project (in python) which seem to have worked around this limitation this way: PyPI Look for version 0.32.0 release notes.

AmirMahdiNassiri commented 3 years ago

@SuperHugh Interesting observations. Thanks for sharing the Wireshark experiment 👍

Can you please point out which specific change in that Python package's release notes is related to this problem? The list for version 0.32.0 is too long!

SuperHugh commented 3 years ago

@SuperHugh Interesting observations. Thanks for sharing the Wireshark experiment 👍

Can you please point out which specific change in that Python package's release notes is related to this problem? The list for version 0.32.0 is too long!

I did not notice there was that much changes in the release notes of 0.32.0 since I found that project by searching for zeroconf unicast on the internet. You can search the page PyPI project release notes page for unicast and find many interesting notes. The one that picked my curiosity was the first item in the release notes but it seems unicast is also mentioned at a couple of places in past releases.

I hope you make sense I still have lots of reading to do in order to understand mDNS yet.

Thanks for the quick reply!

P.S.: I you need someone to test a release candidate for a fix for this issue, I would be interested to do it.

Trawacho commented 2 years ago

Hello, I have the same problem. Using zeroconf with LAN works as expected. Using WiFi I see the outgoing message but no incoming response (checked with Wireshark). Debugging with second PC (connected to the same network with cable) the outgoing message and also the responses can be tracked. To turn the WifI ON and OFF can solve the problem. As I play around with Win IoT on PI, I use the "Windows 10 IoT Core Dashboard". After starting this app I can also see outgoing and incoming messages.

Is a solution already known? Thanks!

andywyattsvp commented 1 year ago

For people who have been having a problem with this (have needed to restart/reset their Wi-Fi module), was it an Intel Wi-Fi AX211 or similar card by any chance? I have this problem too and have had other Wi-Fi related issues with it.

kristianputman commented 1 year ago

This may not be related to the above issue at all, but an observation I would add - "dumb" network switches that have IGMP disabled will treat multicast as a broadcast, which can cause the network to flood. We recently had to modify our corporate network at work in order to resolve this issue during testing for audio over IP.

I raise this because SuperHugh mentioned that unicast was not experiencing the same issues.