> >>Thinking ahead, the challenge/response sequence for passing
> >> authentication info should be open-ended to provide for future
> >> implementation of alternative authentication methods such as Radius,
> >> LDAP, NT Auth, etc.
> >
> > Please don't do too much of that. I've seen this auth
James Yonan wrote:
...
Possible client -> server commands:
(1) send auth credentials
(2) get status (as in SIGUSR2)
(3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM)
And server -> client commands:
(1) need auth credentials -- GUI should query the user then return them to the
daemon via
On Saturday 03 July 2004 23:01, James Yonan wrote:
> management 127.0.0.1 20001
>
> This will cause OpenVPN to listen on 127.0.0.1:20001 as its management
> interface port.
>
> It's important, of course, that the management port always be local, since
> we are using it to potentially pass
On Sat, 3 Jul 2004, James Yonan wrote:
There are no hooks as of yet to control a running OpenVPN instance (other
than sending signals).
While I initially thought that named pipes might be the appropriate
channel for this, I'm wondering if if might make more sense (for
portability) to use a
On Sat, 3 Jul 2004, James Yonan wrote:
On Saturday 03 July 2004 15:13, Brandon Knitter wrote:
Where do I start? Are the namedpipe hooks into the OpenVPN service built?
I'm not too familiar with named pipes on Windows (done a bit on *nix), but
I'm sure it can't be too hard. I guess what I'd
Hey there. James and I had a prior discussion about the systray app offline,
but I thought I'd just poke my head in here. I'm not a strong Windows
application programmer, but I've been doing a lot of C# these days.
With that in mind, I was gonna whip together a quickie little systray app in C#
Mathias Sundman wrote:
...
No, I'm not used to OO languages, unfortunally. The reasons why I
started to write this in C was:
1) I only know how to code in C, VisualBasic and Assembler. Assembler is
out of the question, and I'm tired of VBs dependency for a bunch of
DLLs. I like beeing able
> I would furthermore suggest to discuss the required interface between
> the GUI and the OpenVPN daemon on this list. Starting and stopping would
> be possibly by just running the main binary, but I think a more
> sophisticated status and diagnosis interface requires some other
> mechanism (e.g.
