#127 Miniserver uses INADDR_ANY instead of HostIP

[Klaus Fischer]

The internal miniserver.c uses INADDR_ANY instead of the HostIP/IfName provided when initializing libupnp. But, this HostIP/IfName gets used for the UDP socket when multicasting SSDP messages.

In my situation this causes a problem, since I want to use libupnp with 127.0.0.1 (localhost) but the SSDP multicast gets signalled to the regular network interface as well, where another software connects to the miniserver, thus binding the miniserver's socket to that particular interface and not to 127.0.0.1 (INADDRY_ANY binds the socket to the first interface a connection attempt is received from).

Attached patch fixes this issue for IPV4. Unfortunately, I don't know how to handle this for IPV6 (which I don't need btw.).

Is there any reason to explicitly use INADDR_ANY for the miniserver? Or could you consider using the attached patch and extend it for IPV6?

[Nick Leverton]

This updated patch should fix it for both IPv4 and IPv6.

[Marcelo Roberto Jimenez]

Klaus,

I have committed Nick's patch, please test and report.

Regards,
Marcelo.

[Klaus Fischer]

Test result was positive; I could only test IPV4, not IPV6 case, though.

Regards,
Klaus

[Nick Leverton]

Hi Marcelo, sorry but I think you've committed the IPv4 only patch in 4f98a55c. I added IPv6 support in the first comment but forgot to rename the patch to make it clear, sorry.

[Marcelo Roberto Jimenez]

Ok Nick, just did the correction to your first patch.

Klaus, would you mind testing the new version, since it is different from the other one?

Regards,
Marcelo.

[Klaus Fischer]

Hi Marcelo,

Test result was positive on this one too. Again, I could only test IPV4, not IPV6 case.

Thanks for committing the patch!

Regards,
Klaus

[Marcelo Roberto Jimenez]

Ok, Klaus, thanks!

Closing the issue.

[Marcelo Roberto Jimenez]

Forwarding an email I have received from Uwe Kleine-König.

---

Control: tag 813249 + upstream

[adding Marcelo Roberto Jimenez (i.e. upstream) to Cc]

Hello,

On 01/30/2016 11:05 PM, Uwe Kleine-König wrote:

Package: libupnp6
Version: 1:1.6.19+git20160116-1
Severity: normal

Hello,

vlc stopped showing my dlna provider, when downgrading libupnp6 to
1:1.6.19+git20141001-1 it works fine again.

With libupnp6 1:1.6.19+git20141001-1 the (I think) relevant part obtained from strace is:

  10317 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 18
  10317 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 19
  10317 setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
  10317 bind(18, {sa_family=AF_INET, sin_port=htons(49152), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
  10317 bind(19, {sa_family=AF_INET6, sin6_port=htons(49152), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
  10317 listen(18, 128)                   = 0
  10317 getsockname(18, {sa_family=AF_INET, sin_port=htons(49152), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
  10317 listen(19, 128)                   = 0
  10317 getsockname(19, {sa_family=AF_INET6, sin6_port=htons(49152), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0

while with 1:1.6.19+git20160116-1 I get:

  10997 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 18
  10997 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 19
  10997 setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
  10997 bind(18, {sa_family=AF_INET, sin_port=htons(49152), sin_addr=inet_addr("192.168.77.157")}, 16) = 0
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49152), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49153), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49154), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49155), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(49156), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  ...
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65531), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65532), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65533), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65534), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 bind(19, {sa_family=AF_INET6, sin6_port=htons(65535), inet_pton(AF_INET6, "fe80::f2de:f1ff:fe44:529d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
  10997 close(18)                         = 0
  10997 close(19)                         = 0

The obvious difference is that the newer libupnp uses an explicit
address for binding the port, but I don't see this as an excuse for bind
to fail. And in fact the same difference exists for ipv4 where there
doesn't seem to be a problem.

btw, netcat-openbsd has the same problem:

  nc fe80::2ac6:8eff:fe36:df57 22

fails with:

  connect(3, {sa_family=AF_INET6, sin6_port=htons(22), inet_pton(AF_INET6, "fe80::2ac6:8eff:fe36:df57", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)

while it works fine when using the ipv4 or a global ipv6 of the same
machine.

So it seems to be a bad idea to use the link local ipv6. Without
checking the source code, for machines with >1 network device using the
wildcard address seems to be easier. Also it would be nice if libupnp
fell back to ipv4 only if it fails to connect via ipv6.

Maybe this bug is a regression from addressing #781876?

No, it's not, it's a regression from

• Bind miniserver sockets to our given IP address not INADDR_ANY (patch 24).

that is upstream bug 127[1]. When reverting that one, vlc works as
expected (and before).

While searching for the problem I stumbled about the following paragraph
in ipv6(7):

ERRORS
ENODEV The user tried to bind(2) to a link-local IPv6 address,
but the sin6_scope_id in the supplied sockaddr_in6
structure is not a valid interface index.

This doesn't match EINVAL that I'm seeing, but still is the problem I
think. libupnp (and also netcat) pass 0, which isn't a valid scope_id.
(The valid scope_ids can be determined from either $(ip link) or with
the SIOCGIFINDEX ioctl on a socket (see netdevice(7)). Not sure how
portable to non-Linux architectures that is though.

Best regards
Uwe

[tony mancill]

Hi,

I ran across this thread while trying to figure out why VLC fails to find any UPnP/DLNA servers on my local network. Reverting the miniserver_IPV4_INADDR_ANY.patch and rebuilding resolved the issue for me. I realize that this is opting for one use case over the other, but the patch (which is now committed in the 1.6.20 release) is preventing use of VLC as a UPnP/DLNA client.

Perhaps you could revisit this for the next release?

Thank you,
tony

Other references:
* https://bugs.launchpad.net/ubuntu/+source/libupnp/+bug/1571199
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813249

[Klaus Fischer]

Hi Tony,

shoudln't using INADDR_ANY as IP address during libupnp initialization have the same effect as reverting the patch? Since before the patch, INADDR_ANY was used internally for binding instead of the IP address supplied during initialzation. So wouldn't the best solution be to keep the patch but change the initialization of libupnp, probably inside VLC?

Best regards,
Klaus

[tony mancill]

Hi Klaus,

That's a good idea. I'll look into getting VLC working against an unpatched libupnp (version 1.6.20).

Cheers,
tony