libtorrent query dns records from the wrong network interface

[Masaiki]

Please provide the following information

libtorrent version (or branch): qbittorrent4.3.9 & libtorrent RC_1_2 https://github.com/arvidn/libtorrent/commit/c05affe19ccbc02ae53434f957ccb15d1e7d3fe0 platform/architecture: windows10 22h2/x64 compiler and compiler version: Visual Studio 2019 v16.11.14 please describe what symptom you see, what you would expect to see instead and how to reproduce it. i have two net interface one is wired NIC, the other is a virtual net interface created by https://github.com/Fndroid/clash_for_windows_pkg using wintun named "clash" dns query from the "clash" with return ip of 198.18.0.1/16 which could only be accessed by "clash" i have specified the wired NIC and all its addresses in qbittorrent now DHT works well with latest commit and all the tracker shows "skipping tracker announce (unreachable)" i guess it get the ip of 198.18.0.1/16 for querying dns records from the wrong network interface

[Masaiki]

if proxy is enabled ( i use socks5 here ), tracker works well, but dht will be down.

[arvidn]

normal APIs to resolve hostnames don't support options to BINDTODEVICE, to make requests over a specific interface. Do you have any other programs that make DNS requests via both interfaces?

[Masaiki]

as far as i know, node could be one (https://github.com/nodejs/node/commit/3e10ce30b471214cc5020a92d628357e9ed4fb91), there may be more on linux platform

[AllSeeingEyeTolledEweSew]

Looks like node internally uses c-ares to support this case. I guess it has a lot of support. Should libtorrent use it?

[Masaiki]

Looks like node internally uses c-ares to support this case. I guess it has a lot of support. Should libtorrent use it?

i agree with this

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.