No connections established after reconnecting to the network

[blahdy]

after reconnecting to wifi or deactivating-activating Ethernet - dht drops to 0 peers, trackers are unreachable. mostly reproduced on portables that go to sleep often, hence reconnect to wireless upon waking. traced it to these lines, pure trial and error. no idea what the code does and it might be a qbittorrent issue, but they don't care about the mac platform much, so I'll try my luck here.

libtorrent version (or branch): https://github.com/arvidn/libtorrent/commit/88d9c05e3c9fa7388d50554b48f5470a395bd94f#diff-aaf7190ba8a81c1a1fed8eeb605b4c6941a522dd0fd14ac07bdb5f97c2c676a5R248 onwards platform/architecture: qbittorrent on macos 10.14+

[ghost]

This issue is there since libtorrent 1.2.4. https://github.com/arvidn/libtorrent/issues/4412

[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.

[blahdy]

I believe this is a pretty legit issue. Can we please have some feedback?

[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.

[arvidn]

There used to be an issue in boost.asio breaking things after going to sleep and waking up again.

after reconnecting to wifi or deactivating-activating Ethernet - dht drops to 0 peers, trackers are unreachable.

So, going to sleep and waking up, or bringing a NIC down and back up again causes libtorrent to fail every peer- and tracker connection it attempts. Is that right?

mostly reproduced on portables that go to sleep often, hence reconnect to wireless upon waking.

So, it doesn't reproduce reliably. Is that what you mean?

I don't understand what you mean by "hence reconnect to wireless upon waking". That seems to suggest that connections are being made (over WiFi), which would contradict the first sentence.

traced it to these lines, pure trial and error. no idea what the code does and it might be a qbittorrent issue, but they don't care about the mac platform much, so I'll try my luck here.

So, this only happens on Mac OS?

Do you have any logs?

[arvidn]

as far as I can tell, what's happening is that when MacOS notifies applications that its network has changed, it's not done setting up the routes yet. So when libtorrent looks at the networks, none of them can route to the internet (because there is no route yet), and concludes that no interface need to run a DHT node.

[arvidn]

could someone give this a try? https://github.com/arvidn/libtorrent/pull/6338

[blahdy]

sorry for the late reply. it's fixed. thanks!

[ghost]

So this patch fixes the problem only on MacOS. What about linux and windows?

[arvidn]

@an0n666 I think the problem on linux and windows is a different problem. Is there a ticket describing steps to reproduce?

[ghost]

@an0n666 I think the problem on linux and windows is a different problem. Is there a ticket describing steps to reproduce?

Steps to reproduce error on Windows: Method 1 :

• Use a VPN. Listen on that specific VPN interface GUID.
• Disconnect the VPN.
• DHT nodes drop to 0.
• Reconnect VPN.
• DHT nodes stay at 0.

Method 2 :

• Restart the router.
• DHT nodes drop to 0.
• Wait for router to finish restarting and network coming back.
• DHT nodes stay at 0.