Hi,
I am writing a plugin that creates a thread at plugin-open time. But
when I start ovpn as a daemon the ovpn code has no knowledge of that thread.
The reason is obviously the fact that the thread-creation occurred
*before* the daemon() call (that forked off a child which has no way
of inheritin
Perfect! The following worked:
I defined openvpn_plugin_select_initialization_point_v1() to return
OPENVPN_PLUGIN_INIT_POST_DAEMON and now it all works since the plugin
invocation now gets delayed to be after the daemon thread starts up.
Thanks a lot,
Vineet
On Thu, Jun 24, 2010 at 4:58 AM, chant
Hi,
If my openvpn plugin spawns its own thread and from that thread
wants to kill a tunnel specified by IP:port how can that be done?
(something like what the 'telnet' management provides: "kill IP:port")
This plugin is meant to do other stuff and in certain scenarios wants
to close specific tunn
that this file may be dynamically updated during a client
> session. I assume the main process will pick up the change quick fast.
>
> Chantra
>
>
> On Mon, 2010-12-13 at 15:16 -0800, Vineet Kumar wrote:
>
> Hi,
> If my openvpn plugin spawns its own thread and from that
th
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14/12/10 18:47, Vineet Kumar wrote:
>> Thanks for your response. This seems to involve file I/O and iptables
>> right? File I/O seems like a performance bottleneck, no?
>
> Maybe, if you're still
interactive session is alive my plugin's
telnet session will be ineffective :(
What limits openvpn from not allowing multiple telnet sessions? I can
volunteer to fix that if it the reasons are not big ones.
Thanks,
Vineet
On Tue, Dec 14, 2010 at 11:46 AM, Peter Stuge wrote:
> Vineet Kum
lan to use the same IP:port.
Vineet
On Tue, Dec 14, 2010 at 12:28 PM, Peter Stuge wrote:
> Vineet Kumar wrote:
>> You mean closing the telnet session after every use so that whoever
>> the next guy is gets served?
>
> No I mean creating an intermediary that will know about
Cool, thanks for the clarifications. Will investigate into it.
Vineet
On Tue, Dec 14, 2010 at 2:45 PM, Karl O. Pinc wrote:
> On 12/14/2010 04:22:53 PM, Vineet Kumar wrote:
>> Sorry pl. explain the "intermediary" part. Is that supposed to solve
>> the single telnet
Hi,
Is there a straightforward way to print source IP address and port
given a 'struct context' pointer?
Vineet
That works. Thanks a lot.
Vineet
On Wed, Dec 15, 2010 at 12:56 AM, Gert Doering wrote:
> Hi,
>
> On Tue, Dec 14, 2010 at 03:16:53PM -0800, Vineet Kumar wrote:
>> Is there a straightforward way to print source IP address and port
>> given a 'struct context'
Hi,
Due to the reliability layer wrapping the SSL handshake packets plus
a few non-SSL messages during tunnel-setup time the openvpn protocol
when targeted to port 443 (instead of 1194) ends up breaking if a
proxy sits in the middle and is expecting SSL procol on 443. How can I
get around this (w
gt;
> On 11/03/11 10:04, Gert Doering wrote:
> | Hi,
> |
> | On Thu, Mar 10, 2011 at 05:04:48PM -0800, Vineet Kumar wrote:
> |> Also, doesn't this make openvpn different from other SSL VPNs which
> |> advertise the fact that they are truly SSL?
> |
> | Well, OpenV
f ssl.
>
> A good test of this would be to try something like openssl
> s_client/s_server on each side of the proxy, or netcat with ssl
> support and make sure that if you try and pass non-http traffic
> through it, that the proxy doesn't reject or otherwise molest it.
>
>
Skype breaks too. They also send non-SSL bytes and then SSL.
On Fri, Mar 11, 2011 at 3:17 PM, Jason Haar wrote:
> On 03/12/2011 10:34 AM, Vineet Kumar wrote:
>> BlueCoat's ProxySG is one that runs tranparent SSL protocol detection
>> and breaks if openvpn traffic is coming in
14 matches
Mail list logo
