You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After libtorrent added multi-home support, I (like others) noticed that both my real IP and my VPN IP were being announced to trackers. This announce behavior is expected behavior due to libtorrent's implementation, but I'm looking into what interface is used to create outgoing peer connections (not tracker announces) and how that logic works.
Libtorrent uses the interfaces listed in outgoing_interfaces, and creates sockets for peer connections using each such interface in a round-robin fashion. The value passed to libtorrent in outgoing_interfaces is set by qBittorrent, and this is what I wanted to check. When I noticed that multiple IPs were being announced to trackers, I was more or less using qBittorrent out of the box - the network interface was set to the default Any Interface.
From what I can see in configureNetworkInterfaces, the outgoing interfaces are populated from the listening IPs, which are first retrieved via getListeningIPs. In getListeningIPs, networkInterfaceAddress().isEmpty() should be true for the default Any Interface option, as is networkInterface().isEmpty(), so the pair "0.0.0.0" and "::" is returned to configureNetworkInterfaces.
For both of these returned addresses, the instantiated QHostAddress objects shouldn't be empty, so they'll be added to endpoints, but since they're "0.0.0.0" and "[::]", they will not be added to outgoingInterfaces. As a result, the outgoing_interfaces setting passed to libtorrent will be empty, and via libtorrent's logic, the selection of outgoing interface for new peer connections should be delegated to the kernel.
Is my assessment of outgoing_interfaces for the default case correct here?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
After libtorrent added multi-home support, I (like others) noticed that both my real IP and my VPN IP were being announced to trackers. This announce behavior is expected behavior due to libtorrent's implementation, but I'm looking into what interface is used to create outgoing peer connections (not tracker announces) and how that logic works.
Libtorrent uses the interfaces listed in outgoing_interfaces, and creates sockets for peer connections using each such interface in a round-robin fashion. The value passed to libtorrent in outgoing_interfaces is set by qBittorrent, and this is what I wanted to check. When I noticed that multiple IPs were being announced to trackers, I was more or less using qBittorrent out of the box - the network interface was set to the default Any Interface.
From what I can see in configureNetworkInterfaces, the outgoing interfaces are populated from the listening IPs, which are first retrieved via getListeningIPs. In getListeningIPs, networkInterfaceAddress().isEmpty() should be true for the default Any Interface option, as is networkInterface().isEmpty(), so the pair "0.0.0.0" and "::" is returned to configureNetworkInterfaces.
For both of these returned addresses, the instantiated QHostAddress objects shouldn't be empty, so they'll be added to endpoints, but since they're "0.0.0.0" and "[::]", they will not be added to outgoingInterfaces. As a result, the outgoing_interfaces setting passed to libtorrent will be empty, and via libtorrent's logic, the selection of outgoing interface for new peer connections should be delegated to the kernel.
Is my assessment of outgoing_interfaces for the default case correct here?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions