#130 infinite loop in UpnpGetIfInfo() under WIN32

[Shaddy Baddah]

I've been trying to track down why VLC, both 32-bit and 64-bit, don't do the UPNP network discovery under Windows. This works fine under Linux.

In doing so, I came across some discussion saying that you need to pass the multicast interface name to VLC via -miface. When I do this, regardless of the interface name I pass, the VLC process hangs and needs to be manually killed.

Debugging as best as I can, I followed the code at the point that the interface name is passed, which is to UpnpInit2(). And following the code, I see that UpnpGetIfInfo() is where all the action happens. Purely on code inspection, I see this code suggesting that a infinite while loop may be the culprit to the process hang:

adapts_item = adapts;
while (adapts_item != NULL) {
    if (adapts_item->Flags & IP_ADAPTER_NO_MULTICAST) {
        continue;
    }

Am I reading it correctly that progressing the iterator is not occurring if the IP_ADAPTER_NO_MULTICAST is set on one of the early interfaces in the list?

Unfortunately I cannot confirm this myself, as I cannot build a debug version of libupnp to log what is happening. I don't have Visual Studio (and have had trouble even installing a trial version), and compiling under mingw32-64 (i686), the build fails. And whilst I have vast posix build experience, my Windows build knowledge frequently comes a cropper (it seems with the win32api, I can't even rely on the foundation rule of include guards as a safety net that allows copious inclusion of other headers as necessary. but i'll bring this up in the discussion forum).

[Marcelo Roberto Jimenez]

Hi Shaddy Baddah,

You are most likely right, the code does not make sense.

I am not able to test it here because I have no windows to compile or test it. But if you find a working solution, I will gladly committ it.

On a superficial look on the code, I would try the patch I am attaching, please report if it works.

There is also another problem with this code. The documentation of GetAdaptersAddresses() says explicitly that this way of finding out the necessary space to allocate memory is strongly discouraged as the number of adapters may change between calls. If anyone there fixes the first issue, please fix this second one too.

Regards,
Marcelo.

[Shaddy Baddah]

Hi. I noticed that this has now been fixed. Using the latest VLC seems to confirm this (as the bug was stopping upnp discovery under Windows).