New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UpnpInit2(...) returns UPNP_E_SOCKET_BIND error #195
Comments
Hi and welcome jaehyung-po, There are many ways to find the version of the library. Since you are developing code and linking against it, you can be using a pre-compiled version supplied by your linux distribution or you could have compiled the library from the source code. Since you do not know the version, it is likely that you have it from the linux distro, in which case you should check the package version (rpm or deb)? If you are able to find a file named upnpconfig.h, you can read the version in a define called UPNP_VERSION_STRING. You might also try to compile libupnp from the source code to use the latest updates and bug fixes. Github makes it convenient if you can use git, but this is not required. Regards, |
The version I'm using is 1.12.0. and I tried with 1.14.0, but it has same issue. Additionally, I found the side effect of disabling ipv6. (on version 1.12.0)
Thank you for reading. |
Hi, Sorry for the late reply. If these are still issues, we need an objective way to test them, otherwise it gets too hard. Maybe you could modify the sample code Regards, |
`init_socket_stuff` was ignoring `inet_pton`'s return value causing invalid IPs being seen as valid which caused bad calls to `bind` and `listen` further in the code path. Invalid `bind`s were frequents for interfaces providing only one IP protocol version (IPv4 or v6). In those cases, `gIF_IPV4` or `gIF_IPV4` were left to their default values (an empty string) causing `inet_pton` to fail silently without aborting the socket opening and binding... Fixes pupnp#195
`init_socket_stuff` was ignoring `inet_pton`'s return value causing invalid IPs being seen as valid which caused bad calls to `bind` and `listen` further in the code path. Invalid `bind`s were frequents for interfaces providing only one IP protocol version (IPv4 or v6). In those cases, `gIF_IPV4` or `gIF_IPV4` were left to their default values (an empty string) causing `inet_pton` to fail silently without aborting the socket opening and binding... Refs pupnp#195
VLC 3.0 uses libupnp exclusively as a client. LibUpnp internals are quite opaque and it has been observed that a webserver thread is still running on idle with open sockets even if the library is used as a client only. The recent bump to 1.14 introduces regressions in libupnp's webserver socket initialization [1] on windows. Since the bug is still not corrected upstream and we don't have any use of the webserver for 3.0 anyway, let's just disable it. [1] pupnp/pupnp#195 Fixes videolan/vlc#27001
`init_socket_stuff` was ignoring `inet_pton`'s return value causing invalid IPs being seen as valid which caused bad calls to `bind` and `listen` further in the code path. Invalid `bind`s were frequents for interfaces providing only one IP protocol version (IPv4 or v6). In those cases, `gIF_IPV4` or `gIF_IPV4` were left to their default values (an empty string) causing `inet_pton` to fail silently without aborting the socket opening and binding... Refs pupnp#195
`init_socket_stuff` was ignoring `inet_pton`'s return value causing invalid IPs being seen as valid which caused bad calls to `bind` and `listen` further in the code path. Invalid `bind`s were frequents for interfaces providing only one IP protocol version (IPv4 or v6). In those cases, `gIF_IPV4` or `gIF_IPV4` were left to their default values (an empty string) causing `inet_pton` to fail silently without aborting the socket opening and binding... Refs pupnp#195 (cherry picked from commit 447de4e)
`init_socket_stuff` was ignoring `inet_pton`'s return value causing invalid IPs being seen as valid which caused bad calls to `bind` and `listen` further in the code path. Invalid `bind`s were frequents for interfaces providing only one IP protocol version (IPv4 or v6). In those cases, `gIF_IPV4` or `gIF_IPV4` were left to their default values (an empty string) causing `inet_pton` to fail silently without aborting the socket opening and binding... Refs pupnp#195 (cherry picked from commit 447de4e)
`init_socket_stuff` was ignoring `inet_pton`'s return value causing invalid IPs being seen as valid which caused bad calls to `bind` and `listen` further in the code path. Invalid `bind`s were frequents for interfaces providing only one IP protocol version (IPv4 or v6). In those cases, `gIF_IPV4` or `gIF_IPV4` were left to their default values (an empty string) causing `inet_pton` to fail silently without aborting the socket opening and binding... Refs #195 (cherry picked from commit 447de4e)
First, Thank you for providing this library.
I use pupnp like this way below.(in c++)
class UpnpDevice is a threaded object.
UpnpDevice Initializes UPnP(initialize upnp, get ip and port, set web server root directory, register root device,...) in the constructor and starts thread.
UpnpDevice finishes UPnP(I mean UpnpFinish()) in destructor.
When I create unique pointer in other class(I would call it Handler from now on) and set a network interface name to execute UpnpInit2(...), It works fine.
Now, There is a situation that network interface or IP is changed.
Handler catches that situation and resets UpnpDevice object and sets new network interface name.
Then, UpnpInit2(...) returns UPNP_E_SOCKET_BIND error forever.(in while loop, it tried to UpnpInit2(..), UpnpGetServerIpAddress() and UpnpGetServerPort() until it returns UPNP_E_SUCCESS)
EXCEPTION : If network interface name and ip are same, then it initialized well.
I tried to debug and found the code returning that value.
pupnp > upnp > src > genlib > miniserver > miniserver.c > get_miniserver_sockets > #ifdef UPNP_ENABLE_IPV6
so, In the same code, I disabled IPV6 by
configure --disable-ipv6
. (I don't need ipv6)And It worked well.
I'm using linux, and I don't know how to find the version of this pupnp code.
I'll post the version if you tell me the way to get the version.
Thank you.
The text was updated successfully, but these errors were encountered: