Hi,
To your questions below - a more detailed log, below. I connected to server,
then just put Windows in Standby, and then resumed. NSSM restarted openvpn.exe
automatically (as you can see).
Sun Oct 25 13:56:50 2015 MANAGEMENT: >STATE:1445799410,GET_CONFIG,,,
Sun Oct 25 13:56:51 2015 SENT CONTROL [xxxxx]: 'PUSH_REQUEST' (status=1)
Sun Oct 25 13:56:51 2015 PUSH: Received control message: 'PUSH_REPLY,ping
10,ping-restart 120'
Sun Oct 25 13:56:51 2015 OPTIONS IMPORT: timers and/or timeouts modified
Sun Oct 25 13:56:51 2015 open_tun, tt->ipv6=0
Sun Oct 25 13:56:51 2015 TAP-WIN32 device [TAP Adapter] opened:
\\.\Global\{EAE2B369-297C-4181-BA6B-BAEB80DEFC80}.tap
Sun Oct 25 13:56:51 2015 TAP-Windows Driver Version 9.21
Sun Oct 25 13:56:51 2015 Successful ARP Flush on interface [16]
{EAE2B369-297C-4181-BA6B-BAEB80DEFC80}
Sun Oct 25 13:56:56 2015 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=1 u/d=up
Sun Oct 25 13:56:56 2015 MANAGEMENT: >STATE:1445799416,ADD_ROUTES,,,
Sun Oct 25 13:56:56 2015 C:\WINDOWS\system32\route.exe ADD 192.168.1.0 MASK
255.255.255.0 192.168.2.1
Sun Oct 25 13:56:56 2015 ROUTE: CreateIpForwardEntry succeeded with
dwForwardMetric1=64 and dwForwardType=4
Sun Oct 25 13:56:56 2015 Route addition via IPAPI succeeded [adaptive]
Sun Oct 25 13:56:56 2015 Initialization Sequence Completed
Sun Oct 25 13:56:56 2015 MANAGEMENT:
>STATE:1445799416,CONNECTED,SUCCESS,,x.x.x.x
Sun Oct 25 13:57:54 2015 MANAGEMENT: Client disconnected
Sun Oct 25 13:57:54 2015 TUN/TAP I/O operation aborted, exiting
Sun Oct 25 13:57:54 2015 Exiting due to fatal error
Sun Oct 25 13:57:54 2015 C:\WINDOWS\system32\route.exe DELETE 192.168.1.0 MASK
255.255.255.0 192.168.2.1
Sun Oct 25 13:57:54 2015 ROUTE: route deletion failed using
DeleteIpForwardEntry: Element not found.
Sun Oct 25 13:57:54 2015 Route deletion via IPAPI failed [adaptive]
Sun Oct 25 13:57:54 2015 Route deletion fallback to route.exe
Sun Oct 25 13:57:54 2015 env_block: add
PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Sun Oct 25 13:57:54 2015 Closing TUN/TAP interface
Sun Oct 25 13:57:54 2015 OpenVPN 2.3.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO]
[PKCS11] [IPv6] built on Jul 9 2015
Sun Oct 25 13:57:54 2015 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08
Sun Oct 25 13:57:54 2015 MANAGEMENT: TCP Socket listening on
[AF_INET]127.0.0.1:8000
Sun Oct 25 13:57:54 2015 Need hold release from management interface, waiting...
Thanks,
... Russell
-----Original Message-----
From: gert [mailto:g...@delta2.greenie.net]
Sent: Saturday, October 24, 2015 2:20 AM
To: Morris, Russell <rmor...@rkmorris.us>
Cc: Selva Nair <selva.n...@gmail.com>; openvpn-devel@lists.sourceforge.net
Subject: Re: [Openvpn-devel] Creating a Windows team for OpenVPN?
Hi,
On 2015-10-23 22:22, Morris, Russell wrote:
> Just a bit more on this. I initiated an OpenVPN connection – it
> connects, says all is happy, except the output from the management
> interface is,
>
> Ø STATE:1445605521,CONNECTED,ERROR,,10.138.15.10
I'd love to see the openvpn log on this. This message in itself is not
enough to figure out what it did not like.
> And the TAP IP is garbage (169.x.x.x). So I reset the TAP adapter
> (disable),
Well, 169.254.x.x is "I want to do DHCP, but nobody is talking to me" -
so
this is to be expected if OpenVPN is unhappy.
> Ø FATAL:TUN/TAP I/O operation aborted, exiting
>
> OpenVPN exits when TAP is disabled (should it?).
Well. Don't do this :-) - removing an active interface behind the back
of a program talking to it is not a normal situation, and as such,
OpenVPN does the only thing it can: terminate. There is no way to go on
if basic assumptions ("I can talk to my tap adapter") are no longer
valid.
> So there are some stability related issues we may need to correct.
There is a connection issue which needs to be solved, right. But I
would not call it a "stability issue"...
> In particular, if TAP is disabled, should OpenVPN exit?
Yes, because recovering from that would basically mean "undo everything
that has happened in the code so far and start from scratch" (since we
have no idea why the TAP adapter suddenly is no longer working). So
"exit, and let the caller restart us" is the sensible way to achieve
that.
> Perhaps it
> should. But also, after a connection the TAP adapter shouldn’t be
> “hung”, right?
Log :-) - since OpenVPN knows that there is an ERROR, all the details
should be in the openvpn log.
(Restarting openvpn itself without fiddling with the tap adapter will
most likely have the same effect - "make it try again and then it
works")
gert
