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?
Best regards
Uwe
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (800, 'testing'), (600, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libupnp6 depends on:
ii libc6 2.21-6
libupnp6 recommends no packages.
libupnp6 suggests no packages.
-- no debconf information
