22 hours ago, binhex said:

 

not easily, no, maybe try changing your password on the vpn website, and then change it for this container and see if that kicks it into life, another thought, maybe you have whitespace at the end of the username and/or password, if so remove it.

Ok so I feel kinda stupid right now, after several tries in different os with no issues, i found that the ovpn file from goldenfrog (vypr) and giganews have some differences. Goldenfrog support said this was irrelevant, but apparently not.

After downloading the new ovpn files directly from other sources, everything works as its supposed to with VyprVPN and DelugeVPN docker.

 

So just set custom VPN, user/pass, add ovpn file and certificate, connect and done

 

Hi binhex

 

Thanks a lot for your work.

 

I've been using it successfully since '16, but recently an issue has turned up.

All my torrents stop with a "trackerfix.com: Error: Host not found (authoritative)" error

 

I can see the supervisord.log constantly retry the connection;

 

2018-03-20 09:49:52,350 DEBG 'start-script' stdout output:
Tue Mar 20 09:49:52 2018 TUN/TAP device tun0 opened
Tue Mar 20 09:49:52 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Mar 20 09:49:52 2018 /usr/bin/ip link set dev tun0 up mtu 1500

2018-03-20 09:49:52,351 DEBG 'start-script' stdout output:
Tue Mar 20 09:49:52 2018 /usr/bin/ip addr add dev tun0 100.97.0.63/16 broadcast 100.97.255.255

2018-03-20 09:49:52,351 DEBG 'start-script' stdout output:
Tue Mar 20 09:49:52 2018 /root/openvpnup.sh tun0 1500 1561 100.97.0.63 255.255.0.0 init

2018-03-20 09:49:57,389 DEBG 'start-script' stdout output:
Tue Mar 20 09:49:57 2018 Initialization Sequence Completed

2018-03-20 09:50:02,153 DEBG 'start-script' stdout output:
Tue Mar 20 09:50:02 2018 Authenticate/Decrypt packet error: packet HMAC authentication failed

 

I've tried refreshing the config config files from my vpn provider (tigervpn) without success.

 

The problem seems to come and go, but has now gotten a lot worse and it hasn't worked for days...

 

What debug info would be helpful?

 

1 hour ago, vman81 said:

Hi binhex

 

Thanks a lot for your work.

 

I've been using it successfully since '16, but recently an issue has turned up.

All my torrents stop with a "trackerfix.com: Error: Host not found (authoritative)" error

 

I can see the supervisord.log constantly retry the connection;

 

2018-03-20 09:49:52,350 DEBG 'start-script' stdout output:
Tue Mar 20 09:49:52 2018 TUN/TAP device tun0 opened
Tue Mar 20 09:49:52 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Mar 20 09:49:52 2018 /usr/bin/ip link set dev tun0 up mtu 1500

2018-03-20 09:49:52,351 DEBG 'start-script' stdout output:
Tue Mar 20 09:49:52 2018 /usr/bin/ip addr add dev tun0 100.97.0.63/16 broadcast 100.97.255.255

2018-03-20 09:49:52,351 DEBG 'start-script' stdout output:
Tue Mar 20 09:49:52 2018 /root/openvpnup.sh tun0 1500 1561 100.97.0.63 255.255.0.0 init

2018-03-20 09:49:57,389 DEBG 'start-script' stdout output:
Tue Mar 20 09:49:57 2018 Initialization Sequence Completed

2018-03-20 09:50:02,153 DEBG 'start-script' stdout output:
Tue Mar 20 09:50:02 2018 Authenticate/Decrypt packet error: packet HMAC authentication failed

 

I've tried refreshing the config config files from my vpn provider (tigervpn) without success.

 

The problem seems to come and go, but has now gotten a lot worse and it hasn't worked for days...

 

What debug info would be helpful?

 

 

please follow the procedure in the link below:-

 

https://lime-technology.com/topic/44108-support-binhex-general/?do=findComment&comment=435831

Started having a small issue after the 6.5.0 update.

 

I start DelugeVPN and after a few seconds it starts repeating 

Quote

2018-03-20 22:55:08,820 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 7 from curl != 0
[info] 8 retries left
[info] Retrying in 10 secs...
 

 

1 minute ago, JWMutant said:

Started having a small issue after the 6.5.0 update.

 

I start DelugeVPN and after a few seconds it starts repeating 

 

 

same as previous post.

14 minutes ago, binhex said:

 

same as previous post.

As requested.

 

It looks like pia are using a new api for the port forwarding. https://www.privateinternetaccess.com/forum/discussion/23431/new-pia-port-forwarding-api

supervisord.log

3 minutes ago, JWMutant said:

As requested.

 

It looks like pia are using a new api for the port forwarding. https://www.privateinternetaccess.com/forum/discussion/23431/new-pia-port-forwarding-api

supervisord.log

 

thats old news, i have been htting the new api for nearly a year now, i would say its temporarily down, as per the output on the log suggests:-

 

PIA API currently down, terminating OpenVPN process to force retry for incoming port...

 

only thing you can do is wait and hope it comes back up soon and/or bug pia and tell them their api to assign a incoming port is currently offline.

thanks binhex. Been having the same trouble with PIA.  At least I know its them and not the container.

8 hours ago, munit85 said:

thanks binhex. Been having the same trouble with PIA.  At least I know its them and not the container.

 

you can certainly try another endpoint, it MIGHT be related to certain endpoints (not confirmed), so try netherlands.

Everything has been working for the past months and after i updated the container today (both this container and the binhex-sabnzbdvpn container) it just stopped working. I think it's complaining about it not being able to resolve the VPN address. I have tried different VPN-files, i tried setting googles public DNS as nameservers but i just cannot get it to work again. I've attached the supervisord.log file in hope of assistance.

supervisord.log

 

EDIT: I think i've found the issue. VPN_PORT is set to 194 while it should be set to 1194. Is there a way to force this?

Edited March 21, 20188 yr by peeqi

I still can't connect to deluge with the Thin client. I've searched and searched, but I don't know what I'm doing wrong. Can someone help me out?

 

Firstly I followed this part of the official website. I added a new user (remote) to the /config/auth file:

 

I checked if I could connect with it through deluge-console and if allow_remote is actually enabled:

 

I also checked if the right port (58846) is open, and it is:

 

But it's still not able to connect:

1 hour ago, peeqi said:

Everything has been working for the past months and after i updated the container today (both this container and the binhex-sabnzbdvpn container) it just stopped working. I think it's complaining about it not being able to resolve the VPN address. I have tried different VPN-files, i tried setting googles public DNS as nameservers but i just cannot get it to work again. I've attached the supervisord.log file in hope of assistance.

supervisord.log

 

EDIT: I think i've found the issue. VPN_PORT is set to 194 while it should be set to 1194. Is there a way to force this?

 

hehe i see the problem, you got a comment on the remote line and its getting picked up by the regex, open your ovpn file with something like notepad++ and make the "remote" line look like this:-

remote vpn12.prd.kista.ovpn.com 1194

save and restart the container, do the same for sabnzbdvpn.

1 hour ago, binhex said:

 

hehe i see the problem, you got a comment on the remote line and its getting picked up by the regex, open your ovpn file with something like notepad++ and make the "remote" line look like this:-

remote vpn12.prd.kista.ovpn.com 1194

save and restart the container, do the same for sabnzbdvpn.

 

Thank you, i suspected it was a regex issue That fixed the problem with deluge but not sabnzbd... I removed the comments from both containers and it worked for deluge but not sabnzbd. I've attached the log as well. It keeps waiting for a valid IP address from the tunnel.

supervisord.log

5 minutes ago, peeqi said:

 

Thank you, i suspected it was a regex issue That fixed the problem with deluge but not sabnzbd... I removed the comments from both containers and it worked for deluge but not sabnzbd. I've attached the log as well. It keeps waiting for a valid IP address from the tunnel.

supervisord.log

 

there is nothing wrong with that, you have debug switched on so you will keep seeing the message:-

2018-03-21 16:42:08,410 DEBG 'sabnzbd-script' stdout output:
[debug] Waiting for valid IP address from tunnel...

2018-03-21 16:42:08,527 DEBG 'sabnzbd-script' stdout output:
[debug] Valid IP address from tunnel acquired 'xxxxxxx'

sabnzbd is running too, so no problems from what i can see.

5 hours ago, binhex said:

 

there is nothing wrong with that, you have debug switched on so you will keep seeing the message:-

2018-03-21 16:42:08,410 DEBG 'sabnzbd-script' stdout output:
[debug] Waiting for valid IP address from tunnel...

2018-03-21 16:42:08,527 DEBG 'sabnzbd-script' stdout output:
[debug] Valid IP address from tunnel acquired 'xxxxxxx'

sabnzbd is running too, so no problems from what i can see.

Ah sorry, my previous post was a little vague. I cannot access the web-ui. Neither can sonarr contact sabnzbd.

 

EDIT: To add on this, when i rightclick the sabnzbd docker in the unraid GUI and select the option "webui" it opens 192.168.1.118:8080/#/ and opens guacamole. Is there some redirect issues going on? I've tried rebooting unraid, flush the dns and open the link in incognito but it still opens up the guacamole interface...

 

This is what it looks like if i start the sabnzdb container and open the webui:

Edited March 21, 20188 yr by peeqi

Hehe beat me too it binhex, was writing the same comment when u posted

Love the support and effort you put into your work, keep it up

 

Hi Binhex.

 

My deluge has been running well for probably a year now but this evening it seemed to be acting up (did not seem to connect to the tracker, got errors) and there was an update for it so I updated it and now it won't start.

 

The one error seems to be:

 

Quote

2018-03-21 21:34:34,363 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 7 from curl != 0
[info] 12 retries left
[info] Retrying in 10 secs..

 

The supervisord.log is attached.

 

Thank you for all your work :-)

supervisord_screened.log

Hi Binhex.
 
My deluge has been running well for probably a year now but this evening it seemed to be acting up (did not seem to connect to the tracker, got errors) and there was an update for it so I updated it and now it won't start.
 
The one error seems to be:
 

2018-03-21 21:34:34,363 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 7 from curl != 0
[info] 12 retries left
[info] Retrying in 10 secs..

 
The supervisord.log is attached.
 
Thank you for all your work :-)
supervisord_screened.log
Sweden endpoint is currently unable to connect to pia API in order to allocate a incoming port, switch endpoint to Netherlands for the time being until pia sort their issue.

Sent from my SM-G935F using Tapatalk

I've been on NL from the get go and can't get a port either. Happened in the last day or so.

 

Edited April 9, 20188 yr by Chamzamzoo
log

25 minutes ago, Chamzamzoo said:

I've been on NL from the get go and can't get a port either. Happened in the last day or so.

supervisord.log

 

your log says otherwise:-

 

[debug] Successfully assigned incoming port 35944

 

1 minute ago, binhex said:

 

your log says otherwise:-

 

[debug] Successfully assigned incoming port 35944

 

You're right. I had assumed it was in an error state as it paused my downloads and repeats this message every 30s, it looked like it was retrying for a port.

Downloads are running, but I don't get a PIA IP via the proxy anymore (another thing that led me to believe it was down).

Any ideas?

supervisord.log

9 hours ago, Rourke said:

I still can't connect to deluge with the Thin client. I've searched and searched, but I don't know what I'm doing wrong. Can someone help me out?

 

Firstly I followed this part of the official website. I added a new user (remote) to the /config/auth file:

 

I checked if I could connect with it through deluge-console and if allow_remote is actually enabled:

 

I also checked if the right port (58846) is open, and it is:

 

But it's still not able to connect:

 

A shameless bump. Can someone point me in the right direction?

1 hour ago, ksarnelli said:

Could use some help.  In troubleshooting an issue I had earlier I came to the conclusion that I have no idea how the VPN_REMOTE parameter is supposed to work.  I use PIA as my vpn provider in case that is relevant.

 

According to the official container instructions,

If there are multiple ovpn files then please delete the ones you don't want to use (normally filename follows location of the endpoint) leaving just a single ovpn file and the certificates referenced in the ovpn file (certificates will normally have a crt and/or pem extension).

I should leave only a single .ovpn file.  In doing so, I assumed that the value in VPN_REMOTE parameter would be inserted into the .ovpn file as the host, but this does not seem to be the case.  The host inside the .ovpn file never changes.

 

So then I tried leaving all of the individual .ovpn files in the directory.  With this approach, changing the value in the VPN_REMOTE parameter does sort of work.  If I enter in 'sweden.privateinternetaccess.com' it uses the 'Sweden.ovpn' file, but if I put in 'austria.privateinternetaccess.com' it uses 'AU Melbourne.ovpn' instead of 'Austria.ovpn'.  If I enter 'ireland.privateinternetaccess.com' it uses 'AU Sydney.ovpn'.  the oldest .ovpn file is used.

 

What is the correct way to use the VPN_REMOTE parameter?  Thanks in advance.

 

EDIT - Tested approach two, more, see edits above.

 

The VPN_REMOTE parameter is not used anymore. The container pulls all the info from the .ovpn file. Thus the instruction to only use one ovpn file and delete all others. Put the file you want to use in the openvpn folder along with the crt/pem files. If you want to change endpoint simply replace the ovpn file with another one and restart the container

Edited March 22, 20188 yr by strike

1 hour ago, Chamzamzoo said:

Downloads are running, but I don't get a PIA IP via the proxy anymore (another thing that led me to believe it was down).

Any ideas?

 

Are you on 6.5.0/6.5.1 rc1 by any chance? There is a kernel bug which is affecting some users (including me) in this version. It can cause instability and even crashes some docker containers. If you get call traces in your syslog like this one, it's likely your issue:

 

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
Mar 22 00:23:48 Tower kernel: IP: tcp_push+0x4e/0xee
Mar 22 00:23:48 Tower kernel: PGD 8000000101df7067 P4D 8000000101df7067 PUD 101e37067 PMD 0 
Mar 22 00:23:48 Tower kernel: Oops: 0002 [#4] PREEMPT SMP PTI
Mar 22 00:23:48 Tower kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6table_filter ip6_tables vhost_net vhost tap tun veth xt_nat macvlan ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat xfs nfsd lockd grace sunrpc md_mod e1000e ptp pps_core ipmi_ssif sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 isci crypto_simd glue_helper cryptd i2c_i801 libsas i2c_core hid_logitech_hidpp scsi_transport_sas intel_cstate intel_uncore ahci libahci intel_rapl_perf hid_logitech_dj aacraid wmi ipmi_si button [last unloaded: pps_core]
Mar 22 00:23:48 Tower kernel: CPU: 0 PID: 27975 Comm: privoxy Tainted: G D 4.14.28-unRAID #1
Mar 22 00:23:48 Tower kernel: Hardware name: Supermicro X9SRL-F/X9SRL-F, BIOS 3.2 01/16/2015
Mar 22 00:23:48 Tower kernel: task: ffff8808c3fbe200 task.stack: ffffc90009d14000
Mar 22 00:23:48 Tower kernel: RIP: 0010:tcp_push+0x4e/0xee
Mar 22 00:23:48 Tower kernel: RSP: 0018:ffffc90009d17d30 EFLAGS: 00010246
Mar 22 00:23:48 Tower kernel: RAX: 0000000000000000 RBX: 00000000000005a8 RCX: 0000000000000001
Mar 22 00:23:48 Tower kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88074db4c800
Mar 22 00:23:48 Tower kernel: RBP: ffff8808c3fbeb20 R08: 000000000000fe88 R09: 0000000000000000
Mar 22 00:23:48 Tower kernel: R10: ffff88074db4c958 R11: 0000000000000000 R12: ffff88074db4c800
Mar 22 00:23:48 Tower kernel: R13: 0000000000000000 R14: ffff88070d1cc400 R15: 00000000ffffffe0
Mar 22 00:23:48 Tower kernel: FS: 00001459eef37700(0000) GS:ffff88103f200000(0000) knlGS:0000000000000000
Mar 22 00:23:48 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mar 22 00:23:48 Tower kernel: CR2: 0000000000000038 CR3: 0000000101f2c004 CR4: 00000000000626f0
Mar 22 00:23:48 Tower kernel: Call Trace:
Mar 22 00:23:48 Tower kernel: tcp_sendmsg_locked+0xa53/0xbac
Mar 22 00:23:48 Tower kernel: tcp_sendmsg+0x23/0x35
Mar 22 00:23:48 Tower kernel: sock_sendmsg+0x14/0x1e
Mar 22 00:23:48 Tower kernel: sock_write_iter+0x70/0x86
Mar 22 00:23:48 Tower kernel: __vfs_write+0xe1/0x109
Mar 22 00:23:48 Tower kernel: vfs_write+0xc3/0x166
Mar 22 00:23:48 Tower kernel: SyS_write+0x48/0x81
Mar 22 00:23:48 Tower kernel: do_syscall_64+0x6d/0xfe
Mar 22 00:23:48 Tower kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Mar 22 00:23:48 Tower kernel: RIP: 0033:0x1459f01a58bb
Mar 22 00:23:48 Tower kernel: RSP: 002b:00001459eef332d0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
Mar 22 00:23:48 Tower kernel: RAX: ffffffffffffffda RBX: 00001459eef333f0 RCX: 00001459f01a58bb
Mar 22 00:23:48 Tower kernel: RDX: 0000000000001387 RSI: 00001459eef333f0 RDI: 0000000000000007
Mar 22 00:23:48 Tower kernel: RBP: 0000000000001387 R08: 0000000000000000 R09: 0000000000000000
Mar 22 00:23:48 Tower kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 00001459eef333f0
Mar 22 00:23:48 Tower kernel: R13: 0000000000000000 R14: 00000000004eefab R15: 0000000000000001
Mar 22 00:23:48 Tower kernel: Code: d0 75 02 31 c0 41 89 f3 41 81 e3 00 80 00 00 74 1a 44 8b 8f 68 05 00 00 41 d1 e9 44 2b 8f 6c 06 00 00 44 03 8f 74 06 00 00 79 10 <80> 48 38 08 8b 8f 6c 06 00 00 89 8f 74 06 00 00 40 80 e6 01 74 
Mar 22 00:23:48 Tower kernel: RIP: tcp_push+0x4e/0xee RSP: ffffc90009d17d30
Mar 22 00:23:48 Tower kernel: CR2: 0000000000000038
Mar 22 00:23:48 Tower kernel: ---[ end trace aac96a4aaa1a6d5c ]---

See this thread: 

 

I am new to all this, just setting everything up after building a server, so please bare with me.  I can't get Deluge to work.  I thought I had set it all up right, but I get the following errors:

 

 

In deluge on each download:

 

Status: Permission denied: /downloads/incomplete/ubuntu-17.10.1-server-amd64.iso

Then in the deluge log files:

 

2018-03-21 21:23:22,306 DEBG 'deluge-web-script' stdout output:
[info] Starting Deluge webui...

e":"can not get logs from container which is dead or marked for removal"}
e":"No such container: a5cdf7b73613"}
e":"No such container: a5cdf7b73613"}
e":"No such container: a5cdf7b73613"}

 

What should I look at changing first?

 

Thanks

Edited March 22, 20188 yr by greennick