On Tue, Oct 08, 2024 at 03:18:57AM +0000, Lucas Gabriel Vuotto wrote:
> On Mon, Oct 07, 2024 at 09:21:22PM GMT, Lucas Gabriel Vuotto wrote:
> > On Sun, Oct 06, 2024 at 07:35:35PM GMT, Anon Loli wrote:
> > > Bug 2:
> > > After some uneven time (0-15 minutes), SOME torrents just get Stalled
> > > after
> > > downloading (although I think that some never even get started).
> > > I could not find any correlation between settings and whatnot.
> > > The network is not at fault, and neither is the tracker.
> > > Not only has this been tested against different internet accesses and
> > > ISPs, it
> > > has also been tested with clearnet and I2P, and I2P is anonymous so ISP
> > > can't
> > > even figure out if torrenting is happening even if they wanted to.
> > >
> > > And torrenting worked fine on FreeBSD's qBittorent, although this was
> > > another
> > > computer. I will probably try another disk or something soon, but I very
> > > very
> > > doubt that this could be the cause of bug 2.
> > >
> > >
> > > What could be doing this? I for a long time thought that it was a
> > > I2P-specific
> > > thing until I noticed that it also happens to clearnet torrents.
> > > Default settings cause this too.
> > >
> > > This bug has been ongoing for many months.
> > > What helps is restarting qBittorrent.
> >
> > By any chance, do you run qBittorrent in a rtable(4) other than 0? If
> > that's the case, you should give the patch below for a try. It adds
> > support for that in net/libtorrent-rasterbar.
>
> Now with REVISION bump.
>
>
> diff refs/heads/master 48227dd1687dd2693a67ae71578fe57e9475ae8b
> commit - 5324f947be0d2b037a14f27d27648042f2d6d540
> commit + 48227dd1687dd2693a67ae71578fe57e9475ae8b
> blob - 533da6409cd6f133915ae3f1823dab4b2a976091
> blob + 5e24ad9f913633d4653488396aa8ff36c8717a0d
> --- net/libtorrent-rasterbar/Makefile
> +++ net/libtorrent-rasterbar/Makefile
> @@ -2,7 +2,7 @@ COMMENT = C++ library implementing a BitTorrent
> clien
>
> V = 2.0.10
> DISTNAME = libtorrent-rasterbar-${V}
> -REVISION = 0
> +REVISION = 1
>
> SHARED_LIBS += torrent-rasterbar 9.0 # 10.0.0
>
> blob - /dev/null
> blob + 21c032d13dc9a2585abd74efe633cebdda2b5d83 (mode 644)
> --- /dev/null
> +++ net/libtorrent-rasterbar/patches/patch-src_enum_net_cpp
> @@ -0,0 +1,48 @@
> +Handle non-zero rtable.
> +
> +Index: src/enum_net.cpp
> +--- src/enum_net.cpp.orig
> ++++ src/enum_net.cpp
> +@@ -1146,13 +1146,19 @@ int _System __libsocket_sysctl(int* mib, u_int
> namelen
> + }
> + ::close(s);
> + */
> ++#define nelems(_a) (sizeof((_a)) / sizeof((_a)[0]))
> ++
> ++#ifdef __OpenBSD__
> ++ int mib[7] = {CTL_NET, PF_ROUTE, 0, AF_UNSPEC, NET_RT_DUMP, 0,
> getrtable()};
> ++#else
> + int mib[6] = {CTL_NET, PF_ROUTE, 0, AF_UNSPEC, NET_RT_DUMP, 0};
> ++#endif
> +
> + std::size_t needed = 0;
> + #ifdef TORRENT_OS2
> +- if (__libsocket_sysctl(mib, 6, 0, &needed, 0, 0) < 0)
> ++ if (__libsocket_sysctl(mib, nelems(mib), 0, &needed, 0, 0) < 0)
> + #else
> +- if (sysctl(mib, 6, nullptr, &needed, nullptr, 0) < 0)
> ++ if (sysctl(mib, nelems(mib), nullptr, &needed, nullptr, 0) < 0)
> + #endif
> + {
> + ec = error_code(errno, system_category());
> +@@ -1172,9 +1178,9 @@ int _System __libsocket_sysctl(int* mib, u_int namelen
> + }
> +
> + #ifdef TORRENT_OS2
> +- if (__libsocket_sysctl(mib, 6, buf.get(), &needed, 0, 0) < 0)
> ++ if (__libsocket_sysctl(mib, nelems(mib), buf.get(), &needed, 0, 0) < 0)
> + #else
> +- if (sysctl(mib, 6, buf.get(), &needed, nullptr, 0) < 0)
> ++ if (sysctl(mib, nelems(mib), buf.get(), &needed, nullptr, 0) < 0)
> + #endif
> + {
> + ec = error_code(errno, system_category());
> +@@ -1204,6 +1210,8 @@ int _System __libsocket_sysctl(int* mib, u_int namelen
> + ip_route r;
> + if (parse_route(s, rtm, &r)) ret.push_back(r);
> + }
> ++#undef nelems
> ++
> + #elif TORRENT_USE_GETIPFORWARDTABLE
> + /*
> + move this to enum_net_interfaces
Interesting question!
For the clearnet torrenting I tried the default /etc/pf.conf before, and it
exhibits said behavior.. no idea if the rtables have anything to do with this
and if they somehow change >> by default <<, but I will give it a try!
I will be testing the setup with what the manual for rtable(4) provides:
> route -T0 exec /usr/local/bin/qbittorrent
I will get to you within 24 hours, probably, with a firm response... as a data
hoarder (as seen in my signature below xD), this is quite important to me, so
yeah I can't wait to respond, really, and hopefully the result will positive.
IF the said route(8) command works, then I will apply your patch, and also give
that a try.
(update after like 10min from above)
I'm seeing some suprising speed, and this is with I2P, so we might be onto
something!
If it does not work, then I'll try go provide even more details, if possible.
I'm glad that someone responnded back, and with a potential solution? Lets go!
Thanks.
--
Anon Loli
#########
This mortal strives for omnisciency. Some tags: perfectionist, minimalist,
researcher, scientist, philosopher, developer, autist, anarchist, data hoarder,
99 other tags and interests.
I am always up for conversing as long as you meet these requirements:
1. Use PGP encryption for all data shared,
2. Use a open source operating system,NOT Windows, NOT MacOS,
3. Have a open mind - are ready to let go of any and all imperfect views on
anything, if they are.
Let's change this world for the better, one action at a time
########################
<anonl...@autistici.org>
