version 4.2.0 - openSUSE 12.2 x86_64 When the network interface is chosen manually in the network settings, it should remember that setting even if the selected interface doesn't always exist. For example, if ktorrent is forced to use tun0 to operate over VPN and the VPN is taken down, ktorrent will revert to a blank interface choice. It will sometimes also begin operating over the new default interface (ie eth0). Reproducible: Sometimes Steps to Reproduce: 1. activate VPN interface on tun0 2. run ktorrent and choose tun0 in network settings, start a torrent or two 3. shut down VPN optional 4. exit ktorrent and run it again and see if it reactivates torrents over default interface Actual Results: ktorrent sometimes resumes torrent downloads over default interface Expected Results: ktorrent should stay offline until interface selected in network prefs is brought up
I agree with Christopher that this is a bug. It still occurs on ktorrent 4.3.1.
I can confirm this. If the VPN interface doesn't exist when ktorrent starts: * It is ignored, * The "network interface" setting in the "settings" dialog shows blank * The app starts up with whatever the default interface is. This is a real problem when it's important to be using only the correct interface. If the interface is unavailable the app should ideally wait for it, or if that's too much of a re-write, simply failing and exiting would be OK too.
It looks like the culprit is here: ktorrent/core.cpp:109 C++ isn't my best language, but it looks like if the index of the specified interface is "more than" the number of existing interfaces, it's simply ignored. A quick fix would be to replace "SetNetworkInterface(QString::null);" with "wait for interface to become available", however I'm not sure if the code properly handles cases where an interface is added and another is removed. (someone better in C++ than me would need to check it). // Make sure network interface is set properly before server is initialized if (Settings::networkInterface() != 0) { QList<QNetworkInterface> iface_list = QNetworkInterface::allInterfaces(); int iface = Settings::networkInterface(); if (iface > iface_list.count()) SetNetworkInterface(QString::null); else SetNetworkInterface(iface_list[iface - 1].name()); }
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
I can confirm that this bug still exists in KTorrent 5.1.1 (on openSUSE Tumbleweed for x86_64). Steps to reproduce: 1. Set Settings->Configure KTorrent->Network->Network interface to an interface that is not always available (e.g., a VPN tunnel tun0) 2. Shut down tun0 At this point, all torrents stop. This is good. However, any torrents that are subsequently started or restarted (for instance, by manually starting them, or by restarting KTorrent) start transferring using a different network interface. This is bad.
*** Bug 479479 has been marked as a duplicate of this bug. ***