Re: [Openvpn-devel] [PATCH] Windows: do_ifconfig() after open_tun()

2016-06-25 Thread Selva Nair 
On Sat, Jun 25, 2016 at 3:45 AM, Heiko Hund  wrote:

> On Freitag, 24. Juni 2016 19:37:13 CEST Gert Doering wrote:
> > This patch changes the order to IFCONFIG_AFTER_TUN_OPEN, moves some
> > initialization code to init_tun, where it belongs, and removes duplicate
> > code that is now no longer needed.
>
> Yeah, I was skeptic at first, too. But it seems to work. That said, I've
> only
> tested with the interactive service in place. It's the only option how to
> run
> Openvpn in a sane manner on Windows anyways. =)
>
>
True but not yet practical  in some cases. For example, we do not yet have
way to start openvpn using interactive service without using the GUI -- say
run a client or a server (as from an init script). We should do something
about it, but until then testing without interactive service is important
-- easy to do, just run from the command line.

Also, a test against the old tap driver (NDIS 5.x) is in order..

Selva

Re: [Openvpn-devel] [PATCH] Windows: do_ifconfig() after open_tun()

2016-06-25 Thread Heiko Hund 
On Freitag, 24. Juni 2016 19:37:13 CEST Gert Doering wrote:
> This patch changes the order to IFCONFIG_AFTER_TUN_OPEN, moves some
> initialization code to init_tun, where it belongs, and removes duplicate
> code that is now no longer needed.

Yeah, I was skeptic at first, too. But it seems to work. That said, I've only 
tested with the interactive service in place. It's the only option how to run 
Openvpn in a sane manner on Windows anyways. =)

Cheers
Heiko

Re: [Openvpn-devel] brainstorming: t_client system test equivalent for windows?

2016-06-25 Thread Selva Nair 
On Fri, Jun 24, 2016 at 5:23 PM, David Sommerseth  wrote:

> On 24/06/16 19:33, Gert Doering wrote:
> >> > We might also consider if there are possibilities for us to integrate
> >> > such tests with Travis or similar stuff for platforms where that is
> >> > possible.  Often these solutions have Python or Ruby modules
> available too.
> >
> > While totally interesting, how is this going to help with *Windows*
> > testing (which is what this thread is about)?
>
> Having a standardised testing framework makes it possible to run a
> similar set of tests (comparable to what t_client.sh does today) in an
> automated way across multiple platforms, and can report these results to
> a shared hub.  This way we can run automated tests and catch regressions
> which is not caught by our current buildbots ... such as the Windows
> platform.


Python may be better than perl and a cross-platform choice like that may
reduce duplication, but lets not forget the primary objective here, viz.,
 system level testing to catch bugs during development. For windows that
means we should run tests through the management interface (as that's what
the GUI uses), test use of  keystrokes for signals, interactive service
 etc., unlike unix for which all current tests are run through command line
control running with sudo, I suppose. Some bugs show up only when the
management is active (or the other way) and is important to catch those as
the GUI uses the management.

The way I test patches for windows is by manually running a number of
clients with hand-edited configs against a few servers - - one tcp, one udp,
one with user-auth, challenge-response enabled etc. This is indeed painful,
error-prone and never comprehensive enough. Obviously, automated tests
would be of great help, but I do not think a port of the current t_client
scripts  to windows is that useful.

At least in the short-term, a windows-specific perl or python or powershell
or whatever script using the management interface looks like the way to go.
A single cross-platform scripting framework could be a longer-term goal.

Selva