3 minutes ago, sebstrgg said:

If not, do you use any other plugin to achieve the same end goal?

What are you trying to achieve?

Hey all,

 

Getting frustrated trying to get this up.

 

My docker compose is below.  What I am trying to do is only expose the ports needed for the gui and the privoxy via the bridge network then have everything else communicate on the plex-internal network.

 

When I run docker-compose up delugevpn I keep getting this over and over again.  The full debug log with the redactable bits redacted is here https://pastebin.com/1uu1qrKx

 

 

2019-10-23 14:31:41,759 DEBG 'start-script' stdout output:,
Wed Oct 23 14:31:41 2019 write UDP: Operation not permitted (code=1)

 

version: '3.3'
services:
    pms-docker:
      container_name: plex
      networks:
        macvlan-static:
          ipv4_address: 192.168.1.210
        plex-internal:
          ipv4_address: 10.0.3.2
      environment:
          - TZ=America/New_York
          - PLEX_CLAIM=
          - UMASK=002
      volumes:
          - '/mnt/data/plex/config:/config'
          - '/mnt/data/plex/transcode:/transcode'
          - '/mnt/data/plex/data:/data'
          - '/mnt/data/media:/data/media'
      devices:
          - '/dev/dri/card0:/dev/dri/card0'
          - '/dev/dri/renderD128:/dev/dri/renderD128'
      restart: unless-stopped
      image: plexinc/pms-docker

    radarr:
      container_name: hotio-radarr
      networks:
        plex-internal: 
          ipv4_address: 10.0.3.3
      ports:
        - "7878:7878/tcp"
      volumes:
        - '/mnt/data/radarr/config:/config'
        - '/mnt/data:/data'
      environment:
        - TZ=America/New_York
        - UMASK=002
      restart: unless-stopped
      image: hotio/radarr
    
    delugevpn:
      container_name: deluge-openvpn
      networks:
        plex-internal:
          ipv4_address: 10.0.3.5
      ports:
        - "8118:8118/tcp"
        - "8112:8112/tcp"
        # - "58846:58846/tcp"
        # - "58946:58946/tcp"
        # - "58946:58946/udp"
      environment:
        - VPN_ENABLED=yes
        - VPN_USER=
        - VPN_PASS=
        - VPN_PROV=pia
        - STRICT_PORT_FORWARD=yes
        - ENABLE_PRIVOXY=yes
        - LAN_NETWORK=192.168.1.0/24,10.0.3.0/24
        - UMASK=000
        - DELUGE_DAEMON_LOG_LEVEL=debug
        - DELUGE_WEB_LOG_LEVEL=debug
        - DEBUG=true
        # - UPID=0
        # - UGID=0
      volumes:
        - '/etc/localtime:/etc/localtime:ro'
        - '/mnt/data/deluge/data:/data'
        - '/mnt/data/deluge/config:/config'
      cap_add:
        - NET_ADMIN
      restart: unless-stopped
      image: binhex/arch-delugevpn     

networks:
  macvlan-static:
    external: true
  plex-internal:
    external: true

 

23 hours ago, wgstarks said:

What are you trying to achieve?

I'm essentially only trying to achieve what the plugin does - copy a completed file to another folder. Nothing special tbh 

Edited October 23, 20196 yr by sebstrgg

I had Sonarr and Radarr stop communicating with binhex-delugevpn sometime in the past 48 hours.  Could not for the life of me figure it out.  I could not add or search for shows and movies without getting an error.  And testing Deluge as the download client failed.  Then I realized I had both Sonarr and Radarr using the proxy provided by Deluge, Privoxy.  I selected Use Proxy "No" and all the errors went away and Sonarr and Radarr are once again working.  Is the problem with the Privoxy function or is it with PIA?

 

Edit: Also I just now realized all the trackers residing in Jackett were also all erroring out.  Removed proxy info from Jackett and all is well again.  

 

Is something currently wrong with the privoxy function?

 

2nd Edit: Restoring Privoxy appdata from a backup got me functionality back.  Disregard the post.  Seems I may have had some corrupt files.

Edited October 23, 20196 yr by DontWorryScro
additional info

Hey Guys, Just a heads up, I am new to Docker so go easy.

I would like to see if anyone can assist. I have installed Binhex/Arch-deluge VPN on Ubuntu 18.04 and have everything working.

However, when I check the docker logs I get this:

2019-10-22 19:33:00,710 DEBG 'watchdog-script' stderr output:

Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/twisted/internet/base.py", line 1292, in mainLoop
    self.runUntilCurrent()
  File "/usr/lib/python3.7/site-packages/twisted/internet/base.py", line 913, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/usr/lib/python3.7/site-packages/twisted/internet/defer.py", line 460, in callback
    self._startRunCallbacks(result)
  File "/usr/lib/python3.7/site-packages/twisted/internet/defer.py", line 568, in _startRunCallbacks
    self._runCallbacks()
--- <exception caught here> ---
  File "/usr/lib/python3.7/site-packages/twisted/internet/defer.py", line 654, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
  File "/usr/lib/python3.7/site-packages/twisted/internet/task.py", line 866, in <lambda>
    d.addCallback(lambda ignored: callable(*args, **kw))
  File "/usr/lib/python3.7/site-packages/deluge/core/preferencesmanager.py", line 162, in start
    self.do_config_set_func(key, self.config[key])
  File "/usr/lib/python3.7/site-packages/deluge/core/preferencesmanager.py", line 176, in do_config_set_func
    on_set_func(key, value)
  File "/usr/lib/python3.7/site-packages/deluge/core/preferencesmanager.py", line 191, in _on_set_listen_ports
    self.__set_listen_on()
  File "/usr/lib/python3.7/site-packages/deluge/core/preferencesmanager.py", line 229, in __set_listen_on
    for port in range(listen_ports[0], listen_ports[1] + 1)
builtins.TypeError: can only concatenate str (not "int") to str

1. Is this a bug with the Binhex Docker that he may not know about?

2. Is this something I should be worried about - I am no coding expert but it looks like a string can't be concatenated ???

 

Any help is much appreciated.

 

Cheers

 

48 minutes ago, sebstrgg said:

I'm essentially only trying to achieve what the plugin does - copy a completed file to another folder. Nothing special tbh 

Deluge will do this without the plugin as long as you have the path to the folder mapped in the docker. Preferences>Downloads>Move Completed To: <whatever folder>.

On 10/22/2019 at 6:15 PM, binhex said:

that looks fine to me, can you just try starting the troublesome container at the command line, this should tell you whats going on:-

 

docker start <name of my container>

 

Hi binhex,

 

Unfortunately, this does not give a lot of info :

 

Quote

root@MOZART:~# docker start binhex-privoxyvpn
binhex-privoxyvpn
root@MOZART:~#

Any other idea ?

 

For the record :

Quote

I keep failing to get several binhex "vpn dockers" run simultaneously.
 
For example: if i start the binhex-delugevpn docker alone, everything works fine; but as soon as I start e.g. binhex-privoxyvpn or binhex-qbittorrentvpn, then all connections made in binhex-delugevpn die.
 
Please note that all of those dockers are set to use different ports, and that privoxy is set to "no" in binhex-delugevpn and binhex-qbittorrentvpn containers configuration.

Thanks !

G

8 hours ago, wgstarks said:

Deluge will do this without the plugin as long as you have the path to the folder mapped in the docker. Preferences>Downloads>Move Completed To: <whatever folder>.

Yes you're right, but "move" is not the problem, I need to "copy" completed files.

Edited October 24, 20196 yr by sebstrgg

Thanks !
G

Ok well start the other containers as well from the command line until you see an error

Sent from my CLT-L09 using Tapatalk

On 10/11/2019 at 2:18 AM, yeahokay said:

Thanks binhex.

 

How I tested:

On my desktop (windows), connected to my network via wifi, I compared the torrent speed whilst connected to the same vpn server delugevpn is using.

 

I did this by opening up qbitorrent and without touching the ports, compared the speed for the same torrent file I was using to test speeds in delugevpn. (server was off so I wasn't downloading between them).

 

speedtest.net on my server via lan is ~ 95Mbps, on my desktop over wifi it's ~35Mbps

Ubuntu torrent max download speed on my server using delugevpn is currently ~1.2 MiB/s, compared to ~3.0 MiB/s on my desktop (connected via wifi and using the same VPN)

 

I have tested other torrent files as well and they are maxing out at the same speed.

Hi Binhex. I've still not quite managed to make this work perfectly. My deluge speeds appear to be hard limited at 1.1 MiB/s. Theoretically, my connection should be able to sustain speed ~10 times this.

 

The connection appears to saturated at this current level. There is next to no deviation from this speed when a well seeded torrent is added. It feels like there is a bandwidth hard limit set somewhere.

 

I tried changing the Global Bandwidth Limits. Interestingly, this does not affect speeds.

 

Setting a limit at less 300 KiB/s and Deluge still pulls data at my 1.1 MiB/s.

 

I've tried changing these settings through with the docker instance stopped updating core.conf (after removing all backups) and then restarting the instance. I've tried changing through the webUI and the thin client connection. Through each attempt Global bandwidth limits don't seem to affect my speeds.

 

I'm at a bit of a loss on what else I can test. There are no red flags in any of the logs.

 

Any suggestions on what else I could look into would be greatly appreciated!

 

Thanks again for you efforts in producing this and providing ongoing support to the community!

 

A rehash of other troubleshooting I've attempted - I've tried to work through each of the items you've identified in Q6 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

Upload rate set to 3/4 of my theoretical max

GCM cipher used

ItConfig installed. Both enable_incoming_utp and enable_outgoing_utp are disabled.

Rate limit overhead disabled.

VPN endpoint should be ok - I can use a different (windows based) machine on the same network, connect to the same endpoint, and max out my connection (over wifi)

Disk fragmentation not an issue - new disk.

Not writing to an array/using unraid

Router shouldn't be an issue considering over wifi it's faster and it's a top of the line netgear

16 minutes ago, yeahokay said:

A rehash of other troubleshooting I've attempted - I've tried to work through each of the items you've identified in Q6 here: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

thats good you have gone through all the steps for speed issues, sadly though if you have checked them all and still have no improvement then im out of suggestions :-( the only thing i can say is that this is not a limitation of this container, there are people on here reporting 50 MB/s download rates with no issue, so it is possible, but there is something else in play here that is causing you issues.

4 hours ago, binhex said:

Ok well start the other containers as well from the command line until you see an error
 

OK. I stopped all dockers and did this :

Linux 4.19.56-Unraid.
Last login: Wed Oct 23 23:42:59 +0200 2019 on /dev/pts/1.
root@MOZART:~# docker restart binhex-delugevpn
binhex-delugevpn
root@MOZART:~# docker start binhex-privoxyvpn
binhex-privoxyvpn
root@MOZART:~# docker start binhex-qbittorrentvpn
binhex-qbittorrentvpn
root@MOZART:~# 

So now, if I understood correctly, I just wait and see what happens in the console ? Or maybe I need to check the dockers logs ?

Thanks again for your help.

G

10 minutes ago, Opawesome said:

OK. I stopped all dockers and did this :

Linux 4.19.56-Unraid.
Last login: Wed Oct 23 23:42:59 +0200 2019 on /dev/pts/1.
root@MOZART:~# docker restart binhex-delugevpn
binhex-delugevpn
root@MOZART:~# docker start binhex-privoxyvpn
binhex-privoxyvpn
root@MOZART:~# docker start binhex-qbittorrentvpn
binhex-qbittorrentvpn
root@MOZART:~# 

So now, if I understood correctly, I just wait and see what happens in the console ? Or maybe I need to check the dockers logs ?

Thanks again for your help.

G

well you got no errors, so i think thats it, they are all started and you are good to go.

33 minutes ago, binhex said:

well you got no errors, so i think thats it, they are all started and you are good to go.

Haha ! Well, no errors indeed but I still keep failing to get several binhex "vpn dockers" run simultaneously. If I start the binhex-delugevpn docker alone, everything works fine; but as soon as I start the binhex-privoxyvpn or binhex-qbittorrentvpn, then all connections made in binhex-delugevpn die instantly. 😉

40 minutes ago, Opawesome said:

Haha ! Well, no errors indeed but I still keep failing to get several binhex "vpn dockers" run simultaneously. If I start the binhex-delugevpn docker alone, everything works fine; but as soon as I start the binhex-privoxyvpn or binhex-qbittorrentvpn, then all connections made in binhex-delugevpn die instantly. 😉

which vpn provider are you using?

25 minutes ago, binhex said:

which vpn provider are you using?

I use Torguard. I checked and they allow 8 simultaneous connections so I am well below the limit. Do you think it could be on their side ? That would indeed explain the absence of errors reported on the dockers side.

35 minutes ago, Opawesome said:

Do you think it could be on their side ?

it could be yes, very odd how having more than one concurrent connection knocks them all out, im assuming you arent using any vpn apps on mobile devices etc that could be tipping you over the 8 concurrent connection limit?.

28 minutes ago, binhex said:

it could be yes, very odd how having more than one concurrent connection knocks them all out, im assuming you arent using any vpn apps on mobile devices etc that could be tipping you over the 8 concurrent connection limit?.

Yes, I am sure I am below the limit. If you don't have any other idea, I guess the next step would be to subscribe to a second VPN service, set two different containers with two different VPN services and see if the issue persists or not. I'll keep you posted once I found the time to do so.

 

Thank you again for your help @binhex !

Cheers

G

On 10/24/2019 at 6:45 PM, Opawesome said:

I guess the next step would be to subscribe to a second VPN service, set two different containers with two different VPN services and see if the issue persists or not. I'll keep you posted once I found the time to do so.

I did that and do not suffer the disconnection issue. Seems like my VPN provider only allows one connection to a given VPN server from a single IP address (or something similar). Setting up a different VPN server for each binhex docker solved my problem.

 

Thanks again for your guidance @binhex.

Created by...
___. .__ .__
\_ |__ |__| ____ | |__ ____ ___ ___
| __ \| |/ \| | \_/ __ \\ \/ /
| \_\ \ | | \ Y \ ___/ > <
|___ /__|___| /___| /\___ >__/\_ \
\/ \/ \/ \/ \/
https://hub.docker.com/u/binhex/

2019-10-25 17:13:00.590669 [info] System information Linux bfa57bcbfb29 4.19.56-Unraid #1 SMP Thu Jun 27 13:13:13 BST 2019 x86_64 GNU/Linux
2019-10-25 17:13:00.890171 [info] PUID defined as '99'
2019-10-25 17:13:01.153779 [info] PGID defined as '100'
2019-10-25 17:13:02.653070 [info] UMASK defined as '000'
2019-10-25 17:13:02.704820 [info] Permissions already set for volume mappings
2019-10-25 17:13:02.814684 [info] DELUGE_DAEMON_LOG_LEVEL defined as 'info'
2019-10-25 17:13:02.849781 [info] DELUGE_WEB_LOG_LEVEL defined as 'info'
2019-10-25 17:13:02.886115 [info] VPN_ENABLED defined as 'yes'
2019-10-25 17:13:03.258954 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/us4027.nordvpn.com.tcp443.ovpn
2019-10-25 17:13:03.258954 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/us4027.nordvpn.com.tcp443.ovpn
2019-10-25 17:13:03.374224 [info] VPN remote line defined as 'remote 207.189.2.238 443'
2019-10-25 17:13:03.409641 [info] VPN_REMOTE defined as '207.189.2.238'
2019-10-25 17:13:03.445171 [info] VPN_PORT defined as '443'
2019-10-25 17:13:03.483212 [info] VPN_PROTOCOL defined as 'tcp-client'
2019-10-25 17:13:03.517472 [info] VPN_DEVICE_TYPE defined as 'tun0'
2019-10-25 17:13:03.551377 [info] VPN_PROV defined as 'custom'
2019-10-25 17:13:03.585993 [info] LAN_NETWORK defined as '192.168.86.0/24'
2019-10-25 17:13:03.620365 [info] NAME_SERVERS defined as '209.222.18.222,84.200.69.80,37.235.1.174,1.1.1.1,209.222.18.218,37.235.1.177,84.200.70.40,1.0.0.1'
2019-10-25 17:13:03.656347 [info] VPN_USER defined as 'redacted'
2019-10-25 17:13:03.690964 [info] VPN_PASS defined as 'redacted'
2019-10-25 17:13:03.726825 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2019-10-25 17:13:03.763026 [info] ENABLE_PRIVOXY defined as 'yes'
2019-10-25 17:13:03.798628 [info] Starting Supervisor...
2019-10-25 17:13:05,380 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2019-10-25 17:13:05,380 INFO Set uid to user 0 succeeded
2019-10-25 17:13:05,383 INFO supervisord started with pid 6
2019-10-25 17:13:05,380 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2019-10-25 17:13:05,380 INFO Set uid to user 0 succeeded
2019-10-25 17:13:05,383 INFO supervisord started with pid 6
2019-10-25 17:13:06,386 INFO spawned: 'start-script' with pid 151
2019-10-25 17:13:06,387 INFO spawned: 'watchdog-script' with pid 152
2019-10-25 17:13:06,388 INFO reaped unknown pid 7
2019-10-25 17:13:06,423 DEBG 'watchdog-script' stdout output:
[info] Deluge config file doesn't exist, copying default...

2019-10-25 17:13:06,423 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2019-10-25 17:13:06,423 INFO success: watchdog-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2019-10-25 17:13:06,424 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2019-10-25 17:13:06,431 DEBG 'start-script' stdout output:
[warn] Username contains characters which could cause authentication issues, please consider changing this if possible

2019-10-25 17:13:06,434 DEBG 'start-script' stdout output:
[warn] Password contains characters which could cause authentication issues, please consider changing this if possible

2019-10-25 17:13:06,576 DEBG 'start-script' stdout output:
[info] Default route for container is 172.17.0.1

2019-10-25 17:13:06,580 DEBG 'start-script' stdout output:
[info] Adding 209.222.18.222 to /etc/resolv.conf

2019-10-25 17:13:06,583 DEBG 'start-script' stdout output:
[info] Adding 84.200.69.80 to /etc/resolv.conf

2019-10-25 17:13:06,586 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.174 to /etc/resolv.conf

2019-10-25 17:13:06,589 DEBG 'start-script' stdout output:
[info] Adding 1.1.1.1 to /etc/resolv.conf

2019-10-25 17:13:06,593 DEBG 'start-script' stdout output:
[info] Adding 209.222.18.218 to /etc/resolv.conf

2019-10-25 17:13:06,596 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.177 to /etc/resolv.conf

2019-10-25 17:13:06,599 DEBG 'start-script' stdout output:
[info] Adding 84.200.70.40 to /etc/resolv.conf

2019-10-25 17:13:06,602 DEBG 'start-script' stdout output:
[info] Adding 1.0.0.1 to /etc/resolv.conf

2019-10-25 17:13:06,604 DEBG 'start-script' stdout output:
207.189.2.238

2019-10-25 17:13:06,661 DEBG 'start-script' stdout output:
[info] Docker network defined as 172.17.0.0/16

2019-10-25 17:13:06,664 DEBG 'start-script' stdout output:
[info] Adding 192.168.86.0/24 as route via docker eth0

2019-10-25 17:13:06,665 DEBG 'start-script' stdout output:
[info] ip route defined as follows...
--------------------

2019-10-25 17:13:06,666 DEBG 'start-script' stdout output:
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
192.168.86.0/24 via 172.17.0.1 dev eth0

2019-10-25 17:13:06,667 DEBG 'start-script' stdout output:
--------------------

2019-10-25 17:13:06,670 DEBG 'start-script' stdout output:
iptable_mangle 16384 4
ip_tables 24576 9 iptable_filter,iptable_nat,iptable_mangle

2019-10-25 17:13:06,670 DEBG 'start-script' stdout output:
[info] iptable_mangle support detected, adding fwmark for tables

2019-10-25 17:13:06,828 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2019-10-25 17:13:06,830 DEBG 'start-script' stdout output:
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A INPUT -s 192.168.86.0/24 -i eth0 -p tcp -m tcp --dport 58846 -j ACCEPT
-A INPUT -s 192.168.86.0/24 -d 172.17.0.0/16 -i eth0 -p tcp -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 8112 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8112 -j ACCEPT
-A OUTPUT -d 192.168.86.0/24 -o eth0 -p tcp -m tcp --sport 58846 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 192.168.86.0/24 -o eth0 -p tcp -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

2019-10-25 17:13:06,830 DEBG 'start-script' stdout output:
--------------------

2019-10-25 17:13:06,846 DEBG 'start-script' stdout output:
[info] Starting OpenVPN...

2019-10-25 17:13:07,134 DEBG 'start-script' stdout output:
Fri Oct 25 17:13:07 2019 WARNING: file 'credentials.conf' is group or others accessible

Fri Oct 25 17:13:07 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Fri Oct 25 17:13:07 2019 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10

2019-10-25 17:13:07,134 DEBG 'start-script' stdout output:
[info] OpenVPN started

2019-10-25 17:13:07,135 DEBG 'start-script' stdout output:
Fri Oct 25 17:13:07 2019 WARNING: --ping should normally be used with --ping-restart or --ping-exit

Fri Oct 25 17:13:07 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Oct 25 17:13:07 2019 NOTE: --fast-io is disabled since we are not using UDP

2019-10-25 17:13:07,135 DEBG 'start-script' stdout output:
Fri Oct 25 17:13:07 2019 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Oct 25 17:13:07 2019 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

2019-10-25 17:13:07,135 DEBG 'start-script' stdout output:
Fri Oct 25 17:13:07 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]207.189.2.238:443
Fri Oct 25 17:13:07 2019 Socket Buffers: R=[87380->87380] S=[65536->65536]
Fri Oct 25 17:13:07 2019 Attempting to establish TCP connection with [AF_INET]207.189.2.238:443 [nonblock]

2019-10-25 17:15:07,146 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:07 2019 TCP: connect to [AF_INET]207.189.2.238:443 failed: Connection timed out

Fri Oct 25 17:15:07 2019 SIGHUP[connection failed(soft),init_instance] received, process restarting


2019-10-25 17:15:07,147 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:07 2019 WARNING: file 'credentials.conf' is group or others accessible

Fri Oct 25 17:15:07 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Fri Oct 25 17:15:07 2019 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10

2019-10-25 17:15:07,147 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:07 2019 Restart pause, 5 second(s)

2019-10-25 17:15:07,146 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:07 2019 TCP: connect to [AF_INET]207.189.2.238:443 failed: Connection timed out

Fri Oct 25 17:15:07 2019 SIGHUP[connection failed(soft),init_instance] received, process restarting


2019-10-25 17:15:07,147 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:07 2019 WARNING: file 'credentials.conf' is group or others accessible

Fri Oct 25 17:15:07 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Fri Oct 25 17:15:07 2019 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10

2019-10-25 17:15:07,147 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:07 2019 Restart pause, 5 second(s)

2019-10-25 17:15:12,147 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:12 2019 WARNING: --ping should normally be used with --ping-restart or --ping-exit

Fri Oct 25 17:15:12 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Oct 25 17:15:12 2019 NOTE: --fast-io is disabled since we are not using UDP

2019-10-25 17:15:12,147 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:12 2019 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Oct 25 17:15:12 2019 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

2019-10-25 17:15:12,148 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:12 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]207.189.2.238:443
Fri Oct 25 17:15:12 2019 Socket Buffers: R=[87380->87380] S=[65536->65536]
Fri Oct 25 17:15:12 2019 Attempting to establish TCP connection with [AF_INET]207.189.2.238:443 [nonblock]

2019-10-25 17:15:12,147 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:12 2019 WARNING: --ping should normally be used with --ping-restart or --ping-exit

Fri Oct 25 17:15:12 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Oct 25 17:15:12 2019 NOTE: --fast-io is disabled since we are not using UDP

2019-10-25 17:15:12,147 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:12 2019 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Fri Oct 25 17:15:12 2019 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

2019-10-25 17:15:12,148 DEBG 'start-script' stdout output:
Fri Oct 25 17:15:12 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]207.189.2.238:443
Fri Oct 25 17:15:12 2019 Socket Buffers: R=[87380->87380] S=[65536->65536]
Fri Oct 25 17:15:12 2019 Attempting to establish TCP connection with [AF_INET]207.189.2.238:443 [nonblock]

 

Hey all of a sudden my client keeps getting stuck at "Attempting to establish TCP connection" after updating to the latest bits. Ideas?

On 10/25/2019 at 10:22 PM, LumberJackGeek said:

Fri Oct 25 17:15:07 2019 TCP: connect to [AF_INET]207.189.2.238:443 failed: Connection timed out

check your ovpn file, looks like that specific ip address you are attempting to connect to doesnt exist, doesnt support tcp connections, or is having transient issues.

Edited October 28, 20196 yr by binhex

@rinzes @Lipora @Ranzingabon Hagglesmith

I've been away from this project for many months, but today I tried to get it up and running again, on my Synology NAS. And came across the same error you guys mentioned:

/bin/bash: /root/init.sh: No such file or directory

After running through all the code in the GitHub repositories, docker documentation, Google, etc, I almost gave up and did the most desperate thing you could do; search for the mention of /root/init.sh inside all my docker related files on my Synology NAS. And you know what? I messed up during the update. 😅 And I (hope and) think you guys did too. When using the export and import of the settings function in the Docker UI, it also exports the following line in the .json file:

   "cmd" : "/bin/bash /root/init.sh",

Change this to the right line (below) and import the json file again, and you should be good to go!

   "cmd" : "/bin/bash /usr/local/bin/init.sh",

 

@rinzes @Lipora @Ranzingabon Hagglesmith

I've been away from this project for many months, but today I tried to get it up and running again, on my Synology NAS. And came across the same error you guys mentioned:

/bin/bash: /root/init.sh: No such file or directory

After running through all the code in the GitHub repositories, docker documentation, Google, etc, I almost gave up and did the most desperate thing you could do; search for the mention of /root/init.sh inside all my docker related files on my Synology NAS. And you know what? I messed up during the update. [emoji28] And I (hope and) think you guys did too. When using the export and import of the settings function in the Docker UI, it also exports the following line in the .json file:

 

   "cmd" : "/bin/bash /root/init.sh",

Change this to the right line (below) and import the json file again, and you should be good to go!

 

   "cmd" : "/bin/bash /usr/local/bin/init.sh",

 

 

Fantastic that you identified the issue! However I have to say that this shouldn't really be in the JSON file at all, this does not need to and should not be defined for exactly this sort of trip up that has occurred.

 

Sent from my CLT-L09 using Tapatalk

 

 

 

1 hour ago, binhex said:

Fantastic that you identified the issue! However I have to say that this shouldn't really be in the JSON file at all, this does not need to and should not be defined for exactly this sort of trip up that has occurred.

I agree, but what can I say; we are talking about Synology. 🤷‍♂️ I was dumbfounded when they even added Docker support, as they always seem to like to keep things proprietary with little to no option to customize things. I will keep my mouth shut now, as I don't want to jinx it. It's working, that's what matters, right? *coughs*

10 hours ago, blade227 said:

Anybody? This is still happening. Ive tried everything.

Any other issues besides the logs? I'm just guessing here. Take a look at your OpenVPN config file. Do you see a mention of verb? Is it verb 5 or higher? Change it to 4 or lower.

From the OpenVPN documentation on verb 5:
5 — Output R and W characters to the console for each packet read and write, uppercase is used for TCP/UDP packets and lowercase is used for TUN/TAP packets.

 

Edited October 29, 20196 yr by BakedPizza