Jump to content

binhex

Community Developer
  • Content Count

    5693
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by binhex

  1. from your log:- [warn] PIA endpoint 'us-atlanta.privacy.network' is not in the list of endpoints that support port forwarding, DL/UL speeds maybe slow [info] Please consider switching to one of the endpoints shown below so either set STRICT_PORT_FORWARD to 'no' or choose one of the dozens of other endpoints shown in your log that do support port forwarding.
  2. please do this:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md
  3. i think i see the issue @PeterB i will do some testing and if it looks good will release a new image with the fix.
  4. it all looks fine to me, i think the only things you could try that are left are:- 1. restart the container 2. restart the host if neither of these resolve the issue then im afraid im out of ideas, at least for now, all ican say is this image def does work so it must be a config issue somewhere.
  5. yep its simplicity itself!, follow Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md
  6. hmm that does look like a port forwarding related issue, is the port you have forwarded on your router for udp and tcp?, if not try forwarding both protocols. im using pfsense and have tcp and udp for port 19132 open and have no issues connecting internally or over 3G/4G when out and about (once tweaked minecraft PE of course to allow it).
  7. yes, you will only slow things down when using a proxy over a vpn tunnel, its unnecessary.
  8. thats interesting!, so pia have changed things on their end to prevent socks being used for wireguard/openvpn, that makes sense then, i have enhanced Q16 a little so that hopefully the next person will see my 'Note'.
  9. Honestly, I thought it was always the main log on info. I was never aware of ever being able to use the SOCKS credentials... this images has always been based off the pia website credentials, never the socks credentials, but obviously that is up to pia as to what they do or do not accept, perhaps pia now prevent socks credentials being used for wireguard/openvpn authentication? *shrug*, all i can tell you is main website credentials has been working since this image was created.
  10. yes no see Q4 here:- https://github.com/binhex/documentation/blob/master/docker/faq/delugevpn.md
  11. Q16:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
  12. ive seen a couple of people report this but i have been unable to replicate so unsure as to the cause, you could try another endpoint and see if that helps.
  13. if your kernel is older than 5.6.x then yep you are out of luck and will have to stick to openvpn - or join the dark side and use unraid 🙂
  14. yep thats the problem, you are using a tagged version, you need to drop the tag (the colon and everything after it) in order to download the latest image, this will of course mean you will move onto deluge 2.x
  15. then i can only assume you are not running the latest image, what is set for 'repository' for the container?.
  16. not possible to use this guide? - i know you arent using windows but hopefully enough info to get it going:- https://www.privateinternetaccess.com/pages/client-support/windows8.1-l2tp
  17. imminent removal of support for pia legacy network coming guys - i dont think anybody will be crying into their vindaloo here, as its been mostly broken (thanks pia! \s) for some time, but thought it worth a heads up on this.
  18. i would suspect you havent defined VPN_CLIENT correctly, see this post:- https://forums.unraid.net/topic/75539-support-binhex-qbittorrentvpn/?do=findComment&comment=902637
  19. ok i got some good news and some bad news, the good news is ive identified what is causing the setting to be removed, the bad news is that in order to fix this it will break the ability to set the incoming port in qbittorrent :-(. so the problem is caused by the api, as soon as we set the port it resets one/some settings in the web ui, i think this is a bug in qbittorrent so i will raise it as such on their issue board and see what happens, im hoping for a workaround as the only other way to set the incoming port is to kill the qbittorrent process, hack the config file and start qbittorrent - every time the port changes!, not a nice prospect. Issue raised:- https://github.com/qbittorrent/qBittorrent/issues/13585
  20. you are using the old pia legacy network, from your log:- 2020-10-16 11:27:36.341444 [info] VPN remote server(s) defined as 'france.privateinternetaccess.com,' you need to switch to next-gen, see Q19 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
  21. ok i had a poke about and it looks to be saving to the correct location, for instance adding in two trackers writes to the file:- /config/qBittorrent/config/qBittorrent.conf line 9 - Bittorrent\TrackersList=test\ntest2 but as you have correctly identified, if you reboot then this is disabled and the list is shown as empty in the web ui, BUT the config is still present in the config file. So i would def say this is a bug in qbittorrent, most probably a new bug introduced after 4.1, as you said it wasn't present in that version. edit - actually the data DOES disappear from the config file once you have logged in after a restart of the container, no idea why that would happen!. certainly not something i am actively doing in this container.
  22. was that using the web ui or qbittorrent gui?
  23. sorry guys i cant replicate this issue, can you try deleting all files/folders in /config for this container, then restart the container, it should start correctly.
  24. most probably a bug in qbittorrent, they have 2700+ open issues and 51 pull requests at present, so its probably in there somewhere.
  25. yo uare using the legacy pia network, this is broken (by pia), switch to next-gen by following Q19:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md