search

haugene / vpn-configs-contrib

A collection of configs for various VPN providers
GNU General Public License v3.0
188 stars 752 forks source link

PIA - "Tracker gave HTTP response code 0 (No Response)" when trying to use a udp based private tracker #52

Closed MrJamesT closed 3 years ago

MrJamesT commented 3 years ago

Is there a pinned issue for this?

Is there an existing or similar issue for this?

Is there any comment in the documentation for this?

Is this related to a provider?

Are you using the latest release?

Have you tried using the dev branch latest?

Config used

transmission-openvpn: container_name: transmission-openvpn image: haugene/transmission-openvpn cap_add:

Current Behavior

Package works flawlessly with my 3 public trackers but when I try to add a torrent from a udp based private tracker, it doesn't start downloading/seeding. When I looked into the log files, I found this line to be the cause of the issue: Tracker gave HTTP response code 0 (No Response) (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/announcer.c:1085) I tried checking Enable uTP for peer communication but it didn't help. I tested the tracker on my pc with qbitorrent and it works just fine.

Expected Behavior

Would work even with a private udp based tracker.

How have you tried to solve the problem?

  1. Restarted the docker container
  2. Restarted my NAS
  3. Changed the DNS servers from PIA to Cloudflare

Log output

These are the logs after restart, there's something interesting about UDP not working maybe? [2021-09-02 14:36:28.466] Transmission 3.00 (bb6b5a062e) started (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/session.c:769) [2021-09-02 14:36:28.467] RPC Server Adding address to whitelist: 127.0.0.1 (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/rpc-server.c:956) [2021-09-02 14:36:28.467] RPC Server Adding address to whitelist: ::1 (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/rpc-server.c:956) [2021-09-02 14:36:28.467] RPC Server Serving RPC and Web requests on 0.0.0.0:9091/transmission/ (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/rpc-server.c:1243) [2021-09-02 14:36:28.467] Port Forwarding Stopped (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/port-forwarding.c:196) [2021-09-02 14:36:28.467] UDP Failed to set receive buffer: requested 4194304, got 425984 (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/tr-udp.c:97) [2021-09-02 14:36:28.467] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/tr-udp.c:99) [2021-09-02 14:36:28.467] UDP Failed to set send buffer: requested 1048576, got 425984 (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/tr-udp.c:105) [2021-09-02 14:36:28.467] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (/home/buildozer/aports/community/transmission/src/transmission-3.00/libtransmission/tr-udp.c:107)

I've attached one line from the logs in the current behavior part, I've read the other logs thoroughly and they don't appear to contain anything important.

Environment

- OS: Synology DSM 7.0
- Docker: 20.10.3
- VPN Provider: PrivateInternetAccess

Anything else?

No response

MrJamesT commented 3 years ago

A follow-up to this issue, I tried running the docker container on my Windows 10 PC and it seems to work, so this is likely an issue with synology? Although as I've already said, all the public trackers I've tried worked fine. I've attached the logs from my NAS and my PC, which seem really similar apart from this line in the NAS log file: Unable to create session lock file (22): Invalid argument. But I'm pretty sure that has nothing to do with this issue. I guess this issue is already ready to be closed, since it apparently isn't a problem of this package, although I'd greatly appreciate any help solving it. transmission-nas.log transmission-win.log

pkishino commented 3 years ago

have you checked the pinned issue regarding dsm 7 haugene/docker-transmission-openvpn#1839 Seems like synology messed up with a few things..

MrJamesT commented 3 years ago

I have just read it and I don't believe I'm experiencing any of the issues described there, transmission works, vpn works, doesn't seem to be crashing I just can't download via UDP. When I look at transmission settings, it does say the port is open and the log files of the container confirm that, so I really can't tell what the issue might be? Can the port be somehow open only for TCP communication?

pkishino commented 3 years ago

so, either there is some config issue which causes problems for synology or a synology problem directly.. please try running the dev branch and see if this clears it up. Apart from that...

MrJamesT commented 3 years ago

Indeed, I've tried running on the dev branch, it didn't help. I also tried running another docker container with transmission only, that seemed to work, however there I directly port-forwarded like this: 

ports:
  - 9095:9091
  - 51413:51413
  - 51413:51413/udp

Which I cannot do with this package since the port is random on every launch so I guess this is the problem?

pkishino commented 3 years ago

You shouldn’t need to port forward the peer port.. You can set it in the settings to a fixed port if you want,I believe default is not random.

On Fri, Sep 3, 2021 at 22:44 MrJamesT @.***> wrote:

Indeed, I've tried running on the dev branch, it didn't help. I also tried running another docker container with transmission only, that seemed to work, however there I directly port-forwarded like this:

ports:

  • 9095:9091
  • 51413:51413
  • 51413:51413/udp

Which I cannot do with this package since the port is random on every launch so I guess this is the problem?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/haugene/docker-transmission-openvpn/issues/1935#issuecomment-912551495, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7OFYR6CH7RLAJFVKTJCRLUADGNPANCNFSM5DJCCKHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

MrJamesT commented 3 years ago

If I understand the port forwarding process correctly, PIA assigns only one port that can be forwarded when connecting to their servers that is always random so I guess a fixed port isn't possible. I might try switching between host and bridge mode for docker networking as a last resort, but I have really tried everything and still have no idea why it's not working on the NAS (I've tried turning off firewall and so on).

pkishino commented 3 years ago

so, here is the PIA part of this container. https://github.com/haugene/docker-transmission-openvpn/tree/master/openvpn/pia as you can see, one script fetches the configs and the other one sorts out the port.. I don't use PIA and I did not make those scripts, perhaps @gawindx can give some advice? At this point, I suggest you try running using CUSTOM as provider and providing a specific vpn config to use and see if that works?

MrJamesT commented 3 years ago

Ok I think I was going at this wrong, I just realized that the tracker I'm trying to use is using https and none of the other trackers do. So it's probably an https issue, I tried adding CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt because I noticed a certificate error in the logs. The error dissapeared but the issue persisted,

technowhizz commented 3 years ago

+1 I am getting connection failed

Tier 5
pkishino commented 3 years ago

@technowhizz did you PR haugene/vpn-configs-contrib#47 fix this for you? might be something similar for PIA then..

technowhizz commented 3 years ago

@technowhizz did you PR haugene/vpn-configs-contrib#47 fix this for you? might be something similar for PIA then..

Nope. The port change was to get the vpn working in the first place. Without it the vpn wasn't connecting

technowhizz commented 3 years ago

@pkishino the issue is with the docker images not the vpn files?

pkishino commented 3 years ago

well, I can confirm udp works fine on my end at least, different provider though. so I doubt this is is some problem in the container.. it could be that the dns doesn't get set properly by the provider.. so as I wrote in the other issue, check /etc/resolv.conf and try to ping the trackers from inside..if that works and resolv looks fine, then it surely is provider problems

MrJamesT commented 3 years ago

It indeed doesn't seem to be a udp issue nor an issue in the container (works on pc). This is the output I get when I try it on my synology NAS, could this be a firewall issue? image

MrJamesT commented 3 years ago

Ok I seem to have fixed the "Temporary failure in name resolution" issue by removing all containers from the "bridge" docker network and re-adding them back but it still hasn't fixed the main issue somehow, so I'm truly out of ideas...

technowhizz commented 3 years ago

well, I can confirm udp works fine on my end at least, different provider though. so I doubt this is is some problem in the container.. it could be that the dns doesn't get set properly by the provider.. so as I wrote in the other issue, check /etc/resolv.conf and try to ping the trackers from inside..if that works and resolv looks fine, then it surely is provider problems

Thank you!!

I tried a different config file and its now working. Turns out only some purevpn servers support torrenting/p2p

pkishino commented 3 years ago

Can someone please try to reproduce with latest?

MrJamesT commented 3 years ago

I think I tried everything I could the past month when I had the time. It must be a synology issue I can't get to the bottom of. I guess this issue is ready to be closed. When I now try to curl the tracker url from inside the docker container it correctly displays that it successfully established TLS1.3 communication, so I really don't know why I'm still getting response code 0 inside transmission. Maybe if I knew what is in the request and response that transmission is sending / receiving, but it's https communication over a vpn, I really don't know how to decipher that :)

pkishino commented 3 years ago

Hmm, might be worth asking on the transmission dev forum then? I’ll close this for now then