search

lontivero / Open.NAT

Lightweight and easy-to-use class library to allow port forwarding in NAT devices with UPNP and/or PMP
MIT License
420 stars 99 forks source link

Very long device discovery #72

Open Eideren opened 7 years ago

Eideren commented 7 years ago

Device discovery works but its duration is very inconsistent and takes often a very-very long time before reporting the device. It falls anywhere between 10 seconds and 500 seconds.

If I run 5 instances of device discovery concurrently, the first one to find the device (not always the first one to run) reports back between 5 and 30 seconds later, while better than the first result, it is still nowhere near acceptable for a user and having that many searchers uses far too much CPU.

My modem (Technicolor TG589Bvac XTream) provided by our ISP (Belgacom/Proximus) is notoriously bad with NAT and port forwarding, here's something that I found and that might help you :

A problem with multicast protocols such as SSDP (discovery of file servers, printers, DLNA servers, etc.) and Bonjour (discovery of services on Apple devices - Airplay, Continuity, etc.). It seems that M-SEARCH messages over HTTPU get blocked or are not always propagated. The result is very annoying: my TV no longer finds my Synology DLNA server and Airplay does not work. If the DLNA server is set to broadcast over SSDP at very small intervals (30 seconds) then the TV finds it. If Airplay receiver is put on the 2.4 GHz network - it works again.

QBittorrent finds the device and port-forwards flawlessly though, it supposedly uses UPnP and NAT-PMP as well since disabling that feature in the options blocks the port.

Here's my network.log and here's qBittorrent's repo.

nathan130200 commented 6 years ago

Same here with ZyXel. Long time without a response. and UTorrent make port mapping in less than 5 seconds.

lontivero commented 6 years ago

Thanks for reporting it. I can see most of the time is wasted searching devices with IPv6 addresses. Also, searching for devices supporting PMP , which are the lees. I have no time to fix this, however I think it could be very easy for you to try doing the following:

  1. Use only Upnp protocol.
  2. Remove the following lines of code (UpnpSearcher.cs)
if (Socket.OSSupportsIPv6)
{
    Discover(client, WellKnownConstants.IPv6LinkLocalMulticastAddress, cancelationToken);
    Discover(client, WellKnownConstants.IPv6LinkSiteMulticastAddress, cancelationToken);
}

In case that improves the situation, please make a PR.