Library should not use all available interfaces for outgoing requests

[ValdikSS]

Cross-post from qBittorrent qbittorrent/qBittorrent#24730, as the same behavior is with Deluge, and is a default behavior of libtorrent.

• qBittorrent: 5.2.3 / Deluge 2.2.0
• libtorrent: 2.1.0 / 2.0.11
• Linux

What is the problem?

In short, libtorrent by default uses all available network interfaces at least for DHT and torrent announces (see #7902).
For L3/Point-to-Point interfaces (almost all tunnels: PPP, PPTP, OpenVPN, WireGuard, GRE, IPIP, ...) this results in using network interface even if no routes are present

---

Basically I've only added a GRE tunnel, added the address on it, and qBittorrent started to send UDP packets to DHT peers over it, even if there's no default route is configured for this interface.

Right now, from what I could see in the code and in the behavior, qBittorrent auto-detects network interfaces and configures 0.0.0.0, :: as lt::settings_pack::listen_interfaces and an empty string as lt::settings_pack::outgoing_interfaces

https://github.com/qbittorrent/qBittorrent/blob/e70f13d46a42b204559d0e7b16a19eeca522fe9e/src/base/bittorrent/sessionimpl.cpp#L2247-L2259

According to libtorrent documentation, outgoing_interfaces:

This string is a comma-separated list of IP addresses and interface names. An empty string will not bind TCP sockets to a device, and let the network stack assign the local address.

but listen_interfaces

These are also used for outgoing uTP and UDP tracker connections and DHT nodes.

It seems that supplying 0.0.0.0, :: to listen_interfaces means that it will not use 0.0.0.0, :: in a sense of "bind to 0.0.0.0 and use default routing", but it handles it in a "smart" way of enumerating all interfaces and binding to all of them (opens the socket for each device and binds it both to the address (bind()) and to the device (setsockopt SO_BINDTODEVICE), as seen with strace).

I hope the comment for listen_interfaces means that every interface would be used only for DHT/trackers, and not for data downloading, but mentioning µTP makes me doubt it.

Steps to reproduce

1. On Linux, create dummy GRE interface: ip link add testgre type gre remote 1.0.0.0
2. Set it up: ip link set testgre up
3. Assign the address: ip addr add 192.168.60.1/32 dev testgre
4. Run tcpdump -n -i testgre
5. Launch qBittorrent

Result

First-launched qBittorrent starts to discover DHT peers over testgre interface, even if there's no default route over it.

15:21:40.106980 IP 192.168.60.1.64051 > 67.215.246.10.6881: UDP, length 111
15:21:40.107009 IP 192.168.60.1.64051 > 87.98.162.88.6881: UDP, length 111
15:21:40.107033 IP 192.168.60.1.64051 > 185.157.221.247.25401: UDP, length 111
15:21:40.107056 IP 192.168.60.1.64051 > 212.129.33.59.6881: UDP, length 111

Expected result

libtorrent might listen for incoming connections on all interfaces but should not attempt to do any outgoing activity over non-default-route interface, especially with bypass of main routing table.

The feature of what libtorrent currently does is useful, but it should be activated if listen_interfaces is set to something like auto.
If 0.0.0.0, it set, I'd expect to do literally that: bind to 0.0.0.0 and follow routing decisions.

[ValdikSS]

https://github.com/arvidn/libtorrent/blob/8c3f7f9126ad65eea8cfbf767b606316cdd938d2/docs/manual.rst#expanding-unspecified-addresses

expanding unspecified addresses

If an IP address is the unspecified address (i.e. 0.0.0.0 or ::),
libtorrent will expand it to specific IP addresses. This expansion will
enumerate all addresses it can find for the corresponding address family.
The expanded IP addresses are considered "local network" if any of the following
conditions are met:

• the IP address is in a known link-local range
• the IP address is in a known loopback range
• the item the IP address was expanded from was marked local (l)
• the network interface has the loopback flag set
• NONE of the following conditions are met:
  1. the IP address is in a globally reachable IP address range
  2. the network interface has the point-to-point flag set
  3. the routing table contains a route for at least one global internet address
     (e.g. a default route) for the address family of the expanded IP that points to
     the network interface of the expanded IP.

Due to ii (point-to-point), the interface is marked as non-local.

[arvidn]

As I think you've figured out, this is part of supporting multi-homed machines.

Your proposed solution, of defaulting to assume a simple single-homed machine and just binding to INADDR_ANY, has its merits. I don't believe it's quite so simple though, without sacrificing multi-homed support.

I think the main problem is that it might actually break multi-homed machines. for example, when running a DHT node on 0.0.0.0, and we receive a DHT request. Simply sending a response to the IP we received it from won't (necessarily) work. There's only a single default route, and we may respond from the wrong interface.

Same thing with announcing to trackers, in that case we definitely have to send the announce from the interface we're listening on.

I think the issue in libtorrent that caused initial problem for you is addressed in #8657 though.

[ValdikSS]

Your proposed solution, of defaulting to assume a simple single-homed machine and just binding to INADDR_ANY, has its merits. I don't believe it's quite so simple though, without sacrificing multi-homed support.

I see two main issues:

• Current defaults lead to unexpected results (see below)
• Parameters which are common in other applications (listen on 0.0.0.0) are "overloaded" and does not do exactly what you expect it to do (to listen on 0.0.0.0) — dark pattern

I think the main problem is that it might actually break multi-homed machines.

That's a two-sided issue: on many systems (esp. Windows), proper multihoming is not configured automatically on a system level, or in some cases, can't be properly configured with the regular means at all.
I understand why you implemented it this way, and you did a great job, I appreciate when applications overcome OS or network configuration tools deficiencies and provide better experience.

However my main question is why libtorrent should be fully-multihomed by default to begin with, given this is not a "passive" software like say a web server.

As a power user or a programmer, I expect the application do one thing based on how the OS and all other applications work. Libtorrent claim to do this thing (I instruct it to listen on 0.0.0.0), but instead does completely different thing, and does so by default.
Please rename smart auto-binding to something like auto/auto-ipv4/auto-ipv6 instead of overloading 0.0.0.0/:: meaning.

As a regular user: say I have a laptop with cellular modem, which is connected to the network, with pay-per-gigabyte plan. The laptop is also connected to Wi-Fi. There is a default route over both interfaces; the route over cellular is with higher metric and is not user while the Wi-Fi is connected.
Why the user would want libtorrent to announce itself over cellular modem, and occasionally seed data over it, and pay for it, when Wi-Fi is connected?

Here's the current bug report in qbittorrent tracker: the user is wondering why qbittorrent uses both Wi-Fi and Ethernet (Android USB network sharing) connection when all other applications use only Ethernet: qbittorrent/qBittorrent#24114

The same applies to regular connection and a VPN: many users would want to use only VPN when it is connected and routes everything, and if the application tries to use Ethernet, that would considered as a 'leaking traffic' and is undesirable.

My situation: I've configured a GRE tunnel to my remote VPS on my laptop, started qbittorrent, and libtorrent started to use the tunnel. I figured it out only after I've received DMCA violation email from the DMCA watchdog to my server's IP address.
That would also happen with your patch if I have a default route with higher metric (which is common; right now I have 3 default routes in the system: Ethernet to one network, Wi-Fi to another network, VPN. VPN is the lowest metric).

Simply sending a response to the IP we received it from won't (necessarily) work. There's only a single default route, and we may respond from the wrong interface.

Yes, this is often like this. In many cases it would work for a TCP incoming connection though, and for UDP it's possible to do that with a single socket using IN_PKTINFO (linux, windows), IP_RECVDSTADDR (BSD) + sendmsg/WSASendMsg with the msghdr fields filled from incoming packet, but your solution with bind+SO_BINDTODEVICE is also reliable for the majority of setups (except asymmetric routing).