Bug 231274

Summary: net-p2p/libtorrent, net-p2p/rtorrent: Incoming connections broken since 0.13.7/0.9.7 update
Product: Ports & Packages Reporter: Henry <PopularMoment>
Component: Individual Port(s)Assignee: Danilo G. Baio <dbaio>
Status: Closed FIXED    
Severity: Affects Many People CC: dbaio, koobs, tj, vladislav.movchan
Priority: --- Keywords: regression
Version: Latest   
Hardware: amd64   
OS: Any   
URL: https://github.com/rakshasa/rtorrent/issues/786
Attachments:
Description Flags
libtorrent patch
none
rtorrent patch
none
libtorrent fix and noop post-patch removal
none
rtorrent cleanup - remove unused patch extra-clang none

Description Henry 2018-09-09 22:58:48 UTC 
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.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2018-09-10 03:34:07 UTC 
Thank you for your report Henry.

Given these ports don't currently have a maintainer, I'd recommend contacting/reporting the issue upstream to obtain an authoritive response/change proposal on the issue as a first course of action, in the absence of an obvious/correct/tested patch.

Further, 10.2 is now EoL, so it would be worth reproducing (confirming) that the issue is present on at least 10.4-RELEASE (EoL October 2018) and 11.2-RELEASE, ie: currently supported branches. It may well be worth doing this before contacting upstream to isolate FreeBSD being a contributing cause.
Comment 2 Henry 2018-09-10 10:55:01 UTC 
Apologies, 10.2-RELEASE-p2 is a typo and should read 11.2-RELEASE-p2.
Comment 3 Henry 2018-09-29 15:41:32 UTC 
Created attachment 197597 [details]
libtorrent patch
Comment 4 Henry 2018-09-29 15:41:55 UTC 
Created attachment 197598 [details]
rtorrent patch
Comment 5 Henry 2018-09-29 15:52:02 UTC 
I've attached the patches that work around the issue for me.

I've been running a client with these applied for the last few days without issue.

I think these patches or a refinement thereof should be applied as it will fix a regression effecting everyone.

If that is not appropriate, then both ports should be rolled back to the last known good versions: libtorrent-0.13.6_5 / rtorrent-0.9.6_3.
Comment 6 Danilo G. Baio freebsd_committer freebsd_triage 2018-09-30 23:56:26 UTC 
Hi Henry.

I've opened an issue on Github.

if you have a GH account, please, help in the discussion there.

And thank you for your report.

Regards.
Comment 7 Henry 2018-11-07 23:16:42 UTC 
Created attachment 199065 [details]
libtorrent fix and noop post-patch removal
Comment 8 Henry 2018-11-07 23:17:58 UTC 
Created attachment 199066 [details]
rtorrent cleanup - remove unused patch extra-clang
Comment 9 Henry 2018-11-07 23:23:16 UTC 
Attached a proper fix for the incoming connections issue courtesy of Vlad Movchan from https://github.com/rakshasa/libtorrent/pull/181.

Also while there:
- remove noop post-patch in place substitutions from libtorrent
- remove unused patch extra-clang from rtorrent
Comment 10 Danilo G. Baio freebsd_committer freebsd_triage 2018-11-08 02:20:46 UTC 
Hi Henry.

Thanks for the patch.

I'll also test it with this other patch, that fix build with OpenSSL 1.1.x.
https://github.com/rakshasa/libtorrent/commit/7b29b6bd2547e72e22b9b7981df27092842d2a10

Regards.
Comment 11 commit-hook freebsd_committer freebsd_triage 2018-11-08 22:53:54 UTC 
A commit references this bug:

Author: dbaio
Date: Thu Nov  8 22:52:55 UTC 2018
New revision: 484484
URL: https://svnweb.freebsd.org/changeset/ports/484484

Log:
  net-p2p/[libtorrent|rtorrent]: Fix incoming connections

  Remove unused patches.

  While here, fix build with OpenSSL 1.1.x

  PR:		231274
  Submitted by:	Henry David Bartholomew <PopularMoment@protonmail.com>
  MFH:		2018Q4

Changes:
  head/net-p2p/libtorrent/Makefile
  head/net-p2p/libtorrent/files/patch-openssl-1.1.x
  head/net-p2p/libtorrent/files/patch-socket-issue
  head/net-p2p/libtorrent/pkg-plist
  head/net-p2p/rtorrent/Makefile
  head/net-p2p/rtorrent/files/extra-clang
Comment 12 Danilo G. Baio freebsd_committer freebsd_triage 2018-11-08 22:57:04 UTC 
Committed, thanks for your work!