Skip to content
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

Open
jaehyung-po opened this issue Aug 13, 2020 · 3 comments
Open

UpnpInit2(...) returns UPNP_E_SOCKET_BIND error #195

jaehyung-po opened this issue Aug 13, 2020 · 3 comments

Comments

@jaehyung-po
Copy link

jaehyung-po commented Aug 13, 2020

First, Thank you for providing this library.

I use pupnp like this way below.(in c++)

  1. class UpnpDevice is a threaded object.

  2. UpnpDevice Initializes UPnP(initialize upnp, get ip and port, set web server root directory, register root device,...) in the constructor and starts thread.

  3. UpnpDevice finishes UPnP(I mean UpnpFinish()) in destructor.

  4. 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.

  5. Now, There is a situation that network interface or IP is changed.

  6. Handler catches that situation and resets UpnpDevice object and sets new network interface name.

  7. 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)

  8. 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.

@mrjimenez
Copy link
Collaborator

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,
Marcelo.

@jaehyung-po
Copy link
Author

jaehyung-po commented Aug 18, 2020

The version I'm using is 1.12.0.
I got the version number by printing UPNP_VERSION_STRING.

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)

  1. I'm using my program as linux service.
  2. When i disable ipv6 in pupnp, upnp that is executed first after the boot of linux device does not work.
    (even upnp methods return success value)
  3. if i stop service and restart service or program, upnp works.
  4. It is not important that the program is service or not.
    First upnp initialization does not work after the boot or installation of pupnp without ipv6,
    even though upnp methods return success.

Thank you for reading.

@mrjimenez
Copy link
Collaborator

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 tv_device to try to illustrate the issue there.

Regards,
Marcelo.

AlaricSenat added a commit to AlaricSenat/pupnp that referenced this issue Jun 9, 2022
`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
AlaricSenat added a commit to AlaricSenat/pupnp that referenced this issue Jun 9, 2022
`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-mirrorer pushed a commit to videolan/vlc that referenced this issue Jun 13, 2022
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
AlaricSenat added a commit to AlaricSenat/pupnp that referenced this issue Jun 17, 2022
`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
AlaricSenat added a commit to AlaricSenat/pupnp that referenced this issue Jun 17, 2022
`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)
AlaricSenat added a commit to AlaricSenat/pupnp that referenced this issue Jun 17, 2022
`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)
mrjimenez pushed a commit that referenced this issue Jun 17, 2022
`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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants