Jump to content
Not connected, Your IP: 18.191.44.145
AirVPN
Sign in to follow this  
Followers 0
mehāniskākaravīrs935

Recommended Posts

mehāniskākaravīrs935    24

mehāniskākaravīrs935
Posted ...

Hello community, i have been plagued with frequent disconnects from servers over and over again for the past few months, it usually starts after a power failure or unexpected shut down (or if i forget to shut down cleanly). It would seem AirVPN is unable to repair itself like it says it does in the recovery section. I have also submitted tickets to support, but they seem to have no idea what the hell is going on, becuase all they can seem to suggest is making sure my AV isnt blocking my connection, generic common sense solutions that do not seem to apply to my problem (not to bash support but i need a few outside opinions here). Anyway i have a log if any of you guys can make anything of it. Once it reconnects me to a new server the connection appears to be stable, however if i try to reconnect to my original server it crashes yet again. In my case my client seems to always fall back to Canada, which is usually why i don't like seeing or using Canada, too many frustrating memories of OpenVPN crashing. Anyways, any advice you can give would be appreciated, log is below.

 

I 2016.08.10 15:49:01 - AirVPN client version: 2.10.3 / x86, System: Windows, Name: Microsoft Windows NT 6.2.9200.0 / x64
. 2016.08.10 15:49:01 - Reading options from C:\Users\M3CHWARRI0R935\AppData\Local\AirVPN\AirVPN.xml
. 2016.08.10 15:49:03 - Data Path: C:\Users\M3CHWARRI0R935\AppData\Local\AirVPN
. 2016.08.10 15:49:03 - App Path: C:\Program Files (x86)\AirVPN
. 2016.08.10 15:49:03 - Executable Path: C:\Program Files (x86)\AirVPN\AirVPN.exe
. 2016.08.10 15:49:03 - Command line arguments (1): path="home"
. 2016.08.10 15:49:03 - Operating System: Microsoft Windows NT 6.2.9200.0
. 2016.08.10 15:49:03 - Updating systems & servers data ...
. 2016.08.10 15:49:04 - Systems & servers data update completed
I 2016.08.10 15:49:04 - OpenVPN Driver - TAP-Windows Adapter V9, version 9.21.2
I 2016.08.10 15:49:04 - OpenVPN - Version: OpenVPN 2.3.8 (C:\Program Files (x86)\AirVPN\openvpn.exe)
I 2016.08.10 15:49:04 - SSH - Version: plink 0.63 (C:\Program Files (x86)\AirVPN\plink.exe)
I 2016.08.10 15:49:04 - SSL - Version: stunnel 5.17 (C:\Program Files (x86)\AirVPN\stunnel.exe)
! 2016.08.10 15:49:04 - Activation of Network Lock - Windows Firewall
! 2016.08.10 15:49:10 - Ready
I 2016.08.10 15:49:30 - Session starting.
I 2016.08.10 15:49:30 - Network adapter DHCP switched to static (Intel® I211 Gigabit Network Connection)
I 2016.08.10 15:49:34 - IPv6 disabled.
I 2016.08.10 15:49:34 - Checking authorization ...
W 2016.08.10 15:49:34 - Authorization check failed, continue anyway ({1])
! 2016.08.10 15:49:34 - Connecting to Pavonis (United States, Chicago, Illinois)
. 2016.08.10 15:49:34 - OpenVPN > OpenVPN 2.3.8 i686-w64-mingw32 [sSL (OpenSSL)] [LZO] [iPv6] built on Aug 13 2015
. 2016.08.10 15:49:34 - OpenVPN > library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.08
. 2016.08.10 15:49:34 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2016.08.10 15:49:34 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2016.08.10 15:49:34 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 15:49:34 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 15:49:34 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144]
. 2016.08.10 15:49:34 - OpenVPN > Attempting to establish TCP connection with [AF_INET]149.255.33.154:80 [nonblock]
. 2016.08.10 15:49:35 - OpenVPN > TCP connection established with [AF_INET]149.255.33.154:80
. 2016.08.10 15:49:35 - OpenVPN > TCPv4_CLIENT link local: [undef]
. 2016.08.10 15:49:35 - OpenVPN > TCPv4_CLIENT link remote: [AF_INET]149.255.33.154:80
. 2016.08.10 15:49:35 - OpenVPN > TLS: Initial packet from [AF_INET]149.255.33.154:80, sid=500bdef9 5c9f6b6c
. 2016.08.10 15:49:35 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2016.08.10 15:49:35 - OpenVPN > Validating certificate key usage
. 2016.08.10 15:49:35 - OpenVPN > ++ Certificate has key usage  00a0, expects 00a0
. 2016.08.10 15:49:35 - OpenVPN > VERIFY KU OK
. 2016.08.10 15:49:35 - OpenVPN > Validating certificate extended key usage
. 2016.08.10 15:49:35 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2016.08.10 15:49:35 - OpenVPN > VERIFY EKU OK
. 2016.08.10 15:49:35 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2016.08.10 15:49:37 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.10 15:49:37 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 15:49:37 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.10 15:49:37 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 15:49:37 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2016.08.10 15:49:37 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]149.255.33.154:80
. 2016.08.10 15:49:39 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2016.08.10 15:49:39 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.7.0.1,comp-lzo no,route-gateway 10.7.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.0.152 255.255.0.0'
. 2016.08.10 15:49:39 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2016.08.10 15:49:39 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2016.08.10 15:49:39 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2016.08.10 15:49:39 - OpenVPN > OPTIONS IMPORT: route options modified
. 2016.08.10 15:49:39 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2016.08.10 15:49:39 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2016.08.10 15:49:39 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2016.08.10 15:49:39 - OpenVPN > open_tun, tt->ipv6=0
. 2016.08.10 15:49:39 - OpenVPN > TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{56383FD0-CF6B-47B7-9CCC-FCF828A2A063}.tap
. 2016.08.10 15:49:39 - OpenVPN > TAP-Windows Driver Version 9.21
. 2016.08.10 15:49:39 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.7.0.0/10.7.0.152/255.255.0.0 [sUCCEEDED]
. 2016.08.10 15:49:39 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.7.0.152/255.255.0.0 on interface {56383FD0-CF6B-47B7-9CCC-FCF828A2A063} [DHCP-serv: 10.7.255.254, lease-time: 31536000]
. 2016.08.10 15:49:39 - OpenVPN > Successful ARP Flush on interface [7] {56383FD0-CF6B-47B7-9CCC-FCF828A2A063}
. 2016.08.10 15:49:44 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
. 2016.08.10 15:49:44 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 149.255.33.154 MASK 255.255.255.255 192.168.0.1
. 2016.08.10 15:49:44 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
. 2016.08.10 15:49:44 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.08.10 15:49:44 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 15:49:44 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
. 2016.08.10 15:49:44 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.08.10 15:49:44 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 15:49:44 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
. 2016.08.10 15:49:44 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.08.10 15:49:44 - Starting Management Interface
. 2016.08.10 15:49:44 - OpenVPN > Initialization Sequence Completed
I 2016.08.10 15:49:44 - DNS of a network adapter forced (TAP-Windows Adapter V9)
I 2016.08.10 15:49:44 - DNS of a network adapter forced (Intel® I211 Gigabit Network Connection)
I 2016.08.10 15:49:44 - Flushing DNS
I 2016.08.10 15:49:44 - Checking route
I 2016.08.10 15:50:09 - Checking DNS
! 2016.08.10 15:50:21 - Connected.
. 2016.08.10 15:50:21 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2016.08.10 15:50:21 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
. 2016.08.10 16:01:28 - OpenVPN > Connection reset, restarting [-1]
. 2016.08.10 16:01:28 - OpenVPN > SIGUSR1[soft,connection-reset] received, process restarting
. 2016.08.10 16:01:28 - OpenVPN > Restart pause, 5 second(s)
! 2016.08.10 16:01:28 - Disconnecting
. 2016.08.10 16:01:28 - Management - Send 'signal SIGTERM'
. 2016.08.10 16:01:28 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2016.08.10 16:01:28 - OpenVPN > MANAGEMENT: Client disconnected
. 2016.08.10 16:01:28 - OpenVPN > Assertion failed at misc.c:779
. 2016.08.10 16:01:28 - OpenVPN > Exiting due to fatal error
. 2016.08.10 16:01:28 - OpenVpn Management > SUCCESS: signal SIGTERM thrown
. 2016.08.10 16:01:28 - OpenVpn Management > >FATAL:Assertion failed at misc.c:779
. 2016.08.10 16:01:28 - Connection terminated.
I 2016.08.10 16:01:28 - DNS of a network adapter restored to original settings (TAP-Windows Adapter V9)
I 2016.08.10 16:01:28 - DNS of a network adapter restored to original settings (Intel® I211 Gigabit Network Connection)
I 2016.08.10 16:01:31 - Checking authorization ...
! 2016.08.10 16:01:32 - Connecting to Alwaid (Canada, Toronto, Ontario)
. 2016.08.10 16:01:32 - OpenVPN > OpenVPN 2.3.8 i686-w64-mingw32 [sSL (OpenSSL)] [LZO] [iPv6] built on Aug 13 2015
. 2016.08.10 16:01:32 - OpenVPN > library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.08
. 2016.08.10 16:01:32 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2016.08.10 16:01:32 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2016.08.10 16:01:32 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:01:32 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:01:32 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144]
. 2016.08.10 16:01:32 - OpenVPN > Attempting to establish TCP connection with [AF_INET]184.75.221.114:80 [nonblock]
. 2016.08.10 16:01:33 - OpenVPN > TCP connection established with [AF_INET]184.75.221.114:80
. 2016.08.10 16:01:33 - OpenVPN > TCPv4_CLIENT link local: [undef]
. 2016.08.10 16:01:33 - OpenVPN > TCPv4_CLIENT link remote: [AF_INET]184.75.221.114:80
. 2016.08.10 16:01:33 - OpenVPN > TLS: Initial packet from [AF_INET]184.75.221.114:80, sid=27e33004 9c2f9715
. 2016.08.10 16:01:34 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2016.08.10 16:01:34 - OpenVPN > Validating certificate key usage
. 2016.08.10 16:01:34 - OpenVPN > ++ Certificate has key usage  00a0, expects 00a0
. 2016.08.10 16:01:34 - OpenVPN > VERIFY KU OK
. 2016.08.10 16:01:34 - OpenVPN > Validating certificate extended key usage
. 2016.08.10 16:01:34 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2016.08.10 16:01:34 - OpenVPN > VERIFY EKU OK
. 2016.08.10 16:01:34 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2016.08.10 16:01:35 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.10 16:01:35 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:01:35 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.10 16:01:35 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:01:35 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2016.08.10 16:01:35 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]184.75.221.114:80
. 2016.08.10 16:01:38 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2016.08.10 16:01:38 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.7.0.1,comp-lzo no,route-gateway 10.7.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.0.22 255.255.0.0'
. 2016.08.10 16:01:38 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2016.08.10 16:01:38 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2016.08.10 16:01:38 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2016.08.10 16:01:38 - OpenVPN > OPTIONS IMPORT: route options modified
. 2016.08.10 16:01:38 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2016.08.10 16:01:38 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2016.08.10 16:01:38 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2016.08.10 16:01:38 - OpenVPN > open_tun, tt->ipv6=0
. 2016.08.10 16:01:38 - OpenVPN > TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{56383FD0-CF6B-47B7-9CCC-FCF828A2A063}.tap
. 2016.08.10 16:01:38 - OpenVPN > TAP-Windows Driver Version 9.21
. 2016.08.10 16:01:38 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.7.0.0/10.7.0.22/255.255.0.0 [sUCCEEDED]
. 2016.08.10 16:01:38 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.7.0.22/255.255.0.0 on interface {56383FD0-CF6B-47B7-9CCC-FCF828A2A063} [DHCP-serv: 10.7.255.254, lease-time: 31536000]
. 2016.08.10 16:01:38 - OpenVPN > Successful ARP Flush on interface [7] {56383FD0-CF6B-47B7-9CCC-FCF828A2A063}
. 2016.08.10 16:01:43 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
. 2016.08.10 16:01:43 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 184.75.221.114 MASK 255.255.255.255 192.168.0.1
. 2016.08.10 16:01:43 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
. 2016.08.10 16:01:43 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.08.10 16:01:43 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 16:01:43 - OpenVPN > ROUTE: route addition failed using CreateIpForwardEntry: The object already exists.   [status=5010 if_index=7]
. 2016.08.10 16:01:43 - OpenVPN > Route addition via IPAPI failed [adaptive]
. 2016.08.10 16:01:43 - OpenVPN > Route addition fallback to route.exe
. 2016.08.10 16:01:43 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
. 2016.08.10 16:01:43 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 16:01:43 - OpenVPN > ROUTE: route addition failed using CreateIpForwardEntry: The object already exists.   [status=5010 if_index=7]
. 2016.08.10 16:01:43 - OpenVPN > Route addition via IPAPI failed [adaptive]
. 2016.08.10 16:01:43 - OpenVPN > Route addition fallback to route.exe
. 2016.08.10 16:01:43 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
. 2016.08.10 16:01:43 - Starting Management Interface
. 2016.08.10 16:01:43 - OpenVPN > Initialization Sequence Completed
I 2016.08.10 16:01:43 - DNS of a network adapter forced (TAP-Windows Adapter V9)
I 2016.08.10 16:01:43 - DNS of a network adapter forced (Intel® I211 Gigabit Network Connection)
I 2016.08.10 16:01:44 - Flushing DNS
I 2016.08.10 16:01:44 - Checking route
I 2016.08.10 16:02:08 - Checking DNS
! 2016.08.10 16:02:21 - Connected.
. 2016.08.10 16:02:21 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2016.08.10 16:02:21 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
! 2016.08.10 16:02:56 - Disconnecting
. 2016.08.10 16:02:56 - Management - Send 'signal SIGTERM'
. 2016.08.10 16:02:56 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2016.08.10 16:02:56 - OpenVPN > C:\WINDOWS\system32\route.exe DELETE 184.75.221.114 MASK 255.255.255.255 192.168.0.1
. 2016.08.10 16:02:56 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2016.08.10 16:02:56 - OpenVPN > C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 16:02:56 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2016.08.10 16:02:56 - OpenVPN > C:\WINDOWS\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 16:02:56 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2016.08.10 16:02:56 - OpenVPN > Closing TUN/TAP interface
. 2016.08.10 16:02:56 - OpenVPN > SIGTERM[hard,] received, process exiting
. 2016.08.10 16:02:56 - Connection terminated.
I 2016.08.10 16:02:56 - DNS of a network adapter restored to original settings (TAP-Windows Adapter V9)
I 2016.08.10 16:02:56 - DNS of a network adapter restored to original settings (Intel® I211 Gigabit Network Connection)
I 2016.08.10 16:02:59 - Checking authorization ...
! 2016.08.10 16:02:59 - Connecting to Pavonis (United States, Chicago, Illinois)
. 2016.08.10 16:03:00 - OpenVPN > OpenVPN 2.3.8 i686-w64-mingw32 [sSL (OpenSSL)] [LZO] [iPv6] built on Aug 13 2015
. 2016.08.10 16:03:00 - OpenVPN > library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.08
. 2016.08.10 16:03:00 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2016.08.10 16:03:00 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2016.08.10 16:03:00 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:03:00 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:03:00 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144]
. 2016.08.10 16:03:00 - OpenVPN > Attempting to establish TCP connection with [AF_INET]149.255.33.154:80 [nonblock]
. 2016.08.10 16:03:01 - OpenVPN > TCP connection established with [AF_INET]149.255.33.154:80
. 2016.08.10 16:03:01 - OpenVPN > TCPv4_CLIENT link local: [undef]
. 2016.08.10 16:03:01 - OpenVPN > TCPv4_CLIENT link remote: [AF_INET]149.255.33.154:80
. 2016.08.10 16:03:01 - OpenVPN > TLS: Initial packet from [AF_INET]149.255.33.154:80, sid=4c577530 bc5b35eb
. 2016.08.10 16:03:01 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2016.08.10 16:03:01 - OpenVPN > Validating certificate key usage
. 2016.08.10 16:03:01 - OpenVPN > ++ Certificate has key usage  00a0, expects 00a0
. 2016.08.10 16:03:01 - OpenVPN > VERIFY KU OK
. 2016.08.10 16:03:01 - OpenVPN > Validating certificate extended key usage
. 2016.08.10 16:03:01 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2016.08.10 16:03:01 - OpenVPN > VERIFY EKU OK
. 2016.08.10 16:03:01 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2016.08.10 16:03:02 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.10 16:03:02 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:03:02 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.10 16:03:02 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:03:02 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2016.08.10 16:03:02 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]149.255.33.154:80
. 2016.08.10 16:03:05 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2016.08.10 16:03:05 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.7.0.1,comp-lzo no,route-gateway 10.7.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.0.152 255.255.0.0'
. 2016.08.10 16:03:05 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2016.08.10 16:03:05 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2016.08.10 16:03:05 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2016.08.10 16:03:05 - OpenVPN > OPTIONS IMPORT: route options modified
. 2016.08.10 16:03:05 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2016.08.10 16:03:05 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2016.08.10 16:03:05 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2016.08.10 16:03:05 - OpenVPN > open_tun, tt->ipv6=0
. 2016.08.10 16:03:05 - OpenVPN > TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{56383FD0-CF6B-47B7-9CCC-FCF828A2A063}.tap
. 2016.08.10 16:03:05 - OpenVPN > TAP-Windows Driver Version 9.21
. 2016.08.10 16:03:05 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.7.0.0/10.7.0.152/255.255.0.0 [sUCCEEDED]
. 2016.08.10 16:03:05 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.7.0.152/255.255.0.0 on interface {56383FD0-CF6B-47B7-9CCC-FCF828A2A063} [DHCP-serv: 10.7.255.254, lease-time: 31536000]
. 2016.08.10 16:03:05 - OpenVPN > Successful ARP Flush on interface [7] {56383FD0-CF6B-47B7-9CCC-FCF828A2A063}
. 2016.08.10 16:03:10 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
. 2016.08.10 16:03:10 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 149.255.33.154 MASK 255.255.255.255 192.168.0.1
. 2016.08.10 16:03:10 - OpenVPN > ROUTE: route addition failed using CreateIpForwardEntry: The object already exists.   [status=5010 if_index=10]
. 2016.08.10 16:03:10 - OpenVPN > Route addition via IPAPI failed [adaptive]
. 2016.08.10 16:03:10 - OpenVPN > Route addition fallback to route.exe
. 2016.08.10 16:03:10 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
. 2016.08.10 16:03:10 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 16:03:10 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
. 2016.08.10 16:03:10 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.08.10 16:03:10 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 16:03:10 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
. 2016.08.10 16:03:10 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.08.10 16:03:10 - Starting Management Interface
. 2016.08.10 16:03:10 - OpenVPN > Initialization Sequence Completed
I 2016.08.10 16:03:10 - DNS of a network adapter forced (TAP-Windows Adapter V9)
I 2016.08.10 16:03:10 - DNS of a network adapter forced (Intel® I211 Gigabit Network Connection)
I 2016.08.10 16:03:10 - Flushing DNS
I 2016.08.10 16:03:10 - Checking route
I 2016.08.10 16:03:35 - Checking DNS
! 2016.08.10 16:03:47 - Connected.
. 2016.08.10 16:03:47 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
. 2016.08.10 16:03:47 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2016.08.10 16:04:02 - OpenVPN > Connection reset, restarting [-1]
. 2016.08.10 16:04:02 - OpenVPN > SIGUSR1[soft,connection-reset] received, process restarting
. 2016.08.10 16:04:02 - OpenVPN > Restart pause, 5 second(s)
! 2016.08.10 16:04:02 - Disconnecting
. 2016.08.10 16:04:02 - Management - Send 'signal SIGTERM'
. 2016.08.10 16:04:02 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2016.08.10 16:04:02 - OpenVPN > MANAGEMENT: Client disconnected
. 2016.08.10 16:04:02 - OpenVPN > Assertion failed at misc.c:779
. 2016.08.10 16:04:02 - OpenVPN > Exiting due to fatal error
. 2016.08.10 16:04:02 - Connection terminated.
I 2016.08.10 16:04:02 - DNS of a network adapter restored to original settings (TAP-Windows Adapter V9)
I 2016.08.10 16:04:02 - DNS of a network adapter restored to original settings (Intel® I211 Gigabit Network Connection)
I 2016.08.10 16:04:05 - Checking authorization ...
! 2016.08.10 16:04:06 - Connecting to Alwaid (Canada, Toronto, Ontario)
. 2016.08.10 16:04:06 - OpenVPN > OpenVPN 2.3.8 i686-w64-mingw32 [sSL (OpenSSL)] [LZO] [iPv6] built on Aug 13 2015
. 2016.08.10 16:04:06 - OpenVPN > library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.08
. 2016.08.10 16:04:06 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2016.08.10 16:04:06 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2016.08.10 16:04:06 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:04:06 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:04:06 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144]
. 2016.08.10 16:04:06 - OpenVPN > Attempting to establish TCP connection with [AF_INET]184.75.221.114:80 [nonblock]
. 2016.08.10 16:04:07 - OpenVPN > TCP connection established with [AF_INET]184.75.221.114:80
. 2016.08.10 16:04:07 - OpenVPN > TCPv4_CLIENT link local: [undef]
. 2016.08.10 16:04:07 - OpenVPN > TCPv4_CLIENT link remote: [AF_INET]184.75.221.114:80
. 2016.08.10 16:04:07 - OpenVPN > TLS: Initial packet from [AF_INET]184.75.221.114:80, sid=e3bc45f1 4225220f
. 2016.08.10 16:04:07 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2016.08.10 16:04:07 - OpenVPN > Validating certificate key usage
. 2016.08.10 16:04:07 - OpenVPN > ++ Certificate has key usage  00a0, expects 00a0
. 2016.08.10 16:04:07 - OpenVPN > VERIFY KU OK
. 2016.08.10 16:04:07 - OpenVPN > Validating certificate extended key usage
. 2016.08.10 16:04:07 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2016.08.10 16:04:07 - OpenVPN > VERIFY EKU OK
. 2016.08.10 16:04:07 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2016.08.10 16:04:09 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.10 16:04:09 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:04:09 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.10 16:04:09 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.10 16:04:09 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2016.08.10 16:04:09 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]184.75.221.114:80
. 2016.08.10 16:04:11 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2016.08.10 16:04:11 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.7.0.1,comp-lzo no,route-gateway 10.7.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.7.0.22 255.255.0.0'
. 2016.08.10 16:04:11 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2016.08.10 16:04:11 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2016.08.10 16:04:11 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2016.08.10 16:04:11 - OpenVPN > OPTIONS IMPORT: route options modified
. 2016.08.10 16:04:11 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2016.08.10 16:04:11 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2016.08.10 16:04:11 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2016.08.10 16:04:11 - OpenVPN > open_tun, tt->ipv6=0
. 2016.08.10 16:04:11 - OpenVPN > TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{56383FD0-CF6B-47B7-9CCC-FCF828A2A063}.tap
. 2016.08.10 16:04:11 - OpenVPN > TAP-Windows Driver Version 9.21
. 2016.08.10 16:04:11 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.7.0.0/10.7.0.22/255.255.0.0 [sUCCEEDED]
. 2016.08.10 16:04:11 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.7.0.22/255.255.0.0 on interface {56383FD0-CF6B-47B7-9CCC-FCF828A2A063} [DHCP-serv: 10.7.255.254, lease-time: 31536000]
. 2016.08.10 16:04:11 - OpenVPN > Successful ARP Flush on interface [7] {56383FD0-CF6B-47B7-9CCC-FCF828A2A063}
. 2016.08.10 16:04:16 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
. 2016.08.10 16:04:16 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 184.75.221.114 MASK 255.255.255.255 192.168.0.1
. 2016.08.10 16:04:16 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
. 2016.08.10 16:04:16 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2016.08.10 16:04:16 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 16:04:16 - OpenVPN > ROUTE: route addition failed using CreateIpForwardEntry: The object already exists.   [status=5010 if_index=7]
. 2016.08.10 16:04:16 - OpenVPN > Route addition via IPAPI failed [adaptive]
. 2016.08.10 16:04:16 - OpenVPN > Route addition fallback to route.exe
. 2016.08.10 16:04:16 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
. 2016.08.10 16:04:16 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.7.0.1
. 2016.08.10 16:04:16 - OpenVPN > ROUTE: route addition failed using CreateIpForwardEntry: The object already exists.   [status=5010 if_index=7]
. 2016.08.10 16:04:16 - OpenVPN > Route addition via IPAPI failed [adaptive]
. 2016.08.10 16:04:16 - OpenVPN > Route addition fallback to route.exe
. 2016.08.10 16:04:16 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
. 2016.08.10 16:04:16 - Starting Management Interface
. 2016.08.10 16:04:16 - OpenVPN > Initialization Sequence Completed
I 2016.08.10 16:04:16 - DNS of a network adapter forced (TAP-Windows Adapter V9)
I 2016.08.10 16:04:16 - DNS of a network adapter forced (Intel® I211 Gigabit Network Connection)
I 2016.08.10 16:04:16 - Flushing DNS
I 2016.08.10 16:04:16 - Checking route
I 2016.08.10 16:04:41 - Checking DNS
! 2016.08.10 16:04:53 - Connected.
. 2016.08.10 16:04:53 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2016.08.10 16:04:53 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info

Share this post

Link to post

zhang888    1066

zhang888
Posted ...

First of all, you should not blame others for problems that you created on your system, and clearly affect only your specific case.

 

. 2016.08.10 16:02:56 - OpenVPN > SIGTERM[hard,] received, process exiting

 

. 2016.08.10 16:04:02 - Management - Send 'signal SIGTERM'

 

There is a software that kills Eddie without grace on your side, and it causes a known Windows issue of stuck routes.

What you have to do in this case is to disable your network adapters and enable them again, or reboot.

 

If you want a permanent fix for this issue, you should consider a clean Windows installation without 3d party buggy software.

Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.

Share this post

Link to post

mehāniskākaravīrs935    24

mehāniskākaravīrs935
Posted ...

First of all, you should not blame others for problems that you created on your system, and clearly affect only your specific case.

 

. 2016.08.10 16:02:56 - OpenVPN > SIGTERM[hard,] received, process exiting

 

>

. 2016.08.10 16:04:02 - Management - Send 'signal SIGTERM'

 

There is a software that kills Eddie without grace on your side, and it causes a known Windows issue of stuck routes.

What you have to do in this case is to disable your network adapters and enable them again, or reboot.

 

If you want a permanent fix for this issue, you should consider a clean Windows installation without 3d party buggy software.

Also Zhang, i cannot help but notice that in every thread i have participated in or viewed, you always take the blame the customer stance. I'm truly sorry that the power grid in my area shits itself every time a lighting storm comes through and i am not always quick to catch it before i suffer a power failure. But that is absolutely no excuse for my software to be irreparably broken to the point where i need a full OS reinstall, or i am forced to pick through hundreds of my programs for a culprit that probably does not exist.

Share this post

Link to post

zhang888    1066

zhang888
Posted ...

Interesting. Please quote a thread where I blame the customer instead of offering help, out of curiosity.

The power grid has nothing to do with SIGTERM signal sent to the Eddie client, whether you like it or not.

SIGTERM is an abrupt, forced shut down of a software in your system, not a power loss.

 

So once again, please look at the top bar of the website, right now it says 9590 connected users. About

1/3 of them use Eddie on Windows, so there is clearly nothing wrong with the client and/or support.

Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.

Share this post

Link to post

mehāniskākaravīrs935    24

mehāniskākaravīrs935
Posted ...

Interesting. Please quote a thread where I blame the customer instead of offering help, out of curiosity.

The power grid has nothing to do with SIGTERM signal sent to the Eddie client, whether you like it or not.

SIGTERM is an abrupt, forced shut down of a software in your system, not a power loss.

 

So once again, please look at the top bar of the website, right now it says 9590 connected users. About

1/3 of them use Eddie on Windows, so there is clearly nothing wrong with the client and/or support.

Easy, i have one right in this thread "problems that you created on your system"

 

Also, you are attempting to say that Sigterm being thrown is the result of the client not being able to exit cleanly, as the direct result of a power outage which caused my system to lose power. Does not get any clearer than that.

Share this post

Link to post

mehāniskākaravīrs935    24

mehāniskākaravīrs935
Posted ...

Also, you are correct. There are many thousands of other users that are probably doing just fine right now. But i can find several other threads where users were definitely not doing okay. With similar issues i may add.

 

https://airvpn.org/topic/14129-random-disconnects/

 

https://airvpn.org/topic/16411-airvpn-fails-after-5-mins-of-use/

 

https://airvpn.org/topic/12543-question-about-inactivity-timeout/

 

PS: i know your going to say it, but yes the log in particular i provided was not an inactivity timeout, but i had that error in the past as well, and the symptoms are undeniably the same, although the source may not be. as a matter of fact i only fixed the inactivity timeout by switching to TCP from UDP.

Share this post

Link to post

zhang888    1066

zhang888
Posted ...

Where exactly in this whole thread did I blame it on the customer (you) instead of offering help?

This was a reply to a blatant statement from your side that "the support have no idea what the hell is going on".

 

As I said, and as I'm sure the support did as well, the issue resides in a faulty setting of your OS.

 

Also, you are attempting to say that Sigterm being thrown is the result of the client not being able to exit cleanly

 

No, this is not what I said, since this is not how things work.

SIGTERM is actually a signal, not an exception, so it is not caught or thrown, it is what you or other software

send to the process/window of the Eddie client.

In Windows, it's actually called WM_QUIT but for the log purpose it's called SIGTERM, just like in POSIX standards.

What it means that other software, like AV, taskmgr, or others, killed the process without the proper shutdown sequence

in Windows, which is called WM_CLOSE, unlike WM_QUIT, thus letting Windows to handle the changes it made.

 

So no, please don't rephrase what I said with own assumptions, this is not an exception (error/bug), this is an active

signal you sent to the client. Same thing will occur if you simply kill the process and monitor the behavior.

Same thing will also occur in Linux if you send SIGKILL signal (kill -9) without restoring routes, and then

ask the software to add the same route again, without asking the Kernel to delete the old route first.

 

 

The power grid or whatever unrelated reason you thought it might be has absolutely nothing to do with your current issue.

There is a clear indication, from the logs that you posted, that Eddie received a SIGTERM and then you tried to launch it

again. You can blame it on any power grid you want, but this is not the issue you currently experience.

When you kill networking software without grace, especially on Windows, issues like that can happen.

 

Since you said you are not aware of anything that may cause it, the only solution anyone here can offer is a test on a clean OS.

Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.

Share this post

Link to post

mehāniskākaravīrs935    24

mehāniskākaravīrs935
Posted ...

Where exactly in this whole thread did I blame it on the customer (you) instead of offering help?

This was a reply to a blatant statement from your side that "the support have no idea what the hell is going on".

 

As I said, and as I'm sure the support did as well, the issue resides in a faulty setting of your OS.

 

The power grid or whatever unrelated reason you thought it might be has absolutely nothing to do with your current issue.

There is a clear indication, from the logs that you posted, that Eddie received a SIGTERM and then you tried to launch it

again. You can blame it on any power grid you want, but this is not the issue you currently experience.

When you kill networking software without grace, especially on Windows, issues like that can happen.

 

Since you said you are not aware of anything that may cause it, the only solution anyone here can offer is a test on a clean OS.

The client had the issue after i rebooted from a power failure. Those attempts are me trying to fix it after the computer has been restarted from the power failure and i cannot get it to work. And again, simply telling me that there is something wrong on my end just puts me in an endless goose chase. I could spend hundreds of hours going through who knows what just to fix this while you do nothing but argue the circumstances. The bottom line is this: I have a problem with your software and i don't know how to fix it. Can you help or not?

Share this post

Link to post

zhang888    1066

zhang888
Posted ...

The client had the issue after i rebooted from a power failure.

 

The client just reflects the current status of Windows networking stack. If there is an error returned by the OS, the client

is not a magic tool to fix such issues. As I said, you can google how to reset your winsock settings using netsh -

https://support.microsoft.com/en-us/kb/299357

 

 

Those attempts are me trying to fix it after the computer has been restarted from the power failure and i cannot get it to work. And again, simply telling me that there is something wrong on my end just puts me in an endless goose chase.

 

At least you finally agree that the issues are likely to be caused from a failure of power/hardware/software at your end. That's a good progress.

 

I could spend hundreds of hours going through who knows what just to fix this while you do nothing but argue the circumstances.

 

Hundreds of hours is clearly not the time it takes to boot a clean Windows DVD/USB and verify there are no issues with the client.

Nobody is arguing in this thread except you, if you will be so kind to re-check.

Seems like you did not want to accept the fact that the issue is on your side, and there is no known bug in Eddie, at least from the logs

and the description you provided. So instead of saying the support is useless, and people who try to help you are actually blaming you,

I suggest you try focusing on the issue you have without making assumptions.

There are potential issues in Eddie ofcourse, just like in any software, but not when Windows cannot delete existing routes.

 

The bottom line is this: I have a problem with your software and i don't know how to fix it. Can you help or not?

 

You have a problem with your OS, which is Microsoft's software, and the result of this problem is that your VPN client does not work.

If you took the troubleshooting part seriously, you would see that this issue will not occur with clean Windows installation.

 

At this point I'm just going to be repeating myself, so I'm going to unsubscribe from this thread. Good luck.

Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.

Share this post

Link to post

Staff    10014

Staff
Posted ...

The "Bug" in Eddie is that it cannot recover from an unexpected shut down. And there is nothing short of a full OS reinstall to fix it manually. Thats the problem.

 

False. In case of a kill without grace, Eddie restores DNS settings and firewall rules at the next run. Or you can just set your DNS manually and re-set firewall rules. Both these operations take 20-30 seconds. Re-installing a whole Operating System for a 30 seconds job is totally crazy. Thread locked, enough is enough.

Kind regards

RidersoftheStorm reacted to this

Share this post

Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0
Go To Topic Listing
×
×
  • Create New...