> >>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
On Sat, 3 Jul 2004, Brandon Knitter wrote:
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
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#
