From owner-freebsd-ports-bugs@freebsd.org Sun Sep 9 22:58:50 2018 Return-Path: Delivered-To: freebsd-ports-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 695DA10A158C for ; Sun, 9 Sep 2018 22:58:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 05E0384D3A for ; Sun, 9 Sep 2018 22:58:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id BE62310A158B; Sun, 9 Sep 2018 22:58:49 +0000 (UTC) Delivered-To: ports-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C4E510A158A for ; Sun, 9 Sep 2018 22:58:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FAC784D38 for ; Sun, 9 Sep 2018 22:58:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 426CA111E0 for ; Sun, 9 Sep 2018 22:58:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w89MwmRY028053 for ; Sun, 9 Sep 2018 22:58:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w89MwmSl028052 for ports-bugs@FreeBSD.org; Sun, 9 Sep 2018 22:58:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 231274] libtorrent/rtorrent incoming connections broken since 0.13.7/0.9.7 update Date: Sun, 09 Sep 2018 22:58:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: PopularMoment@protonmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 22:58:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231274 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@FreeBSD.org Reporter: PopularMoment@protonmail.com CC: dbaio@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 immediat= ely dropped and no further communication appears possible on incoming connectio= ns. 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 f= or AF_INET6.=20 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 se= ems 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 performe= d so that may break further functionality but it should be enough to illustrate = the problem and a avenue for a possible proper fix. --=20 You are receiving this mail because: You are the assignee for the bug.=