[Bug 231274] libtorrent/rtorrent incoming connections broken since 0.13.7/0.9.7 update

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231274

            Bug ID: 231274
           Summary: libtorrent/rtorrent incoming connections broken since
                    0.13.7/0.9.7 update
           Product: Ports & Packages
           Version: Latest
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: Individual Port(s)
          Assignee: ports-bugs at FreeBSD.org
          Reporter: PopularMoment at protonmail.com
                CC: dbaio at freebsd.org

Incoming connections are no longer functional at least for me since the
0.13.7/0.9.7 update.

With libtorrent-0.13.6_5 / rtorrent-0.9.6_3 on 10.2-RELEASE-p2 any incoming
connection initiated to rtorrents listening port would stay open till the
timeout of 60 seconds was reached and only then terminated if no further
communication had been negotiated.

Beginning with the update to 0.13.7/0.9.7 incoming connections are immediately
dropped and no further communication appears possible on incoming connections.

The issue does not appear to manifest with connections initiated in the
opposite direction.

When trussing rtorrent and attempting to determine why connections are
immediately dropped I can see a call to setsockopt() with IPPROTO_IP on an
AF_INET6 socket, this socket is then closed because IPPROTO_IP is invalid for
AF_INET6. 

This is despite the listening and remote addresses being *IPv4*.

So the introduction/improvement/whatever of IPv6 support in 0.13.7/0.9.7 seems
to now create all sockets as AF_INET6 and then incorrectly call setsockopt with
IPPROTO_IP when it should use IPPROTO_IPV6.

The code in question:
https://github.com/rakshasa/rtorrent/blob/master/src/utils/socket_fd.cc#L74
https://github.com/rakshasa/libtorrent/blob/master/src/net/socket_fd.cc#L74

To test my theory I changed both calls to use IPPROTO_IPV6 and IPV6_TCLASS and
connections are no longer immediately dropped, no other tests were performed so
that may break further functionality but it should be enough to illustrate the
problem and a avenue for a possible proper fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.