#127 Miniserver uses INADDR_ANY instead of HostIP

branch-1.6.x
closed-fixed
INADDR_ANY (1)
5
2017-01-21
2015-03-09
No

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?

1 Attachments

Discussion

  • Marcelo Roberto Jimenez

    Klaus,

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

    Regards,
    Marcelo.

     
  • Marcelo Roberto Jimenez

    • assigned_to: Nick Leverton
     
  • Klaus Fischer

    Klaus Fischer - 2016-01-11

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

    Regards,
    Klaus

     
  • Marcelo Roberto Jimenez

    • status: open --> closed-accepted
     
  • Nick Leverton

    Nick Leverton - 2016-01-16

    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

    • status: closed-accepted --> open-accepted
     
  • 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

    Klaus Fischer - 2016-01-25

    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

    • status: open-accepted --> closed-accepted
     
  • Marcelo Roberto Jimenez

    Ok, Klaus, thanks!

    Closing the issue.

     
  • Marcelo Roberto Jimenez

    • status: closed-accepted --> open
     
  • 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

     
    Last edit: Marcelo Roberto Jimenez 2016-02-01
  • tony mancill

    tony mancill - 2016-10-16

    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

    Klaus Fischer - 2016-10-17

    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

    tony mancill - 2016-10-18

    Hi Klaus,

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

    Cheers,
    tony

     
  • Marcelo Roberto Jimenez

    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks