I’m noob at Linux (it just works), so I have no idea how to start troubleshooting this weird issue, any help appreciated!

The setup: stock EndeavourOS, ProtonVPN, qBitTorrent bound to the VPN interface (and Transmission);

the issue: if qBit is running, no matter the load or the server (I have access to P2P-enabled servers), it kills my VPN connection in a matter of minutes, Transmission does not. It is reproducible, launching qBit means getting disconnected, without fail;

the timeline: no issues since I installed EndeavourOS (a year and a half or so), it started happening five to seven days ago, though since a few months ago I would get the same disconnection while qBitting, but only once a day and only while I was away and the system was locked, after I came back to it and reconnect, stable until shutdown. In the months between I haven’t made any changes to my system, just got a new GPU a year ago;

what I tried: I initially though it was a VPN app problem, so I tried reinstalling it, both native and flatpak, after deleting all of its data of course.

Transmission works but I prefer qBit so I’d love to go back to using it.

Where do I start troubleshooting?

I currently can’t be at my PC, so I can’t troubleshoot “live”, but I figured posting this early means more people seeing it and getting more input.

Thanks in advance!

ip link (VPN, no qBit): https://pastebin.com/RtwDqiEN

ip link (VPN, qBit): same identical output (verified with Kate, EndeavourOS text file reader)

journalctl qbit: https://pastebin.com/e2XCgGKy

journalctl PVPN: https://pastebin.com/DiPBvP5W

dmesg: empty for both “torrent” and “proton”

sudo dmesg -l err: virt/tdx: TDX not supported by the host platform

FINGERS CROSSED but it seems that lowering max connections DID fix it, though I’m currently on 20/10/5/4 and it’s limiting. I’ll try upping and see where it lands on, and hopefully that’ll be it.

As per this comment

https://leminal.space/post/41934365/26536143

Proton must have changed something on their end since I used to run qBit with 500 max connections up until the problem started

    • crow@leminal.spaceOP
      1·
      49 minutes ago

      For the most part, I’m not fond of its GUI, the rest is because I’ve been using qBit for, I don’t know, maybe ten or twelve years now

  • ☂️-@lemmy.ml
    2·
    3 hours ago

    never heard of this. super weird.

    can your VPN be used with a generic client (ie. wireguard instead of protonvpn app)? it looks like the app is getting overwhelmed somehow?

    • crow@leminal.spaceOP
      1·
      3 hours ago

      at Brickfrog’s suggestion I crossposted this on the piracy community, and someone did incur in the same issue. Apparently it’s a ProtonVPN DDOS protection, and the fix is lowering the number of max connections, so you’re kind of right, though it’s server-side. I’m now on 20 max global connections and it seems to chug along, for the time being. Now, as to why Transmission worked with 200 max connections, while qBit gets a connection timeout with 150 max, I don’t really know. Though I tried Transmission “as is” without even configuring ports, so that probably lowers the actual number of connections it can establish? I did see lower upload speeds in it, compared to my actual bandwidth and to what I used to see in qBit

      • TrollAccount69@lemmy.ml
        2·
        35 minutes ago

        Transmission wasn’t bound or if bound was going around the port forwarding because it didn’t have the ports configured.

        Airvpn doesn’t have that limit if you’re looking to bypass that problem.

        Also when you’re ready for it, rtorrent is ready for you.

  • morallysuperior@lemmy.ml
    1·
    3 hours ago

    Is this a new problem? My private tracker community is warning everyone to not upgrade to the newest version because it is broken and also has negative effects on the trackers itself.

    • crow@leminal.spaceOP
      1·
      3 hours ago

      Yeah, I read about the new libtorrent version having slower uploads, but I was already on 5.3.0 BEFORE the issue, so that’s not it

  • Brickfrog@lemmy.dbzer0.com
    10·
    7 hours ago

    Just taking a guess: You could try lowering qBittorrent’s total connections and/or bandwidth to see if that helps? I wonder if Transmission is configured for a lower amount vs qBittorrent and somehow the VPN client can’t handle the traffic that qBittorrent pushes through. You could also experiment with disabling DHT & see if that helps - DHT is very useful for public torrenting so disabling it is not ideal but it does generate extra connections.

    You may get better answers in https://lemmy.dbzer0.com/c/piracy there’s probably people with similar setups there that can offer better advice.

    • crow@leminal.spaceOP
      3·
      5 hours ago

      I did try lowering connections (started from 500/200/something/something, went down to 150/20/10/4, this is global max connections/max connections per torrent/max upload slots/max up slots per torrent) but it still kills the VPN.

      Transmission was left untouched and it currently has 200 peers overall and 50 peers per torrent.

      I disabled DHT, testing it!

      Thanks for the help, I’ll also try crossposting there, you never know!

      edit: VPN is still killed with no DHT and/or capped down/up

      • urushitan 漆たん@kakera.kintsugi.moe
        2·
        3 hours ago

        One additional thing to try might be to make sure all outgoing connections are encrypted and you only support encrypted incoming connections, if protonvpn has anything about not using torrents like many vpn services have, they may be watching packets of torrent activity and killing them

  • scutiger@lemmy.world
    6·
    7 hours ago

    A quick search tells me that Proton has servers for P2P. Are you connecting to one of those?

    If that doesn’t help, check if encryption is enabled/forced in both apps. Your traffic may be getting flagged and they may be shutting you down because of it…

    • crow@leminal.spaceOP
      1·
      5 hours ago

      Yes, virtually all servers allow P2P (there are two or three locations that don’t), and I get the same issue regardless of which one I’m connected to.

      Encryption is set to “allow” in qBit and “prefer” in Transmission.

      Thanks!

  • printf("%s", name);@piefed.blahaj.zoneEnglish
    8·
    8 hours ago

    I have never heard of this before. I’m just guessing here, but have you tried binding your qBit client to the VPN interface (tun0 or the likes) from settings? Normally that’s not why you do that, but I wonder if it could somehow force the VPN to stay alive…

    Meanwhile, some more info that people might ask for, with which you may want to edit your post, are the output of:

    • ip link (when VPN is running and when qBit is running)
    • journalctl /usr/bin/qbittorrent (or the location where your qBit is installed)
    • journalctl /usr/bin/[whatever the VPN executable is called] (or the location where your VPN is installed)
    • sudo dmesg | grep -i "torrent"
    • sudo dmesg | grep -i "proton"
    • sudo dmesg -l err
      • printf("%s", name);@piefed.blahaj.zoneEnglish
        2·
        5 hours ago

        Nice! I do wonder whether you initiated/sent this SIGTERM (“close”) or if this is something out of the ordinary… Especially considering that it’s a few minutes after boot. Perhaps when you start Proton and qBit?

        Nov 10 +0h 31:11 HOSTNAME qbittorrent[PID]: QFSFileEngine::open: No file name specified  
Nov 10 +0h 31:11 HOSTNAME qbittorrent[PID]: QFSFileEngine::open: No file name specified  
Nov 10 +0h 38:57 HOSTNAME qbittorrent[PID]: Catching signal: SIGTERM  
Nov 10 +0h 38:57 HOSTNAME qbittorrent[PID]: Exiting cleanly

        What’s actually worrying (without me understanding its implications for qBit specifically) is the segmentation fault:

        Nov 01 +0h 47:18 HOSTNAME qbittorrent[PID]: Caught signal: SIGSEGV

        I was looking for the corresponding timestamps for the above two entries of qBit within the logs of Proton, but Proton’s logs only show logs from the 13th.

        You can disregard the sudo dmesg -l err output for now, because this error pertains to something else.

        Unfortunately I don’t know much more, but maybe somebody with more experience and understands the logs better can help! What I would do is to do a fresh install of qBit to start with. Make sure to save your torrent cache so that you don’t lose your uploads/downloads!

        I’ll get back to you if anything else comes to mind. If you feel up for the task, you could try to find the above mentioned logs of Proton whose timestamps are close to the segfault that qBit reported!

        • crow@leminal.spaceOP
          2·
          4 hours ago

          So, journalctl for the VPN shows nothing for Nov 01 around that time (only what I suppose is normal networking, “sending request - receiving response”). I remember that the qBit client froze at some point and I had to xkill it, though I’m not sure it was so long ago, I think it was less than a week ago. Anyway this is the journalctl for that day, around that time: https://pastebin.com/Y9eXqbgL

          in a few minutes I’ll add the VPN log matching the Nov 10 qBit SIGTERM edit: here it is: https://pastebin.com/Vj9e0a2C

          What I understand from these logs, and also because I noticed it this time, is that once the connection to the VPN server drops, I can NOT reconnect to the same server, not manually nor waiting for the client to do it automatically. I can only connect again to ProtonVPN if I change country

        • crow@leminal.spaceOP
          2·
          5 hours ago

          Nov 10 was three days ago and that’s more or less when this issue started happening. I’ll check the logs again and see if I remember something. I usually don’t close qBit as soon as I boot the system, routine is boot, launch PVPN, connect, launch qBit and I don’t close it ever.

          The Proton log is truncated because it was tens of thousands of lines lol so I had the journalctl print only the last few lines, but, yeah, I can fetch its logs for Nov 10 and Nov 01, I’ll add them asap.

          I was just thinking that I did not try to reinstall qBit and maybe I should do that! Thanks again

        • printf("%s", name);@piefed.blahaj.zoneEnglish
          1·
          5 hours ago

          It also could be worth dumping the whole log to see if there are other things at work here, even if you suspect foul play between qBit and Proton specifically. In that case you would just hit journalctl.

    • crow@leminal.spaceOP
      4·
      9 hours ago

      yes, qBit was always bound to the VPN interface, I’ll add it to the OP.

      thanks for the commands, I’ll see what they return and add everything to the OP as soon as possible