Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Arne Schwabe]

I am listing a few requirements that are not discussed before but may
still be important and non obvious. These at least people not involved
with the Android platform a better picture of required changes.
> To allow OpenVPN to be properly refactored afterwards, the important
> part is probably to get the external interfaces correct (which never
> works in practice, but it would be nice to get close...).
>
> The main undecided points regarding the interface side of things appear to be:
> * How to pass the fds back and forth: Special-case the management
>   interface for unix domain sockets or use a dedicated unix domain
>   socket for special operations. Could this potentially be the same
>   interface that was discussed for some of the windows privilege
>   separation approaches?
> * How to call OpenVPN from Java. Via thin JNI wrapper or as a regular
>   executable.
> * The precise names of the newly introduced management commands.

* How to pass routing and other information over the managment
interface. This is important since OpenVpn for Linux needs
ROUTE_AFTER_TUN and IFCONFIG_AFTER_TUN and the Android API needs both
before TUN.
* If the TARGET_ANDROID (or call it TARGET_UNPRIVILEGED_USES_FDPASSING
or something generic) is an extra target or if TARGET_LINUX and
TARGET_ANDROID should one target. This will complicate a lot of things
without refactoring (see the before/after point)
* Openvpn for Android is the first platform which does allow non CIDR
routes (I think). In my port I print a warning in the GUI if I encounter
something stupid like 10.0.0.0 netmask 255.0.255.0. The same goes the
netmask of the ifconfig command.

Arne

P.S.: Sorry for double email, I sent from the wrong email in the first try.

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Fabian Knittel]

Hi,

2012/5/10 David Sommerseth :
> On 10/05/12 16:50, Alon Bar-Lev wrote:
>> Why? plugin is adding a custom logic, and you need custom logic. As
>> I wrote it does not imply that you implement your JNI there.
>
> Okay ... fine ... there are plenty of big visions for a future version
> of OpenVPN, and it will become more modular, yes.  I think we all
> agree there.
>
> What is far more important now is the review the *current* patch, this
> review process have so far derailed completely.  Lets put this current
> discussion aside.  Later on we will discuss this how to modularise
> OpenVPN anyway.

To allow OpenVPN to be properly refactored afterwards, the important
part is probably to get the external interfaces correct (which never
works in practice, but it would be nice to get close...).

The main undecided points regarding the interface side of things appear to be:
* How to pass the fds back and forth: Special-case the management
  interface for unix domain sockets or use a dedicated unix domain
  socket for special operations. Could this potentially be the same
  interface that was discussed for some of the windows privilege
  separation approaches?
* How to call OpenVPN from Java. Via thin JNI wrapper or as a regular
  executable.
* The precise names of the newly introduced management commands.

Anything else?

Cheers
Fabian

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

On Thu, May 10, 2012 at 6:20 PM, Alon Bar-Lev  wrote:
> On Thu, May 10, 2012 at 6:17 PM, David Sommerseth
>  wrote:
>> Development is all about iterations.  Let's see what we can do NOW to
>> get Arne's approach reviewed properly, see if there are things which
>> can be do to simplify the future somewhat ... but don't make this
>> depend on a complete modularisation of OpenVPN first.
>
> There is nothing wrong in maintaining external patches until upstream
> properly merged the change.
> I've been maintaining such patches for years, with user base that was happy.
> What's the rush? if users wants a solution they have it ready.
>
> Alon.

Can you please remind me how much time the android kernel patches were
maintained outside of mainline?
And why?

Alon.

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

On Thu, May 10, 2012 at 6:17 PM, David Sommerseth
 wrote:
> Development is all about iterations.  Let's see what we can do NOW to
> get Arne's approach reviewed properly, see if there are things which
> can be do to simplify the future somewhat ... but don't make this
> depend on a complete modularisation of OpenVPN first.

There is nothing wrong in maintaining external patches until upstream
properly merged the change.
I've been maintaining such patches for years, with user base that was happy.
What's the rush? if users wants a solution they have it ready.

Alon.

Re: [Openvpn-devel] Some issues with openvpn-build/windows-nsis

[Alon Bar-Lev]

On Thu, May 10, 2012 at 3:53 PM, Samuli Seppänen  wrote:
>
>> On Thu, May 10, 2012 at 3:11 PM, Samuli Seppänen  wrote:
>>> Hi,
>>>
>>> I tried to generate a Windows installer on Ubuntu 11.10 amd64, but ran
>>> into some issues:
>>>
>>> $ cd openvpn-build/windows-nsis
>>> $ ./build-snapshot
>>> --- snip ---
>>>
>>> make[3]: Leaving directory
>>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>>> make[2]: Leaving directory
>>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>>> make[1]: Leaving directory
>>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>>> tap-windows
>>> Fixup libtool files
>>> Restore libtool files
>>> ls: cannot access tmp/image-i686/openvpn-i686-*-bin.*: No such file or
>>> directory
>>>
>>> The error message seems clear enough, but I'm wondering why the binaries
>>> are not where it looks for them:
>>>
>>> $ ls tmp/image-i686
>>> openvpn
>>> $ ls tmp/image-i686/openvpn
>>> bin  etc  include  lib  share
>> This is strange, as you referred to dash, which I never tested, I will
>> try and see if that is the problem.
>>
>> Alon.
> What I know is that if I work around this problem, I get a shell syntax
> error later on... and if I switch #!/bin/sh to #!/bin/bash in
> "build-snapshot", that syntax error goes away. To be more precise, the
> error occurs at openvpn-build/windows-nsis/build:5, which is
>
>   ROOT="${ROOT:-tmp}"
>
> I don't have full logs at hand right now, unfortunately.

No the problem was in much later phase... dash does not support ${XXX//} syntax.
Fixed now.
Can you please try again?

Thanks!
Alon.

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/12 16:50, Alon Bar-Lev wrote:
> On Thu, May 10, 2012 at 5:43 PM, Adriaan de Jong
>  wrote:
>>> -Original Message- From: Alon Bar-Lev
>>> [mailto:alon.bar...@gmail.com] Sent: donderdag 10 mei 2012
>>> 16:33 To: Mendelt Siebenga Cc:
>>> openvpn-devel@lists.sourceforge.net Subject: Re:
>>> [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
>>> 
>>> Hello Mendelt,
>>> 
>>> Thank you for taking the time to explain the process, now at
>>> least I can comment better.
>>> 
>>> On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga 
>>>  wrote: 
>>> 
 Android has a lot of limitations on how you can get access to
 a TUN
>>> device without rooting your phone. Basically what you need to
>>> do is:
 - Pass a file descriptor of the socket used by OpenVPN to a
 system
>>> call to protect it. This prevents traffic to this socket being
>>> routed over the vpn itself.
 - Pass all routing information, dns servers etc. To a system
 call.
>>> This call sets up routing and returns a file descriptor to the
>>> TUN device.
>>> 
>>> This is new! So you need the complete IP and routing settings
>>> *BEFORE* you open the tun, this was not clear from the
>>> discussion.
>>> 
>>> 
>>> 
 I'm not really sure about putting these changes off into a
 separate
>>> plugin. I personally like to modularize code as much as
>>> possible, but my guess is that in this case adding the hooks to
>>> the plugin interface that are necessary to allow this
>>> functionality to be implemented as a plugin will add more
>>> clutter to OpenVPN than just adding them to the core. I'm not
>>> sure what the plans are for the plugin interface but I can
>>> imagine that if it becomes more powerful over time we might be
>>> able to spin off these changes as a separate plugin later.
>>> 
>>> This is exactly what I am afraid of, merge now monolithic code
>>> in a hope that in future someone will clean up the mess. To be
>>> able to provide a solution now to users an external patch may
>>> be used, nothing wrong with this.
>>> 
>>> I prefer to work a little harder and implement the modular 
>>> infrastructure required to support this scenario and other that
>>> may exist, this without breaking assumptions, such as
>>> management interface can be TCP connection.
>>> 
>>> So what I recommend extending the tun engine interface I
>>> recently implemented[1] for 2.4, and add an engine to delegate
>>> calls to the openvpn plugin framework, the tun engine interface
>>> already supports opening the tun, configuring the tun etc...
>>> maybe minor changes are required, I will be happy to work on
>>> this.
>>> 
>>> We also add an option for a plugin to use the management
>>> interface and expose something like: plugin  command.
>>> 
>>> Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain
>>> socket in addition to the management interface and put its
>>> number in environment ANDROID_CONTROL_FD=XXX.
>>> 
>>> A special android plugin will be loaded which register to the
>>> tun engine notifications, it will be able to interact with the
>>> UI via the management interface, but for two special tasks it
>>> will use the custom unix domain control fd in addition, for
>>> example via the management interface it will forward the
>>> network details, then ask for tun fd, and will get the fd via
>>> the control channel.
>>> 
>>> This way you will be able to maintain the android custom code
>>> as a whole, while the openvpn project will benefit from the
>>> ability to expose all plugins via the management interface for
>>> any task and be able to perform routing and networking setting
>>> via plugin (which was also discussed for privilege separation
>>> model).
>>> 
>>> Alon.
>>> 
>>> [1] https://github.com/alonbl/openvpn/compare/master...tun
>>> 
>> 
>> Basically, what you're asking is that a reasonably simple patch
>> is extended into a revamp of the management system. While I agree
>> that more modularisation is important for OpenVPN, stopping all
>> progress and killing off a useful feature is not the way to
>> achieve that. Shall we agree to discuss the technical merits of
>> the patch, and not the grand vision of how OpenVPN should look?
>> Don't throw out the good for the perfect :).
> 
> I wrote that I will help to make it true, and already shown the
> major work done in this direction.
> 
> Anyway your argument may be heard from everyone who try to add any 
> change to any software, yes, I need just this simple change...
> this probably not wise, as sooner or later you have unmaintainable 
> software, which is lose-lose solution.
> 
>> Modularisation work is planned for 2.4, and adding a
>> management-interface controlled tun module would be a great idea
>> there. I still disagree on using the plugin interface for that. A
>> modularised system is fine there.
> 
> Why? plugin is adding a custom logic, and you need custom logic. As
> I wrote it does not imply that you implem

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

On Thu, May 10, 2012 at 5:43 PM, Adriaan de Jong  wrote:
>> -Original Message-
>> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> Sent: donderdag 10 mei 2012 16:33
>> To: Mendelt Siebenga
>> Cc: openvpn-devel@lists.sourceforge.net
>> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
>>
>> Hello Mendelt,
>>
>> Thank you for taking the time to explain the process, now at least I
>> can comment better.
>>
>> On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga
>>  wrote:
>> 
>>
>> > Android has a lot of limitations on how you can get access to a TUN
>> device without rooting your phone. Basically what you need to do is:
>> > - Pass a file descriptor of the socket used by OpenVPN to a system
>> call to protect it. This prevents traffic to this socket being routed
>> over the vpn itself.
>> > - Pass all routing information, dns servers etc. To a system call.
>> This call sets up routing and returns a file descriptor to the TUN
>> device.
>>
>> This is new!
>> So you need the complete IP and routing settings *BEFORE* you open the
>> tun, this was not clear from the discussion.
>>
>> 
>>
>> > I'm not really sure about putting these changes off into a separate
>> plugin. I personally like to modularize code as much as possible, but
>> my guess is that in this case adding the hooks to the plugin interface
>> that are necessary to allow this functionality to be implemented as a
>> plugin will add more clutter to OpenVPN than just adding them to the
>> core. I'm not sure what the plans are for the plugin interface but I
>> can imagine that if it becomes more powerful over time we might be able
>> to spin off these changes as a separate plugin later.
>>
>> This is exactly what I am afraid of, merge now monolithic code in a
>> hope that in future someone will clean up the mess. To be able to
>> provide a solution now to users an external patch may be used, nothing
>> wrong with this.
>>
>> I prefer to work a little harder and implement the modular
>> infrastructure required to support this scenario and other that may
>> exist, this without breaking assumptions, such as management interface
>> can be TCP connection.
>>
>> So what I recommend extending the tun engine interface I recently
>> implemented[1] for 2.4, and add an engine to delegate calls to the
>> openvpn plugin framework, the tun engine interface already supports
>> opening the tun, configuring the tun etc... maybe minor changes are
>> required, I will be happy to work on this.
>>
>> We also add an option for a plugin to use the management interface and
>> expose something like: plugin  command.
>>
>> Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain socket
>> in addition to the management interface and put its number in
>> environment ANDROID_CONTROL_FD=XXX.
>>
>> A special android plugin will be loaded which register to the tun
>> engine notifications, it will be able to interact with the UI via the
>> management interface, but for two special tasks it will use the custom
>> unix domain control fd in addition, for example via the management
>> interface it will forward the network details, then ask for tun fd, and
>> will get the fd via the control channel.
>>
>> This way you will be able to maintain the android custom code as a
>> whole, while the openvpn project will benefit from the ability to
>> expose all plugins via the management interface for any task and be
>> able to perform routing and networking setting via plugin (which was
>> also discussed for privilege separation model).
>>
>> Alon.
>>
>> [1] https://github.com/alonbl/openvpn/compare/master...tun
>>
>
> Basically, what you're asking is that a reasonably simple patch is extended 
> into a revamp of the management system. While I agree that more 
> modularisation is important for OpenVPN, stopping all progress and killing 
> off a useful feature is not the way to achieve that. Shall we agree to 
> discuss the technical merits of the patch, and not the grand vision of how 
> OpenVPN should look? Don't throw out the good for the perfect :).

I wrote that I will help to make it true, and already shown the major
work done in this direction.

Anyway your argument may be heard from everyone who try to add any
change to any software, yes, I need just this simple change... this
probably not wise, as sooner or later you have unmaintainable
software, which is lose-lose solution.

> Modularisation work is planned for 2.4, and adding a management-interface 
> controlled tun module would be a great idea there. I still disagree on using 
> the plugin interface for that. A modularised system is fine there.

Why? plugin is adding a custom logic, and you need custom logic.
As I wrote it does not imply that you implement your JNI there.

Alon.

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Adriaan de Jong]

> -Original Message-
> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> Sent: donderdag 10 mei 2012 16:33
> To: Mendelt Siebenga
> Cc: openvpn-devel@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
> 
> Hello Mendelt,
> 
> Thank you for taking the time to explain the process, now at least I
> can comment better.
> 
> On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga
>  wrote:
> 
> 
> > Android has a lot of limitations on how you can get access to a TUN
> device without rooting your phone. Basically what you need to do is:
> > - Pass a file descriptor of the socket used by OpenVPN to a system
> call to protect it. This prevents traffic to this socket being routed
> over the vpn itself.
> > - Pass all routing information, dns servers etc. To a system call.
> This call sets up routing and returns a file descriptor to the TUN
> device.
> 
> This is new!
> So you need the complete IP and routing settings *BEFORE* you open the
> tun, this was not clear from the discussion.
> 
> 
> 
> > I'm not really sure about putting these changes off into a separate
> plugin. I personally like to modularize code as much as possible, but
> my guess is that in this case adding the hooks to the plugin interface
> that are necessary to allow this functionality to be implemented as a
> plugin will add more clutter to OpenVPN than just adding them to the
> core. I'm not sure what the plans are for the plugin interface but I
> can imagine that if it becomes more powerful over time we might be able
> to spin off these changes as a separate plugin later.
> 
> This is exactly what I am afraid of, merge now monolithic code in a
> hope that in future someone will clean up the mess. To be able to
> provide a solution now to users an external patch may be used, nothing
> wrong with this.
> 
> I prefer to work a little harder and implement the modular
> infrastructure required to support this scenario and other that may
> exist, this without breaking assumptions, such as management interface
> can be TCP connection.
> 
> So what I recommend extending the tun engine interface I recently
> implemented[1] for 2.4, and add an engine to delegate calls to the
> openvpn plugin framework, the tun engine interface already supports
> opening the tun, configuring the tun etc... maybe minor changes are
> required, I will be happy to work on this.
> 
> We also add an option for a plugin to use the management interface and
> expose something like: plugin  command.
> 
> Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain socket
> in addition to the management interface and put its number in
> environment ANDROID_CONTROL_FD=XXX.
> 
> A special android plugin will be loaded which register to the tun
> engine notifications, it will be able to interact with the UI via the
> management interface, but for two special tasks it will use the custom
> unix domain control fd in addition, for example via the management
> interface it will forward the network details, then ask for tun fd, and
> will get the fd via the control channel.
> 
> This way you will be able to maintain the android custom code as a
> whole, while the openvpn project will benefit from the ability to
> expose all plugins via the management interface for any task and be
> able to perform routing and networking setting via plugin (which was
> also discussed for privilege separation model).
> 
> Alon.
> 
> [1] https://github.com/alonbl/openvpn/compare/master...tun
> 

Basically, what you're asking is that a reasonably simple patch is extended 
into a revamp of the management system. While I agree that more modularisation 
is important for OpenVPN, stopping all progress and killing off a useful 
feature is not the way to achieve that. Shall we agree to discuss the technical 
merits of the patch, and not the grand vision of how OpenVPN should look? Don't 
throw out the good for the perfect :).

Modularisation work is planned for 2.4, and adding a management-interface 
controlled tun module would be a great idea there. I still disagree on using 
the plugin interface for that. A modularised system is fine there.

Adriaan

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

Hello Mendelt,

Thank you for taking the time to explain the process, now at least I
can comment better.

On Thu, May 10, 2012 at 5:03 PM, Mendelt Siebenga
 wrote:


> Android has a lot of limitations on how you can get access to a TUN device 
> without rooting your phone. Basically what you need to do is:
> - Pass a file descriptor of the socket used by OpenVPN to a system call to 
> protect it. This prevents traffic to this socket being routed over the vpn 
> itself.
> - Pass all routing information, dns servers etc. To a system call. This call 
> sets up routing and returns a file descriptor to the TUN device.

This is new!
So you need the complete IP and routing settings *BEFORE* you open the
tun, this was not clear from the discussion.



> I'm not really sure about putting these changes off into a separate plugin. I 
> personally like to modularize code as much as possible, but my guess is that 
> in this case adding the hooks to the plugin interface that are necessary to 
> allow this functionality to be implemented as a plugin will add more clutter 
> to OpenVPN than just adding them to the core. I'm not sure what the plans are 
> for the plugin interface but I can imagine that if it becomes more powerful 
> over time we might be able to spin off these changes as a separate plugin 
> later.

This is exactly what I am afraid of, merge now monolithic code in a
hope that in future someone will clean up the mess. To be able to
provide a solution now to users an external patch may be used, nothing
wrong with this.

I prefer to work a little harder and implement the modular
infrastructure required to support this scenario and other that may
exist, this without breaking assumptions, such as management interface
can be TCP connection.

So what I recommend extending the tun engine interface I recently
implemented[1] for 2.4, and add an engine to delegate calls to the
openvpn plugin framework, the tun engine interface already supports
opening the tun, configuring the tun etc... maybe minor changes are
required, I will be happy to work on this.

We also add an option for a plugin to use the management interface and
expose something like: plugin  command.

Then [[[JUST A SUGGESTION]] the UI (java) will open unix domain socket
in addition to the management interface and put its number in
environment ANDROID_CONTROL_FD=XXX.

A special android plugin will be loaded which register to the tun
engine notifications, it will be able to interact with the UI via the
management interface, but for two special tasks it will use the custom
unix domain control fd in addition, for example via the management
interface it will forward the network details, then ask for tun fd,
and will get the fd via the control channel.

This way you will be able to maintain the android custom code as a
whole, while the openvpn project will benefit from the ability to
expose all plugins via the management interface for any task and be
able to perform routing and networking setting via plugin (which was
also discussed for privilege separation model).

Alon.

[1] https://github.com/alonbl/openvpn/compare/master...tun

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Arne Schwabe]

I generaly agree with Mendelt. A few additions

> We considered two ways of doing this:
> - Modify OpenVPN to make it possible to use JNI to call into OpenVPN
directly from Java code.

I implemented that in the first version of my app (<= 0.4.6). But that
involed evil trickery like set_jmp/long_jmp and had other deficits like
memory leaks when stopping a connection and opening a new one.

> - Modify OpenVPN to add the needed functionality to the management
interface like Arne did.
>
> The first option is probably easier to implement on the Java side but
it requires a lot of changes in the OpenVPN code. The second option
needs a couple of relatively simple changes in OpenVPN and makes it
possible for these changes to be reused in other contexts. Being able to
get routing information and pass TUN devices to OpenVPN might be useful
for some of the GUI projects too.
>
> One thing we did differently is that we don't use JNI at all. We use
the existing build system to cross compile OpenVpn as a normal arm-linux
executable, package it inside the android apk, write it to flash when it
is needed and then execute it from the apk as a separate process. After
this we were planning to use the management interface in the same way
Arne has implemented.

My newest version does also does not use JNI at all :). (aport from a
tiny wrapper around close(int fd) since I have not yet found another way
to close a FileSocket in java).

I build openvpn as library so I only have to write a tiny wrapper to the
flash which calls main of the openvpn library.

> In order to make Arne's changes more reusable I would suggest a couple
of small changes:
>
> - Split the changes up into three features: 1. send socket on the
management interface. 2. Send routing info on management interface 3.
Receive the TUN device on the management interface
>
> - Use command line options or options in the configuration file to
enable these features instead of relying on #ifdef TARGET_ANDROID
>
> - Add some checks to warn about nonsensical settings. For example using
these features without a management interface or with a management
interface on a tcp/ip socket or on an OS that doesn't support sending
filedescriptors over domain sockets should result in an error message.
>
>
> I'm not really sure about putting these changes off into a separate
plugin. I personally like to modularize code as much as possible, but my
guess is that in this case adding the hooks to the plugin interface that
are necessary to allow this functionality to be implemented as a plugin
will add more clutter to OpenVPN than just adding them to the core. I'm
not sure what the plans are for the plugin interface but I can imagine
that if it becomes more powerful over time we might be able to spin off
these changes as a separate plugin later.
>

I agree on these.

-- 
Arne Schwabe, M.Sc. - http://www.uni-paderborn.de/cs/cn/
Computer Science, University of Paderborn, Germany,  +49 5251 60-1756

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Mendelt Siebenga]

Let me introduce myself first as this is my first post to this mailing list.

I'm Mendelt Siebenga, a new colleague of Adriaan de Jong. I started working for 
Fox IT a couple of weeks ago. I've been working on something similar to what 
Arne has been doing but my background is more in higher level Java-y coding so 
getting familiar with the OpenVPN code has taken me a lot of time. I'm 
impressed by the progress Arne has made. I'd like to jump in and add some 
suggestions and hopefully clarify some technical aspects. Adriaan and me 
arrived at a very similar solution as Arne for getting OpenVPN to work on 
Android 4 so maybe it's helpful if we clarify how we got to the decisions we 
made.

Android has a lot of limitations on how you can get access to a TUN device 
without rooting your phone. Basically what you need to do is:
- Pass a file descriptor of the socket used by OpenVPN to a system call to 
protect it. This prevents traffic to this socket being routed over the vpn 
itself.
- Pass all routing information, dns servers etc. To a system call. This call 
sets up routing and returns a file descriptor to the TUN device.
Both of these system calls are Java only.

So in order to get this to work with OpenVPN you need to be able to:
- Get a file descriptor for the socket OpenVPN uses
- Prevent OpenVPN from adding routes itself and get routing information to pass 
to the Android API
- Pass an opened TUN device to OpenVPN.

We considered two ways of doing this:
- Modify OpenVPN to make it possible to use JNI to call into OpenVPN directly 
from Java code.
- Modify OpenVPN to add the needed functionality to the management interface 
like Arne did.

The first option is probably easier to implement on the Java side but it 
requires a lot of changes in the OpenVPN code. The second option needs a couple 
of relatively simple changes in OpenVPN and makes it possible for these changes 
to be reused in other contexts. Being able to get routing information and pass 
TUN devices to OpenVPN might be useful for some of the GUI projects too.

One thing we did differently is that we don't use JNI at all. We use the 
existing build system to cross compile OpenVpn as a normal arm-linux 
executable, package it inside the android apk, write it to flash when it is 
needed and then execute it from the apk as a separate process. After this we 
were planning to use the management interface in the same way Arne has 
implemented.

In order to make Arne's changes more reusable I would suggest a couple of small 
changes:

- Split the changes up into three features: 1. send socket on the management 
interface. 2. Send routing info on management interface 3. Receive the TUN 
device on the management interface

- Use command line options or options in the configuration file to enable these 
features instead of relying on #ifdef TARGET_ANDROID

- Add some checks to warn about nonsensical settings. For example using these 
features without a management interface or with a management interface on a 
tcp/ip socket or on an OS that doesn't support sending filedescriptors over 
domain sockets should result in an error message.


I'm not really sure about putting these changes off into a separate plugin. I 
personally like to modularize code as much as possible, but my guess is that in 
this case adding the hooks to the plugin interface that are necessary to allow 
this functionality to be implemented as a plugin will add more clutter to 
OpenVPN than just adding them to the core. I'm not sure what the plans are for 
the plugin interface but I can imagine that if it becomes more powerful over 
time we might be able to spin off these changes as a separate plugin later.

Kind regards,
Mendelt Siebenga

-Original Message-
From: David Sommerseth [mailto:openvpn.l...@topphemmelig.net]
Sent: donderdag 10 mei 2012 11:49
To: Alon Bar-Lev
Cc: openvpn-devel@lists.sourceforge.net
Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/12 09:28, Adriaan de Jong wrote:
> I still prefer using the management interface. It keeps the interface
> to the Java stuff very clean (socket-based). Further you potentially
> allow other systems, such as Apple or Windows Phone to do the same. It
> avoids messy JNI stuff, and fits into the spirit of the management
> interface. It's the simplest solution.

I agree.  The plug-in approach seems a bit overkill to me.  The approach using 
the management API makes it far simpler.

Bear in mind that Windows Phone 7 support will probably be asked for at some 
point - we have no idea how that will really work out now.  We have users 
wanting support for iPhone/iPad.  The plug-in approach means to write both a 
suitable plug-in for the platform and the front-end app.  Using just the 
management API, you just need to write the GUI which does all the needed gluing 
on the native platforms in that app, just how it wants it.


kind regards,

David Sommerseth

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

[Alon Bar-Lev]

On Thu, May 10, 2012 at 3:42 PM, Alon Bar-Lev  wrote:
> On Thu, May 10, 2012 at 3:39 PM, David Sommerseth
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/05/12 14:33, Alon Bar-Lev wrote:
>>> On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen
>>>  wrote:

> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
>  wrote:
>>> Hello David,
>>>
>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>>  wrote:
>>>
>>> 
>>>
 The reason I don't see the benefit of splitting out the
 plug-ins as much is that they all depend on OpenVPN.  You
 can not make much use of these plug-ins without having
 OpenVPN.  But with Windows TAP driver and easy-rsa, they
 can be completely used independently.

 Another point is that the plug-ins we have in the source
 tree, is officially supported plug-ins.  And especially
 auth-pam and down-root are plug-ins which are very useful
 and we should encourage packagers to always package
 those.

 Then the example/ and defer/ plug-ins, which are
 examples.  Maybe it would rather make sense to merge them
 somehow?
>>> There are a lot of plugins out there, think about chrome
>>> extension or firefox extension, but also network manager
>>> plugins or similar, they are all depend on the core
>>> product, but extend its functionality, and have their own
>>> repositories.
>>>
>>> Plugins should be installed as separate package, aka rpm.
>>>
>>> So if administrator wants openvpn he does: # yum install
>>> openvpn
>>>
>>> Now, if administrator wants auth-pam, he should do: # yum
>>> install openvpn-plugin-auth-pam
>>>
>>> As there is no sense in keeping the auth-pam plugin in
>>> system if it is unused nor to have pam dependency of the
>>> openvpn core package.
>>>
>>> I would not encourage packages to always have them, it is
>>> also not the correct approach for plugins. Plugins should
>>> be optional in nature.
>>>
>>> All the above does not imply separate repository as in both
>>> cases we can either provide one .spec file that generate
>>> both rpms or two separate spec files.
>>>
>>> The real question is how do we provide proper build for
>>> this components. Currently it has poor-man-build, which I
>>> fixed to meet some level of quality, instead of
>>> ./configure&&make install, packager should go and figure
>>> own what else needs to be built in tree.
>>>
>>> So either these are officially supported and should be
>>> build properly using main build system, example: --- $
>>> ./configure --enable-plugin-auth-pam PAM_CFLAGS=...
>>> PAM_LIBS=... ---
>>>
>>> Or have plugins as separate components with its own release
>>> cycle and should have their proper own build system and
>>> release cycle.
>>>
>>> I think that if we have proper interface
>>> (openvpn-plugin.h), there is no sense in providing the
>>> plugins within the tree, as it has its own release cycle.
>>>
>>> I also would like to discuss the "official" argument A
>>> project can have several repositories all at equal
>>> "official" level, why on earth people think that having
>>> more than one repository around damage their "official"
>>> state? "officially supported plug-ins", can be official in
>>> the openvpn repository and can be official in their own
>>> repository, there is absolutely no difference between the
>>> two approaches in this regards.
>>>
>>> However, splitting the repositories, allow helping distro
>>> packaging in determine what needed to be packaged and
>>> provided to users, it also allow separate release cycle
>>> (new openvpn release does not force new plugin release),
>>> and can even help in maintenance as a plugin can have its
>>> own maintainer (commit access).
>>>
>>> If also has more advantage as now in github we can
>>> encourage people to host and maintain their plugin within
>>> the OpenVPN organization, attracting more skills. So bottom
>>> line:
>>>
>>> 1. Either we add the plugins to core build system, with its
>>> disadvantages.
>>>
>>> 2. Split plugins into their own repository, release cycle,
>>> packaging.
>>>
>>> I am for (2), as I don't afraid of the "official" argument
>>> nor do I afraid to commit to more than one repository, and
>>> the modular nature of the plugin interface allows optional
>>> components to be installed separately along with their own
>>> dependencies.
>>>
>>> Alon
>> I think there's some very good argumentation here. In my
>> view, separating plugins into their own repositories would
>> have some important advantages; excuse me for repeating some
>> of Alon's argume

Re: [Openvpn-devel] Some issues with openvpn-build/windows-nsis

[Samuli Seppänen]

> On Thu, May 10, 2012 at 3:11 PM, Samuli Seppänen  wrote:
>> Hi,
>>
>> I tried to generate a Windows installer on Ubuntu 11.10 amd64, but ran
>> into some issues:
>>
>> $ cd openvpn-build/windows-nsis
>> $ ./build-snapshot
>> --- snip ---
>>
>> make[3]: Leaving directory
>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>> make[2]: Leaving directory
>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>> make[1]: Leaving directory
>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>> tap-windows
>> Fixup libtool files
>> Restore libtool files
>> ls: cannot access tmp/image-i686/openvpn-i686-*-bin.*: No such file or
>> directory
>>
>> The error message seems clear enough, but I'm wondering why the binaries
>> are not where it looks for them:
>>
>> $ ls tmp/image-i686
>> openvpn
>> $ ls tmp/image-i686/openvpn
>> bin  etc  include  lib  share
> This is strange, as you referred to dash, which I never tested, I will
> try and see if that is the problem.
>
> Alon.
What I know is that if I work around this problem, I get a shell syntax
error later on... and if I switch #!/bin/sh to #!/bin/bash in
"build-snapshot", that syntax error goes away. To be more precise, the
error occurs at openvpn-build/windows-nsis/build:5, which is

   ROOT="${ROOT:-tmp}"

I don't have full logs at hand right now, unfortunately.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

On Thu, May 10, 2012 at 12:48 PM, David Sommerseth
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/05/12 09:28, Adriaan de Jong wrote:
>> I still prefer using the management interface. It keeps the
>> interface to the Java stuff very clean (socket-based). Further you
>> potentially allow other systems, such as Apple or Windows Phone to
>> do the same. It avoids messy JNI stuff, and fits into the spirit of
>> the management interface. It's the simplest solution.
>
> I agree.  The plug-in approach seems a bit overkill to me.  The
> approach using the management API makes it far simpler.

It can be either management interface or socket between UI and plugin.

The issue is monolithic vs modular.

OpenVPN is already exploded in feature that are needed by specific
installations.

For every new feature was need to add we should ask our-selves if it
can be added using modular approach and what is missing in the public
interfaces in order to do the task.

Of course adding features as #ifdefs is simpler at first, but later on
they tend to be complex to maintain and untested, moving to modular
components can delegate the maintenance and making the core product
quality higher.

If we need to allow directing custom commands to specific plugin via
the management - this I can understand.
But patching the core for these tasks is something I think we should avoid.

Alon.

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Samuli Seppänen]

>
>> -Original Message-
>> From: David Sommerseth [mailto:openvpn.l...@topphemmelig.net]
>> Sent: donderdag 10 mei 2012 11:49
>> To: Alon Bar-Lev
>> Cc: Adriaan de Jong; openvpn-devel@lists.sourceforge.net
>> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/05/12 09:28, Adriaan de Jong wrote:
>>> I still prefer using the management interface. It keeps the interface
>>> to the Java stuff very clean (socket-based). Further you potentially
>>> allow other systems, such as Apple or Windows Phone to do the same.
>> It
>>> avoids messy JNI stuff, and fits into the spirit of the management
>>> interface. It's the simplest solution.
>> I agree.  The plug-in approach seems a bit overkill to me.  The
>> approach using the management API makes it far simpler.
>>
>> Bear in mind that Windows Phone 7 support will probably be asked for at
>> some point - we have no idea how that will really work out now.  We
>> have users wanting support for iPhone/iPad.  The plug-in approach means
>> to write both a suitable plug-in for the platform and the front-end
>> app.  Using just the management API, you just need to write the GUI
>> which does all the needed gluing on the native platforms in that app,
>> just how it wants it.
>>
>>
> In fact, it's theoretically even a way to remove the need for root rights for 
> the OpenVPN executable, and moving them towards a different, simpler app.
>
>
Speaking of Windows Phone 7 and iPhone/iPad afaik[1] their
respective application stores prohibit apps with reciprocal licenses
(e.g. GPLv2). Is there any way to work around this arbitrary limitations
without a complete rewrite? Having to root one's iPhone/iPad/Windows
Phone to use OpenVPN sounds silly.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


[1]

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

[Alon Bar-Lev]

On Thu, May 10, 2012 at 3:39 PM, David Sommerseth
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/05/12 14:33, Alon Bar-Lev wrote:
>> On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen
>>  wrote:
>>>
 On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
  wrote:
>> Hello David,
>>
>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>  wrote:
>>
>> 
>>
>>> The reason I don't see the benefit of splitting out the
>>> plug-ins as much is that they all depend on OpenVPN.  You
>>> can not make much use of these plug-ins without having
>>> OpenVPN.  But with Windows TAP driver and easy-rsa, they
>>> can be completely used independently.
>>>
>>> Another point is that the plug-ins we have in the source
>>> tree, is officially supported plug-ins.  And especially
>>> auth-pam and down-root are plug-ins which are very useful
>>> and we should encourage packagers to always package
>>> those.
>>>
>>> Then the example/ and defer/ plug-ins, which are
>>> examples.  Maybe it would rather make sense to merge them
>>> somehow?
>> There are a lot of plugins out there, think about chrome
>> extension or firefox extension, but also network manager
>> plugins or similar, they are all depend on the core
>> product, but extend its functionality, and have their own
>> repositories.
>>
>> Plugins should be installed as separate package, aka rpm.
>>
>> So if administrator wants openvpn he does: # yum install
>> openvpn
>>
>> Now, if administrator wants auth-pam, he should do: # yum
>> install openvpn-plugin-auth-pam
>>
>> As there is no sense in keeping the auth-pam plugin in
>> system if it is unused nor to have pam dependency of the
>> openvpn core package.
>>
>> I would not encourage packages to always have them, it is
>> also not the correct approach for plugins. Plugins should
>> be optional in nature.
>>
>> All the above does not imply separate repository as in both
>> cases we can either provide one .spec file that generate
>> both rpms or two separate spec files.
>>
>> The real question is how do we provide proper build for
>> this components. Currently it has poor-man-build, which I
>> fixed to meet some level of quality, instead of
>> ./configure&&make install, packager should go and figure
>> own what else needs to be built in tree.
>>
>> So either these are officially supported and should be
>> build properly using main build system, example: --- $
>> ./configure --enable-plugin-auth-pam PAM_CFLAGS=...
>> PAM_LIBS=... ---
>>
>> Or have plugins as separate components with its own release
>> cycle and should have their proper own build system and
>> release cycle.
>>
>> I think that if we have proper interface
>> (openvpn-plugin.h), there is no sense in providing the
>> plugins within the tree, as it has its own release cycle.
>>
>> I also would like to discuss the "official" argument A
>> project can have several repositories all at equal
>> "official" level, why on earth people think that having
>> more than one repository around damage their "official"
>> state? "officially supported plug-ins", can be official in
>> the openvpn repository and can be official in their own
>> repository, there is absolutely no difference between the
>> two approaches in this regards.
>>
>> However, splitting the repositories, allow helping distro
>> packaging in determine what needed to be packaged and
>> provided to users, it also allow separate release cycle
>> (new openvpn release does not force new plugin release),
>> and can even help in maintenance as a plugin can have its
>> own maintainer (commit access).
>>
>> If also has more advantage as now in github we can
>> encourage people to host and maintain their plugin within
>> the OpenVPN organization, attracting more skills. So bottom
>> line:
>>
>> 1. Either we add the plugins to core build system, with its
>> disadvantages.
>>
>> 2. Split plugins into their own repository, release cycle,
>> packaging.
>>
>> I am for (2), as I don't afraid of the "official" argument
>> nor do I afraid to commit to more than one repository, and
>> the modular nature of the plugin interface allows optional
>> components to be installed separately along with their own
>> dependencies.
>>
>> Alon
> I think there's some very good argumentation here. In my
> view, separating plugins into their own repositories would
> have some important advantages; excuse me for repeating some
> of Alon's arguments here:
>
> 1) Delegating maintenance tasks easily to (new) developers:
> this is now trivial with GitHub 2) Avoid having to make an
> OpenVPN release due

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/12 14:33, Alon Bar-Lev wrote:
> On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen
>  wrote:
>> 
>>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
>>>  wrote:
> Hello David,
> 
> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth 
>  wrote:
> 
> 
> 
>> The reason I don't see the benefit of splitting out the
>> plug-ins as much is that they all depend on OpenVPN.  You
>> can not make much use of these plug-ins without having
>> OpenVPN.  But with Windows TAP driver and easy-rsa, they
>> can be completely used independently.
>> 
>> Another point is that the plug-ins we have in the source
>> tree, is officially supported plug-ins.  And especially
>> auth-pam and down-root are plug-ins which are very useful
>> and we should encourage packagers to always package
>> those.
>> 
>> Then the example/ and defer/ plug-ins, which are
>> examples.  Maybe it would rather make sense to merge them
>> somehow?
> There are a lot of plugins out there, think about chrome
> extension or firefox extension, but also network manager
> plugins or similar, they are all depend on the core
> product, but extend its functionality, and have their own
> repositories.
> 
> Plugins should be installed as separate package, aka rpm.
> 
> So if administrator wants openvpn he does: # yum install
> openvpn
> 
> Now, if administrator wants auth-pam, he should do: # yum
> install openvpn-plugin-auth-pam
> 
> As there is no sense in keeping the auth-pam plugin in
> system if it is unused nor to have pam dependency of the
> openvpn core package.
> 
> I would not encourage packages to always have them, it is
> also not the correct approach for plugins. Plugins should
> be optional in nature.
> 
> All the above does not imply separate repository as in both
> cases we can either provide one .spec file that generate
> both rpms or two separate spec files.
> 
> The real question is how do we provide proper build for
> this components. Currently it has poor-man-build, which I
> fixed to meet some level of quality, instead of
> ./configure&&make install, packager should go and figure
> own what else needs to be built in tree.
> 
> So either these are officially supported and should be
> build properly using main build system, example: --- $
> ./configure --enable-plugin-auth-pam PAM_CFLAGS=...
> PAM_LIBS=... ---
> 
> Or have plugins as separate components with its own release
> cycle and should have their proper own build system and
> release cycle.
> 
> I think that if we have proper interface
> (openvpn-plugin.h), there is no sense in providing the
> plugins within the tree, as it has its own release cycle.
> 
> I also would like to discuss the "official" argument A
> project can have several repositories all at equal
> "official" level, why on earth people think that having
> more than one repository around damage their "official"
> state? "officially supported plug-ins", can be official in
> the openvpn repository and can be official in their own 
> repository, there is absolutely no difference between the
> two approaches in this regards.
> 
> However, splitting the repositories, allow helping distro
> packaging in determine what needed to be packaged and
> provided to users, it also allow separate release cycle
> (new openvpn release does not force new plugin release),
> and can even help in maintenance as a plugin can have its
> own maintainer (commit access).
> 
> If also has more advantage as now in github we can
> encourage people to host and maintain their plugin within
> the OpenVPN organization, attracting more skills. So bottom
> line:
> 
> 1. Either we add the plugins to core build system, with its
> disadvantages.
> 
> 2. Split plugins into their own repository, release cycle,
> packaging.
> 
> I am for (2), as I don't afraid of the "official" argument
> nor do I afraid to commit to more than one repository, and
> the modular nature of the plugin interface allows optional
> components to be installed separately along with their own
> dependencies.
> 
> Alon
 I think there's some very good argumentation here. In my
 view, separating plugins into their own repositories would
 have some important advantages; excuse me for repeating some
 of Alon's arguments here:
 
 1) Delegating maintenance tasks easily to (new) developers:
 this is now trivial with GitHub 2) Avoid having to make an
 OpenVPN release due to an important fix in a plugin used by
 few. This also helps distro packagers, provided they didn't
 bundle the plugins in their core "openvpn"

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

On Thu, May 10, 2012 at 12:06 PM, David Sommerseth
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/05/12 00:36, Arne Schwabe wrote:
>
>>> I suggest you clone the repository at github, create a branch
>>> and order your changes.
>>
>>
>> that would mean to revert all changes, making the changes in small
>> steps and commiting each step? (I am still trying to learn how to
>> work with git)
>
> Using github is no requirement.  From what I see, all your patches was
> gathered into a single file.  For this initial review, I see no issues
> with that.  And the changeset isn't really that big.

I only asked for, and indeed it was easier to review than original offering.

Alon.

Re: [Openvpn-devel] Some issues with openvpn-build/windows-nsis

[Alon Bar-Lev]

On Thu, May 10, 2012 at 3:11 PM, Samuli Seppänen  wrote:
> Hi,
>
> I tried to generate a Windows installer on Ubuntu 11.10 amd64, but ran
> into some issues:
>
> $ cd openvpn-build/windows-nsis
> $ ./build-snapshot
> --- snip ---
>
> make[3]: Leaving directory
> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
> make[2]: Leaving directory
> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
> make[1]: Leaving directory
> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
> tap-windows
> Fixup libtool files
> Restore libtool files
> ls: cannot access tmp/image-i686/openvpn-i686-*-bin.*: No such file or
> directory
>
> The error message seems clear enough, but I'm wondering why the binaries
> are not where it looks for them:
>
> $ ls tmp/image-i686
> openvpn
> $ ls tmp/image-i686/openvpn
> bin  etc  include  lib  share

This is strange, as you referred to dash, which I never tested, I will
try and see if that is the problem.

Alon.

Re: [Openvpn-devel] Some issues with openvpn-build/windows-nsis

[Alon Bar-Lev]

On Thu, May 10, 2012 at 3:23 PM, Samuli Seppänen  wrote:
> Il 10.05.2012 15:11, Samuli Seppänen ha scritto:
>> Hi,
>>
>> I tried to generate a Windows installer on Ubuntu 11.10 amd64, but ran
>> into some issues:
>>
>> $ cd openvpn-build/windows-nsis
>> $ ./build-snapshot
>> --- snip ---
>>
>> make[3]: Leaving directory
>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>> make[2]: Leaving directory
>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>> make[1]: Leaving directory
>> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
>> tap-windows
>> Fixup libtool files
>> Restore libtool files
>> ls: cannot access tmp/image-i686/openvpn-i686-*-bin.*: No such file or
>> directory
>>
>> The error message seems clear enough, but I'm wondering why the binaries
>> are not where it looks for them:
>>
>> $ ls tmp/image-i686
>> openvpn
>> $ ls tmp/image-i686/openvpn
>> bin  etc  include  lib  share
>
> Oh, forgot to ask... is there a clean way to resume the build near the
> failure point? Rebuilding everything every time is very time-consuming.

No sorry, I didn't think it worth the effort as dependencies build
is one time and you can use regular openvpn configure && make against
the dependencies while developing.

But once you have the binary images you can use the windows-nsis/build
script to only create installer out of them.

Alon.

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

[Alon Bar-Lev]

On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen  wrote:
>
>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen  wrote:
 Hello David,

 On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
  wrote:

 

> The reason I don't see the benefit of splitting out the plug-ins as
> much is that they all depend on OpenVPN.  You can not make much use of
> these plug-ins without having OpenVPN.  But with Windows TAP driver
> and easy-rsa, they can be completely used independently.
>
> Another point is that the plug-ins we have in the source tree, is
> officially supported plug-ins.  And especially auth-pam and down-root
> are plug-ins which are very useful and we should encourage packagers
> to always package those.
>
> Then the example/ and defer/ plug-ins, which are examples.  Maybe it
> would rather make sense to merge them somehow?
 There are a lot of plugins out there, think about chrome extension or
 firefox extension, but also network manager plugins or similar, they
 are all depend on the core product, but extend its functionality, and
 have their own repositories.

 Plugins should be installed as separate package, aka rpm.

 So if administrator wants openvpn he does:
 # yum install openvpn

 Now, if administrator wants auth-pam, he should do:
 # yum install openvpn-plugin-auth-pam

 As there is no sense in keeping the auth-pam plugin in system if it is
 unused nor to have pam dependency of the openvpn core package.

 I would not encourage packages to always have them, it is also not the
 correct approach for plugins. Plugins should be optional in nature.

 All the above does not imply separate repository as in both cases we
 can either provide one .spec file that generate both rpms or two
 separate spec files.

 The real question is how do we provide proper build for this
 components. Currently it has poor-man-build, which I fixed to meet
 some level of quality, instead of ./configure&&make install, packager
 should go and figure own what else needs to be built in tree.

 So either these are officially supported and should be build properly
 using main build system, example:
 ---
 $ ./configure --enable-plugin-auth-pam PAM_CFLAGS=... PAM_LIBS=...
 ---

 Or have plugins as separate components with its own release cycle and
 should have their proper own build system and release cycle.

 I think that if we have proper interface (openvpn-plugin.h), there is
 no sense in providing the plugins within the tree, as it has its own
 release cycle.

 I also would like to discuss the "official" argument
 A project can have several repositories all at equal "official" level,
 why on earth people think that having more than one repository around
 damage their "official" state? "officially supported plug-ins", can be
 official in the openvpn repository and can be official in their own
 repository, there is absolutely no difference between the two
 approaches in this regards.

 However, splitting the repositories, allow helping distro packaging in
 determine what needed to be packaged and provided to users, it also
 allow separate release cycle (new openvpn release does not force new
 plugin release), and can even help in maintenance as a plugin can have
 its own maintainer (commit access).

 If also has more advantage as now in github we can encourage people to
 host and maintain their plugin within the OpenVPN organization,
 attracting more skills.
 So bottom line:

 1. Either we add the plugins to core build system, with its disadvantages.

 2. Split plugins into their own repository, release cycle, packaging.

 I am for (2), as I don't afraid of the "official" argument nor do I
 afraid to commit to more than one repository, and the modular nature
 of the plugin interface allows optional components to be installed
 separately along with their own dependencies.

 Alon
>>> I think there's some very good argumentation here. In my view,
>>> separating plugins into their own repositories would have some important
>>> advantages; excuse me for repeating some of Alon's arguments here:
>>>
>>> 1) Delegating maintenance tasks easily to (new) developers: this is now
>>> trivial with GitHub
>>> 2) Avoid having to make an OpenVPN release due to an important fix in a
>>> plugin used by few. This also helps distro packagers, provided they
>>> didn't bundle the plugins in their core "openvpn" package
>>>
>>> Afaik none of the official plugins are needed to create the official
>>> Windows installers, so that platform is entirely unaffected. On *NIX
>>> side we only release source code. If we don't want to force people to
>>> fetch official plugin code using Git, providing tarballs would 

Re: [Openvpn-devel] Some issues with openvpn-build/windows-nsis

[Samuli Seppänen]

Il 10.05.2012 15:11, Samuli Seppänen ha scritto:
> Hi,
>
> I tried to generate a Windows installer on Ubuntu 11.10 amd64, but ran
> into some issues:
>
> $ cd openvpn-build/windows-nsis
> $ ./build-snapshot
> --- snip ---
>
> make[3]: Leaving directory
> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
> make[2]: Leaving directory
> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
> make[1]: Leaving directory
> `/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
> tap-windows
> Fixup libtool files
> Restore libtool files
> ls: cannot access tmp/image-i686/openvpn-i686-*-bin.*: No such file or
> directory
>
> The error message seems clear enough, but I'm wondering why the binaries
> are not where it looks for them:
>
> $ ls tmp/image-i686
> openvpn
> $ ls tmp/image-i686/openvpn
> bin  etc  include  lib  share

Oh, forgot to ask... is there a clean way to resume the build near the
failure point? Rebuilding everything every time is very time-consuming.

Samuli

[Openvpn-devel] Some issues with openvpn-build/windows-nsis

[Samuli Seppänen]

Hi,

I tried to generate a Windows installer on Ubuntu 11.10 amd64, but ran
into some issues:

$ cd openvpn-build/windows-nsis
$ ./build-snapshot
--- snip ---

make[3]: Leaving directory
`/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
make[2]: Leaving directory
`/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
make[1]: Leaving directory
`/home/samuli/opt/openvpn-build/windows-nsis/tmp/build-i686/pkcs11-helper-1.10'
tap-windows
Fixup libtool files
Restore libtool files
ls: cannot access tmp/image-i686/openvpn-i686-*-bin.*: No such file or
directory

The error message seems clear enough, but I'm wondering why the binaries
are not where it looks for them:

$ ls tmp/image-i686
openvpn
$ ls tmp/image-i686/openvpn
bin  etc  include  lib  share

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


PS. For those interested in building and cross-compiling OpenVPN using
the new "openvpn-build" buildsystem, please take a look here:

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Adriaan de Jong]

> -Original Message-
> From: David Sommerseth [mailto:openvpn.l...@topphemmelig.net]
> Sent: donderdag 10 mei 2012 11:49
> To: Alon Bar-Lev
> Cc: Adriaan de Jong; openvpn-devel@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/05/12 09:28, Adriaan de Jong wrote:
> > I still prefer using the management interface. It keeps the interface
> > to the Java stuff very clean (socket-based). Further you potentially
> > allow other systems, such as Apple or Windows Phone to do the same.
> It
> > avoids messy JNI stuff, and fits into the spirit of the management
> > interface. It's the simplest solution.
> 
> I agree.  The plug-in approach seems a bit overkill to me.  The
> approach using the management API makes it far simpler.
> 
> Bear in mind that Windows Phone 7 support will probably be asked for at
> some point - we have no idea how that will really work out now.  We
> have users wanting support for iPhone/iPad.  The plug-in approach means
> to write both a suitable plug-in for the platform and the front-end
> app.  Using just the management API, you just need to write the GUI
> which does all the needed gluing on the native platforms in that app,
> just how it wants it.
> 
> 

In fact, it's theoretically even a way to remove the need for root rights for 
the OpenVPN executable, and moving them towards a different, simpler app.

Adriaan

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/12 09:28, Adriaan de Jong wrote:
> I still prefer using the management interface. It keeps the 
> interface to the Java stuff very clean (socket-based). Further you
> potentially allow other systems, such as Apple or Windows Phone to
> do the same. It avoids messy JNI stuff, and fits into the spirit of
> the management interface. It's the simplest solution.

I agree.  The plug-in approach seems a bit overkill to me.  The
approach using the management API makes it far simpler.

Bear in mind that Windows Phone 7 support will probably be asked for
at some point - we have no idea how that will really work out now.  We
have users wanting support for iPhone/iPad.  The plug-in approach
means to write both a suitable plug-in for the platform and the
front-end app.  Using just the management API, you just need to write
the GUI which does all the needed gluing on the native platforms in
that app, just how it wants it.


kind regards,

David Sommerseth



>> -Original Message- From: Alon Bar-Lev
>> [mailto:alon.bar...@gmail.com] Sent: donderdag 10 mei 2012 9:17 
>> To: Adriaan de Jong Cc: Arne Schwabe;
>> openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel]
>> [PATCH] Openvpn for Android 4.0 Changeset
>> 
>> Thank you,
>> 
>> Yes, I understand.
>> 
>> If I narrow this to "feature requests", basically we say that: 1.
>> we want direct tun management to the management interface. 2. we
>> want to have some logic when openvpn socket is opened. 3. Pass
>> pre opened tun.
>> 
>> (1)  - direct tun management to the management interface
>> 
>> Until now I thought it should go to the plugin interface as in
>> any privilege separation model, the user will not be able to do
>> any change in networking.
>> 
>> But... I think it will be fairly simple to do so, with the new
>> tun interface[1] I am working of.
>> 
>> It introduces a tun engine, with a standard interface, it will be
>> easy to support several tun engines at same time selecting one
>> by configuration.
>> 
>> So we can have tun-engine-management.c to delegate all to the 
>> management interface. It can be used if management interface is
>> tcp as well...
>> 
>> For example the linux tune engine[2] is very simple.
>> 
>> A management engine can be stacked overriding the tun_ifconfig, 
>> tun_init*.
>> 
>> BUT: I still think that currently it will be much simpler to do
>> this using iproute2 wrapper that uses the android API.
>> 
>> For (2) - custom socket creation
>> 
>> I still think that the plugin API is the right approach, you
>> simply implement openvpn-plugin-android, that opens the socket
>> for the openvpn process. It is not more complex than passing this
>> via the management interface, and can be used if management
>> interface is not unix domain socket...
>> 
>> (3) pre opened tun
>> 
>> This should be simple, as fd can be created and inherited by the 
>> openvpn process.
>> 
>> What do you think?
>> 
>> Alon
>> 
>> 
>> [1] https://github.com/alonbl/openvpn/tree/tun [2] 
>> https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e49f
>>
>> 
41154f61/src/openvpn/tun-engine-linux.c
>> 
>> On Thu, May 10, 2012 at 10:00 AM, Adriaan de Jong
>>  wrote:
>>> That would be another option. In the model we were using (which
>>> might
>> be different), the order is as follows:
>>> 
>>> 1. openvpn is started 2. openvpn opens a socket to the remote
>>> host 2. openvpn establishes the control channel across this
>>> socket 3. openvpn passes socket and control channel data (IP,
>>> routing, DNS, etc) through the management interface to the
>>> android app 4. android app passes these to the VPNService and
>>> receives an opened tun 5. android app passes the tun
>> to
>>> openvpn 6. openvpn proceeds as usual
>>> 
>>> To answer your follow up: There's no need for the extra
>>> complexity of a plugin here. The
>> management interface is a great tool, completely separating
>> OpenVPN from its management interface.
>>> 
>>> Adriaan
>>> 
 -Original Message- From: Alon Bar-Lev
 [mailto:alon.bar...@gmail.com] Sent: donderdag 10 mei 2012
 8:49 To: Adriaan de Jong Cc: Arne Schwabe;
 openvpn-devel@lists.sourceforge.net Subject: Re:
 [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
 
 On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong
  wrote:
>> -Original Message- From: Alon Bar-Lev
>> [mailto:alon.bar...@gmail.com] Sent: donderdag 10 mei
>> 2012 2:10 To: Arne Schwabe Cc:
>> openvpn-devel@lists.sourceforge.net Subject: Re:
>> [Openvpn-devel] [PATCH] Openvpn for Android 4.0 
>> Changeset
>> 
>> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe
>> 
 wrote:
>>> Am 10.05.12 01:39, schrieb Alon Bar-Lev:
 On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe 
 
>> wrote:
>> I need a better description of the tun process...
>> so far I did not understand why you cannot use
>> 

Re: [Openvpn-devel] openvpn question

[Raj Kumar]

Hi JJK,

Thanks a lot for quick responds.  your answer really helped me.




Regards
Raj 




 From: Jan Just Keijser 
To: Raj Kumar  
Cc: "openvpn-devel@lists.sourceforge.net"  
Sent: Thursday, May 10, 2012 2:17 PM
Subject: Re: [Openvpn-devel] openvpn question
 
Hi Raj,

Raj Kumar wrote:
> 
> Hi all,
> 
> I am new to openvpn. I am using openvpn on my  linux machine.
> 
> I have a basic question about openvpn. 
> How openvpn process the incoming packets ?
> 
> Is it processing incoming packets one by one, means receive one packet from 
> the kernel, decrypt it and send it back to the kernel then next packet ?
> or
> whenever a packet comes, openvpn receives  and queues it while doing 
> decryption of already received packet ?
> 
>  
openvpn processes the incoming packets one by one , both from the VPN side (the 
encrypted packets) , and the packets coming in via the tun/tap interface. This 
is one of the main reasons why openvpn speeds top off at around ~ 300 Mbps.

HTH,

JJK

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/12 00:36, Arne Schwabe wrote:

>> I suggest you clone the repository at github, create a branch
>> and order your changes.
> 
> 
> that would mean to revert all changes, making the changes in small
> steps and commiting each step? (I am still trying to learn how to
> work with git)

Using github is no requirement.  From what I see, all your patches was
gathered into a single file.  For this initial review, I see no issues
with that.  And the changeset isn't really that big.

Having that said, it's a good approach to have many smaller changesets
which have well defined changes which "belongs" together.  When
debugging later on, there's a neat feature in git which is called 'git
bisect', which can help you find out which commit causes the trouble.
 Smaller changes gives then a better idea how to fix it, than bigger
changes.  But of course, it makes no sense to have each line change as
a separate commit.  See the build/cleanup commits from Alon or the
PolarSSL commits (git log 0a18017..be960aa)

For the future, you may also find it easier to configure 'git
send-email' when submitting your patches, see our quick crash course
on how to do that.  Basically, if I have five commits you want to send
to the mailing list - all I do is:

$ git send-email HEAD~5

And then patches are formatted and sent via SMTP.  If you want to have
a "cover letter", then do:

   $ git format-patch --cover HEAD~5
   (you may review 000{1..5}-*.patch)
   (edit -cover-letter.patch)
   $ git send-email -cover-letter.patch HEAD~5
   *or*
   $ git send-email -cover-letter.patch 000[12345]-*.patch

This makes sure all your mails are nicely threaded.

git crash course:


There's also other nice tweaks you can do with git there.


And that's all I want to say about git/github or anything like that in
this thread.  The rest of this thread will be about the patch contents
itself from my side.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+rhP8ACgkQDC186MBRfrrGWgCgqe1emSRs8LXAwE33SS9eUDs4
0ggAnjqUxh1gXYPLX2iqEpvfA4FIxfdX
=g4z8
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Jan Just Keijser]

Hi,

Samuli Seppänen wrote:

Hello,

I have developed the port of openvpn for Android 4.0:
https://play.google.com/store/apps/details?id=de.blinkt.openvpn and
http://code.google.com/p/ics-openvpn/

The API of Android 4.0 requires that openvpn runs as completely
unprivileged process. There all opening of tun, adding of routes,
ifconfig etc. has to be done by another process.

This patch implements an API to allow pushing routes, dns, tun over the
management interface (unix socket). Also on Android 4.0 the connection
for the control has to be protect via an API call from the Java GUI.
 
Basically I am using the needok feature of the management protocol to

push all relevant information to the GUI or to request information. I
have not split the patch into multiple small patches because it should
be first discussed if this is right architectural way.


Arne


Hi Arne,

This is very neat, thanks! I wish I had an Android phone to test with
this...

  
FYI: actually, you can run android 4 on your PC (Linux/Win/Mac) quite 
nicely - simply download the android SDK.  Performance is actually 
pretty good!


cheers,

JJK

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Samuli Seppänen]

> Hello,
>
> I have developed the port of openvpn for Android 4.0:
> https://play.google.com/store/apps/details?id=de.blinkt.openvpn and
> http://code.google.com/p/ics-openvpn/
>
> The API of Android 4.0 requires that openvpn runs as completely
> unprivileged process. There all opening of tun, adding of routes,
> ifconfig etc. has to be done by another process.
>
> This patch implements an API to allow pushing routes, dns, tun over the
> management interface (unix socket). Also on Android 4.0 the connection
> for the control has to be protect via an API call from the Java GUI.
>  
> Basically I am using the needok feature of the management protocol to
> push all relevant information to the GUI or to request information. I
> have not split the patch into multiple small patches because it should
> be first discussed if this is right architectural way.
>
>
> Arne
Hi Arne,

This is very neat, thanks! I wish I had an Android phone to test with
this...

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Re: [Openvpn-devel] openvpn question

[Jan Just Keijser]

Hi Raj,

Raj Kumar wrote:


Hi all,

I am new to openvpn. I am using openvpn on my  linux machine.

I have a basic question about openvpn. 


How openvpn process the incoming packets ?

Is it processing incoming packets one by one, means receive one packet 
from the kernel, decrypt it and send it back to the kernel then next 
packet ?

or
whenever a packet comes, openvpn receives  and queues it while doing 
decryption of already received packet ?


 
openvpn processes the incoming packets one by one , both from the VPN 
side (the encrypted packets) , and the packets coming in via the tun/tap 
interface. This is one of the main reasons why openvpn speeds top off at 
around ~ 300 Mbps.


HTH,

JJK

Re: [Openvpn-devel] [RFC] Split plugins into their own repositories

[Samuli Seppänen]

> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen  wrote:
>>> Hello David,
>>>
>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>>  wrote:
>>>
>>> 
>>>
 The reason I don't see the benefit of splitting out the plug-ins as
 much is that they all depend on OpenVPN.  You can not make much use of
 these plug-ins without having OpenVPN.  But with Windows TAP driver
 and easy-rsa, they can be completely used independently.

 Another point is that the plug-ins we have in the source tree, is
 officially supported plug-ins.  And especially auth-pam and down-root
 are plug-ins which are very useful and we should encourage packagers
 to always package those.

 Then the example/ and defer/ plug-ins, which are examples.  Maybe it
 would rather make sense to merge them somehow?
>>> There are a lot of plugins out there, think about chrome extension or
>>> firefox extension, but also network manager plugins or similar, they
>>> are all depend on the core product, but extend its functionality, and
>>> have their own repositories.
>>>
>>> Plugins should be installed as separate package, aka rpm.
>>>
>>> So if administrator wants openvpn he does:
>>> # yum install openvpn
>>>
>>> Now, if administrator wants auth-pam, he should do:
>>> # yum install openvpn-plugin-auth-pam
>>>
>>> As there is no sense in keeping the auth-pam plugin in system if it is
>>> unused nor to have pam dependency of the openvpn core package.
>>>
>>> I would not encourage packages to always have them, it is also not the
>>> correct approach for plugins. Plugins should be optional in nature.
>>>
>>> All the above does not imply separate repository as in both cases we
>>> can either provide one .spec file that generate both rpms or two
>>> separate spec files.
>>>
>>> The real question is how do we provide proper build for this
>>> components. Currently it has poor-man-build, which I fixed to meet
>>> some level of quality, instead of ./configure&&make install, packager
>>> should go and figure own what else needs to be built in tree.
>>>
>>> So either these are officially supported and should be build properly
>>> using main build system, example:
>>> ---
>>> $ ./configure --enable-plugin-auth-pam PAM_CFLAGS=... PAM_LIBS=...
>>> ---
>>>
>>> Or have plugins as separate components with its own release cycle and
>>> should have their proper own build system and release cycle.
>>>
>>> I think that if we have proper interface (openvpn-plugin.h), there is
>>> no sense in providing the plugins within the tree, as it has its own
>>> release cycle.
>>>
>>> I also would like to discuss the "official" argument
>>> A project can have several repositories all at equal "official" level,
>>> why on earth people think that having more than one repository around
>>> damage their "official" state? "officially supported plug-ins", can be
>>> official in the openvpn repository and can be official in their own
>>> repository, there is absolutely no difference between the two
>>> approaches in this regards.
>>>
>>> However, splitting the repositories, allow helping distro packaging in
>>> determine what needed to be packaged and provided to users, it also
>>> allow separate release cycle (new openvpn release does not force new
>>> plugin release), and can even help in maintenance as a plugin can have
>>> its own maintainer (commit access).
>>>
>>> If also has more advantage as now in github we can encourage people to
>>> host and maintain their plugin within the OpenVPN organization,
>>> attracting more skills.
>>> So bottom line:
>>>
>>> 1. Either we add the plugins to core build system, with its disadvantages.
>>>
>>> 2. Split plugins into their own repository, release cycle, packaging.
>>>
>>> I am for (2), as I don't afraid of the "official" argument nor do I
>>> afraid to commit to more than one repository, and the modular nature
>>> of the plugin interface allows optional components to be installed
>>> separately along with their own dependencies.
>>>
>>> Alon
>> I think there's some very good argumentation here. In my view,
>> separating plugins into their own repositories would have some important
>> advantages; excuse me for repeating some of Alon's arguments here:
>>
>> 1) Delegating maintenance tasks easily to (new) developers: this is now
>> trivial with GitHub
>> 2) Avoid having to make an OpenVPN release due to an important fix in a
>> plugin used by few. This also helps distro packagers, provided they
>> didn't bundle the plugins in their core "openvpn" package
>>
>> Afaik none of the official plugins are needed to create the official
>> Windows installers, so that platform is entirely unaffected. On *NIX
>> side we only release source code. If we don't want to force people to
>> fetch official plugin code using Git, providing tarballs would be trivial.
>>
>> I tend to agree that packagers should take care of packaging the plugins
>> as they see fit and making sure they're compatible with their version

[Openvpn-devel] openvpn question

[Raj Kumar]

Hi all,

I am new to openvpn. I am using openvpn on my  linux machine.


I have a basic question about openvpn.  


How openvpn process the incoming packets ?

Is it processing incoming packets one by one, means receive one packet from the 
kernel, decrypt it and send it back to the kernel then next packet ?

or 

whenever a packet comes, openvpn receives  and queues it while doing decryption 
of already received packet ?


 
Regards
Raj Kumar

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

I guess you refer to (2), right?
I don't think the spirit of the management interface was to pass
fds... as it was written in tcp.
A plugin does not mean that you need to write JNI, as it can
communicate using a different unix domain socket to upstream anyway...

Something like:

open fd=45 for management
open fd=77 for plugin communication
fork openvpn
openvpn calls plugin to setup custom socket
plugin uses fd=77 to communicate with UI and returns a socket

==> minimal changes to openvpn to a custom solution that most probably
has no reuse.

On Thu, May 10, 2012 at 10:28 AM, Adriaan de Jong  wrote:
> I still prefer using the management interface. It keeps the interface to the 
> Java stuff very clean (socket-based). Further you potentially allow other 
> systems, such as Apple or Windows Phone to do the same. It avoids messy JNI 
> stuff, and fits into the spirit of the management interface. It's the 
> simplest solution.
>
>> -Original Message-
>> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> Sent: donderdag 10 mei 2012 9:17
>> To: Adriaan de Jong
>> Cc: Arne Schwabe; openvpn-devel@lists.sourceforge.net
>> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
>>
>> Thank you,
>>
>> Yes, I understand.
>>
>> If I narrow this to "feature requests", basically we say that:
>> 1. we want direct tun management to the management interface.
>> 2. we want to have some logic when openvpn socket is opened.
>> 3. Pass pre opened tun.
>>
>> (1)  - direct tun management to the management interface
>>
>> Until now I thought it should go to the plugin interface as in any
>> privilege separation model, the user will not be able to do any change
>> in networking.
>>
>> But... I think it will be fairly simple to do so, with the new tun
>> interface[1] I am working of.
>>
>> It introduces a tun engine, with a standard interface, it will be easy
>> to support several tun engines at same time selecting one by
>> configuration.
>>
>> So we can have tun-engine-management.c to delegate all to the
>> management interface. It can be used if management interface is tcp as
>> well...
>>
>> For example the linux tune engine[2] is very simple.
>>
>> A management engine can be stacked overriding the tun_ifconfig,
>> tun_init*.
>>
>> BUT: I still think that currently it will be much simpler to do this
>> using iproute2 wrapper that uses the android API.
>>
>> For (2) - custom socket creation
>>
>> I still think that the plugin API is the right approach, you simply
>> implement openvpn-plugin-android, that opens the socket for the openvpn
>> process. It is not more complex than passing this via the management
>> interface, and can be used if management interface is not unix domain
>> socket...
>>
>> (3) pre opened tun
>>
>> This should be simple, as fd can be created and inherited by the
>> openvpn process.
>>
>> What do you think?
>>
>> Alon
>>
>>
>> [1] https://github.com/alonbl/openvpn/tree/tun
>> [2]
>> https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e49f
>> 41154f61/src/openvpn/tun-engine-linux.c
>>
>> On Thu, May 10, 2012 at 10:00 AM, Adriaan de Jong 
>> wrote:
>> > That would be another option. In the model we were using (which might
>> be different), the order is as follows:
>> >
>> > 1. openvpn is started
>> > 2. openvpn opens a socket to the remote host 2. openvpn establishes
>> > the control channel across this socket 3. openvpn passes socket and
>> > control channel data (IP, routing, DNS, etc) through the management
>> > interface to the android app 4. android app passes these to the
>> > VPNService and receives an opened tun 5. android app passes the tun
>> to
>> > openvpn 6. openvpn proceeds as usual
>> >
>> > To answer your follow up:
>> > There's no need for the extra complexity of a plugin here. The
>> management interface is a great tool, completely separating OpenVPN
>> from its management interface.
>> >
>> > Adriaan
>> >
>> >> -Original Message-
>> >> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> >> Sent: donderdag 10 mei 2012 8:49
>> >> To: Adriaan de Jong
>> >> Cc: Arne Schwabe; openvpn-devel@lists.sourceforge.net
>> >> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0
>> >> Changeset
>> >>
>> >> On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong 
>> >> wrote:
>> >> >> -Original Message-
>> >> >> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> >> >> Sent: donderdag 10 mei 2012 2:10
>> >> >> To: Arne Schwabe
>> >> >> Cc: openvpn-devel@lists.sourceforge.net
>> >> >> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0
>> >> >> Changeset
>> >> >>
>> >> >> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe 
>> >> wrote:
>> >> >> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
>> >> >> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe
>> >> >> >> 
>> >> >> wrote:
>> >> >>  I need a better description of the tun process... so far I
>> >> >>  did not understand why you cannot use standard approach of
>> >> >>  creating persist

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Adriaan de Jong]

I still prefer using the management interface. It keeps the interface to the 
Java stuff very clean (socket-based). Further you potentially allow other 
systems, such as Apple or Windows Phone to do the same. It avoids messy JNI 
stuff, and fits into the spirit of the management interface. It's the simplest 
solution.

> -Original Message-
> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> Sent: donderdag 10 mei 2012 9:17
> To: Adriaan de Jong
> Cc: Arne Schwabe; openvpn-devel@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
> 
> Thank you,
> 
> Yes, I understand.
> 
> If I narrow this to "feature requests", basically we say that:
> 1. we want direct tun management to the management interface.
> 2. we want to have some logic when openvpn socket is opened.
> 3. Pass pre opened tun.
> 
> (1)  - direct tun management to the management interface
> 
> Until now I thought it should go to the plugin interface as in any
> privilege separation model, the user will not be able to do any change
> in networking.
> 
> But... I think it will be fairly simple to do so, with the new tun
> interface[1] I am working of.
> 
> It introduces a tun engine, with a standard interface, it will be easy
> to support several tun engines at same time selecting one by
> configuration.
> 
> So we can have tun-engine-management.c to delegate all to the
> management interface. It can be used if management interface is tcp as
> well...
> 
> For example the linux tune engine[2] is very simple.
> 
> A management engine can be stacked overriding the tun_ifconfig,
> tun_init*.
> 
> BUT: I still think that currently it will be much simpler to do this
> using iproute2 wrapper that uses the android API.
> 
> For (2) - custom socket creation
> 
> I still think that the plugin API is the right approach, you simply
> implement openvpn-plugin-android, that opens the socket for the openvpn
> process. It is not more complex than passing this via the management
> interface, and can be used if management interface is not unix domain
> socket...
> 
> (3) pre opened tun
> 
> This should be simple, as fd can be created and inherited by the
> openvpn process.
> 
> What do you think?
> 
> Alon
> 
> 
> [1] https://github.com/alonbl/openvpn/tree/tun
> [2]
> https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e49f
> 41154f61/src/openvpn/tun-engine-linux.c
> 
> On Thu, May 10, 2012 at 10:00 AM, Adriaan de Jong 
> wrote:
> > That would be another option. In the model we were using (which might
> be different), the order is as follows:
> >
> > 1. openvpn is started
> > 2. openvpn opens a socket to the remote host 2. openvpn establishes
> > the control channel across this socket 3. openvpn passes socket and
> > control channel data (IP, routing, DNS, etc) through the management
> > interface to the android app 4. android app passes these to the
> > VPNService and receives an opened tun 5. android app passes the tun
> to
> > openvpn 6. openvpn proceeds as usual
> >
> > To answer your follow up:
> > There's no need for the extra complexity of a plugin here. The
> management interface is a great tool, completely separating OpenVPN
> from its management interface.
> >
> > Adriaan
> >
> >> -Original Message-
> >> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> >> Sent: donderdag 10 mei 2012 8:49
> >> To: Adriaan de Jong
> >> Cc: Arne Schwabe; openvpn-devel@lists.sourceforge.net
> >> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0
> >> Changeset
> >>
> >> On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong 
> >> wrote:
> >> >> -Original Message-
> >> >> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> >> >> Sent: donderdag 10 mei 2012 2:10
> >> >> To: Arne Schwabe
> >> >> Cc: openvpn-devel@lists.sourceforge.net
> >> >> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0
> >> >> Changeset
> >> >>
> >> >> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe 
> >> wrote:
> >> >> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
> >> >> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe
> >> >> >> 
> >> >> wrote:
> >> >>  I need a better description of the tun process... so far I
> >> >>  did not understand why you cannot use standard approach of
> >> >>  creating persistent tun with non root access and then use
> the
> >> >>  iproute2 wrapper with suid or sudo to setup its
> configuration.
> >> >> 
> >> >>  Alon.
> >> >> >>> I have no root access on the telephone. But Android 4.0
> >> >> >>> provides an API for VPNs
> >> >> >>>
> >> >>
> >>
> (http://developer.android.com/reference/android/net/VpnService.html).
> >> >> >>> Looking at my method at the method that opens the tun device
> >> >> >>> to passed over managment socket might also give an idea how
> it
> >> >> >>> is done
> >> >> in Android:
> >> >> >>> http://code.google.com/p/ics-
> >> >> openvpn/source/browse/src/de/blinkt/ope
> >> >> >>> nvpn/OpenVpnService.java#220
> >> >> >>>
> >> >> >>> Arne

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

Thank you,

Yes, I understand.

If I narrow this to "feature requests", basically we say that:
1. we want direct tun management to the management interface.
2. we want to have some logic when openvpn socket is opened.
3. Pass pre opened tun.

(1)  - direct tun management to the management interface

Until now I thought it should go to the plugin interface as in any
privilege separation model, the user will not be able to do any change
in networking.

But... I think it will be fairly simple to do so, with the new tun
interface[1] I am working of.

It introduces a tun engine, with a standard interface, it will be easy
to support several tun engines at same time selecting one by
configuration.

So we can have tun-engine-management.c to delegate all to the
management interface. It can be used if management interface is tcp as
well...

For example the linux tune engine[2] is very simple.

A management engine can be stacked overriding the tun_ifconfig, tun_init*.

BUT: I still think that currently it will be much simpler to do this
using iproute2 wrapper that uses the android API.

For (2) - custom socket creation

I still think that the plugin API is the right approach, you simply
implement openvpn-plugin-android, that opens the socket for the
openvpn process. It is not more complex than passing this via the
management interface, and can be used if management interface is not
unix domain socket...

(3) pre opened tun

This should be simple, as fd can be created and inherited by the
openvpn process.

What do you think?

Alon


[1] https://github.com/alonbl/openvpn/tree/tun
[2] 
https://github.com/alonbl/openvpn/blob/0205f085e8b77c6a6d49c38f20f9e49f41154f61/src/openvpn/tun-engine-linux.c

On Thu, May 10, 2012 at 10:00 AM, Adriaan de Jong  wrote:
> That would be another option. In the model we were using (which might be 
> different), the order is as follows:
>
> 1. openvpn is started
> 2. openvpn opens a socket to the remote host
> 2. openvpn establishes the control channel across this socket
> 3. openvpn passes socket and control channel data (IP, routing, DNS, etc) 
> through the management interface to the android app
> 4. android app passes these to the VPNService and receives an opened tun
> 5. android app passes the tun to openvpn
> 6. openvpn proceeds as usual
>
> To answer your follow up:
> There's no need for the extra complexity of a plugin here. The management 
> interface is a great tool, completely separating OpenVPN from its management 
> interface.
>
> Adriaan
>
>> -Original Message-
>> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> Sent: donderdag 10 mei 2012 8:49
>> To: Adriaan de Jong
>> Cc: Arne Schwabe; openvpn-devel@lists.sourceforge.net
>> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
>>
>> On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong 
>> wrote:
>> >> -Original Message-
>> >> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> >> Sent: donderdag 10 mei 2012 2:10
>> >> To: Arne Schwabe
>> >> Cc: openvpn-devel@lists.sourceforge.net
>> >> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0
>> >> Changeset
>> >>
>> >> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe 
>> wrote:
>> >> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
>> >> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe 
>> >> wrote:
>> >>  I need a better description of the tun process... so far I did
>> >>  not understand why you cannot use standard approach of creating
>> >>  persistent tun with non root access and then use the iproute2
>> >>  wrapper with suid or sudo to setup its configuration.
>> >> 
>> >>  Alon.
>> >> >>> I have no root access on the telephone. But Android 4.0 provides
>> >> >>> an API for VPNs
>> >> >>>
>> >>
>> (http://developer.android.com/reference/android/net/VpnService.html).
>> >> >>> Looking at my method at the method that opens the tun device to
>> >> >>> passed over managment socket might also give an idea how it is
>> >> >>> done
>> >> in Android:
>> >> >>> http://code.google.com/p/ics-
>> >> openvpn/source/browse/src/de/blinkt/ope
>> >> >>> nvpn/OpenVpnService.java#220
>> >> >>>
>> >> >>> Arne
>> >> >> I understand.
>> >> >>
>> >> >> But... let's discuss another approach...
>> >> >>
>> >> >> Implement android-ip program that uses the Android API, and put
>> >> >> "iproute2 android-ip" in configuration.
>> >> >>
>> >> >> Now, the interface of the program is similar to what iproute is
>> >> >> receiving, but instead of netlink it does android API.
>> >> >>
>> >> >> So actually you can receive requests from openvpn via this
>> >> >> interface without modifying openvpn...
>> >> >>
>> >> >> Maybe I am missing something, please bear with me.
>> >> >>
>> >> > The android API in this case is Java.  There is no C API that can
>> >> > be used. Opening the tun device requires passing the fd of the tun
>> >> device
>> >> > to openvpn. Also the for sockets that should not be routed over
>> the
>> >> > tun device the Java API provides

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Adriaan de Jong]

That would be another option. In the model we were using (which might be 
different), the order is as follows:

1. openvpn is started
2. openvpn opens a socket to the remote host
2. openvpn establishes the control channel across this socket
3. openvpn passes socket and control channel data (IP, routing, DNS, etc) 
through the management interface to the android app
4. android app passes these to the VPNService and receives an opened tun 
5. android app passes the tun to openvpn
6. openvpn proceeds as usual

To answer your follow up:
There's no need for the extra complexity of a plugin here. The management 
interface is a great tool, completely separating OpenVPN from its management 
interface.

Adriaan

> -Original Message-
> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> Sent: donderdag 10 mei 2012 8:49
> To: Adriaan de Jong
> Cc: Arne Schwabe; openvpn-devel@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
> 
> On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong 
> wrote:
> >> -Original Message-
> >> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> >> Sent: donderdag 10 mei 2012 2:10
> >> To: Arne Schwabe
> >> Cc: openvpn-devel@lists.sourceforge.net
> >> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0
> >> Changeset
> >>
> >> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe 
> wrote:
> >> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
> >> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe 
> >> wrote:
> >>  I need a better description of the tun process... so far I did
> >>  not understand why you cannot use standard approach of creating
> >>  persistent tun with non root access and then use the iproute2
> >>  wrapper with suid or sudo to setup its configuration.
> >> 
> >>  Alon.
> >> >>> I have no root access on the telephone. But Android 4.0 provides
> >> >>> an API for VPNs
> >> >>>
> >>
> (http://developer.android.com/reference/android/net/VpnService.html).
> >> >>> Looking at my method at the method that opens the tun device to
> >> >>> passed over managment socket might also give an idea how it is
> >> >>> done
> >> in Android:
> >> >>> http://code.google.com/p/ics-
> >> openvpn/source/browse/src/de/blinkt/ope
> >> >>> nvpn/OpenVpnService.java#220
> >> >>>
> >> >>> Arne
> >> >> I understand.
> >> >>
> >> >> But... let's discuss another approach...
> >> >>
> >> >> Implement android-ip program that uses the Android API, and put
> >> >> "iproute2 android-ip" in configuration.
> >> >>
> >> >> Now, the interface of the program is similar to what iproute is
> >> >> receiving, but instead of netlink it does android API.
> >> >>
> >> >> So actually you can receive requests from openvpn via this
> >> >> interface without modifying openvpn...
> >> >>
> >> >> Maybe I am missing something, please bear with me.
> >> >>
> >> > The android API in this case is Java.  There is no C API that can
> >> > be used. Opening the tun device requires passing the fd of the tun
> >> device
> >> > to openvpn. Also the for sockets that should not be routed over
> the
> >> > tun device the Java API provides a protect(int fd) API. That means
> >> the
> >> > socket from openvpn needs to passed to the Java GUI to call the
> >> > protect method.
> >> >
> >> > I see 2 way to accomplish this:
> >> >
> >> > - Using the the java native interface to directly call into java
> >> > from c and vice versa. This worked but since openvpn was not
> really
> >> > usable as a library I got other problem (the google code
> repository
> >> > has earlier version of the code which uses this.)
> >> > - Keep openvpn as seperate process and pass the fd over a unix
> >> socket.
> >> > (One of the more obscure Unix apis)
> >> >
> >> > The requirement that all information as ip addresses, dns and
> >> > routes must be available means that the persist-tun device cannot
> >> > be used if I also want to be to use pull.
> >> >
> >> > Calling an external programs could eliminate the "ROUTE" , "DNS",
> >> > "DOMAIN" , "IFCONFIG" management commands I have introduced. But
> >> > the patched implements also two fd passing managment commands
> >> > "PROTECT-
> >> FD"
> >> > (passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI
> >> > to openvpn).
> >> >
> >> > Arne
> >> >
> >>
> >> Great, so we can first shrink the patch!
> >>
> >> So two features you implied...
> >>
> >> 1. pass pre-opened tun device
> >>
> >> are you sure there are no alternatives to this? how does the java
> api
> >> receives the handle anyway?
> >>
> >
> > I agree with Arne's approach of letting the tun driver be passed
> through the management interface. This is the way things work in
> Android VPNService land. I still need to go through the code though.
> >
> >> 2. the "protect" API.
> >>
> >> Can you please explain more about the functionality of the "protect"
> >> API? why is this actually required? maybe there are alternatives.
> >>
> >
> > About the protect API: The VPNService API r

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

On Thu, May 10, 2012 at 9:49 AM, Alon Bar-Lev  wrote:
> On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong  wrote:
>>> -Original Message-
>>> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>>> Sent: donderdag 10 mei 2012 2:10
>>> To: Arne Schwabe
>>> Cc: openvpn-devel@lists.sourceforge.net
>>> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
>>>
>>> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe  wrote:
>>> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
>>> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe 
>>> wrote:
>>>  I need a better description of the tun process... so far I did not
>>>  understand why you cannot use standard approach of creating
>>>  persistent tun with non root access and then use the iproute2
>>>  wrapper with suid or sudo to setup its configuration.
>>> 
>>>  Alon.
>>> >>> I have no root access on the telephone. But Android 4.0 provides an
>>> >>> API for VPNs
>>> >>>
>>> (http://developer.android.com/reference/android/net/VpnService.html).
>>> >>> Looking at my method at the method that opens the tun device to
>>> >>> passed over managment socket might also give an idea how it is done
>>> in Android:
>>> >>> http://code.google.com/p/ics-
>>> openvpn/source/browse/src/de/blinkt/ope
>>> >>> nvpn/OpenVpnService.java#220
>>> >>>
>>> >>> Arne
>>> >> I understand.
>>> >>
>>> >> But... let's discuss another approach...
>>> >>
>>> >> Implement android-ip program that uses the Android API, and put
>>> >> "iproute2 android-ip" in configuration.
>>> >>
>>> >> Now, the interface of the program is similar to what iproute is
>>> >> receiving, but instead of netlink it does android API.
>>> >>
>>> >> So actually you can receive requests from openvpn via this interface
>>> >> without modifying openvpn...
>>> >>
>>> >> Maybe I am missing something, please bear with me.
>>> >>
>>> > The android API in this case is Java.  There is no C API that can be
>>> > used. Opening the tun device requires passing the fd of the tun
>>> device
>>> > to openvpn. Also the for sockets that should not be routed over the
>>> > tun device the Java API provides a protect(int fd) API. That means
>>> the
>>> > socket from openvpn needs to passed to the Java GUI to call the
>>> > protect method.
>>> >
>>> > I see 2 way to accomplish this:
>>> >
>>> > - Using the the java native interface to directly call into java from
>>> > c and vice versa. This worked but since openvpn was not really usable
>>> > as a library I got other problem (the google code repository has
>>> > earlier version of the code which uses this.)
>>> > - Keep openvpn as seperate process and pass the fd over a unix
>>> socket.
>>> > (One of the more obscure Unix apis)
>>> >
>>> > The requirement that all information as ip addresses, dns and routes
>>> > must be available means that the persist-tun device cannot be used if
>>> > I also want to be to use pull.
>>> >
>>> > Calling an external programs could eliminate the "ROUTE" , "DNS",
>>> > "DOMAIN" , "IFCONFIG" management commands I have introduced. But the
>>> > patched implements also two fd passing managment commands "PROTECT-
>>> FD"
>>> > (passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to
>>> > openvpn).
>>> >
>>> > Arne
>>> >
>>>
>>> Great, so we can first shrink the patch!
>>>
>>> So two features you implied...
>>>
>>> 1. pass pre-opened tun device
>>>
>>> are you sure there are no alternatives to this? how does the java api
>>> receives the handle anyway?
>>>
>>
>> I agree with Arne's approach of letting the tun driver be passed through the 
>> management interface. This is the way things work in Android VPNService 
>> land. I still need to go through the code though.
>>
>>> 2. the "protect" API.
>>>
>>> Can you please explain more about the functionality of the "protect"
>>> API? why is this actually required? maybe there are alternatives.
>>>
>>
>> About the protect API: The VPNService API routes all traffic through the VPN 
>> by default. The socket used by OpenVPN needs to be "protected" from this, 
>> using a special function call. Therefore, Android Java needs this call.
>
> Thanks!
>
> So why can't we simply open the socket at the UI as well? similar to the tun?
>
> Alon.

Or add this functionality to plugin interface?

Alon.

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong  wrote:
>> -Original Message-
>> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
>> Sent: donderdag 10 mei 2012 2:10
>> To: Arne Schwabe
>> Cc: openvpn-devel@lists.sourceforge.net
>> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
>>
>> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe  wrote:
>> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
>> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe 
>> wrote:
>>  I need a better description of the tun process... so far I did not
>>  understand why you cannot use standard approach of creating
>>  persistent tun with non root access and then use the iproute2
>>  wrapper with suid or sudo to setup its configuration.
>> 
>>  Alon.
>> >>> I have no root access on the telephone. But Android 4.0 provides an
>> >>> API for VPNs
>> >>>
>> (http://developer.android.com/reference/android/net/VpnService.html).
>> >>> Looking at my method at the method that opens the tun device to
>> >>> passed over managment socket might also give an idea how it is done
>> in Android:
>> >>> http://code.google.com/p/ics-
>> openvpn/source/browse/src/de/blinkt/ope
>> >>> nvpn/OpenVpnService.java#220
>> >>>
>> >>> Arne
>> >> I understand.
>> >>
>> >> But... let's discuss another approach...
>> >>
>> >> Implement android-ip program that uses the Android API, and put
>> >> "iproute2 android-ip" in configuration.
>> >>
>> >> Now, the interface of the program is similar to what iproute is
>> >> receiving, but instead of netlink it does android API.
>> >>
>> >> So actually you can receive requests from openvpn via this interface
>> >> without modifying openvpn...
>> >>
>> >> Maybe I am missing something, please bear with me.
>> >>
>> > The android API in this case is Java.  There is no C API that can be
>> > used. Opening the tun device requires passing the fd of the tun
>> device
>> > to openvpn. Also the for sockets that should not be routed over the
>> > tun device the Java API provides a protect(int fd) API. That means
>> the
>> > socket from openvpn needs to passed to the Java GUI to call the
>> > protect method.
>> >
>> > I see 2 way to accomplish this:
>> >
>> > - Using the the java native interface to directly call into java from
>> > c and vice versa. This worked but since openvpn was not really usable
>> > as a library I got other problem (the google code repository has
>> > earlier version of the code which uses this.)
>> > - Keep openvpn as seperate process and pass the fd over a unix
>> socket.
>> > (One of the more obscure Unix apis)
>> >
>> > The requirement that all information as ip addresses, dns and routes
>> > must be available means that the persist-tun device cannot be used if
>> > I also want to be to use pull.
>> >
>> > Calling an external programs could eliminate the "ROUTE" , "DNS",
>> > "DOMAIN" , "IFCONFIG" management commands I have introduced. But the
>> > patched implements also two fd passing managment commands "PROTECT-
>> FD"
>> > (passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to
>> > openvpn).
>> >
>> > Arne
>> >
>>
>> Great, so we can first shrink the patch!
>>
>> So two features you implied...
>>
>> 1. pass pre-opened tun device
>>
>> are you sure there are no alternatives to this? how does the java api
>> receives the handle anyway?
>>
>
> I agree with Arne's approach of letting the tun driver be passed through the 
> management interface. This is the way things work in Android VPNService land. 
> I still need to go through the code though.
>
>> 2. the "protect" API.
>>
>> Can you please explain more about the functionality of the "protect"
>> API? why is this actually required? maybe there are alternatives.
>>
>
> About the protect API: The VPNService API routes all traffic through the VPN 
> by default. The socket used by OpenVPN needs to be "protected" from this, 
> using a special function call. Therefore, Android Java needs this call.

Thanks!

So why can't we simply open the socket at the UI as well? similar to the tun?

Alon.

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Adriaan de Jong]

> -Original Message-
> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com]
> Sent: donderdag 10 mei 2012 2:10
> To: Arne Schwabe
> Cc: openvpn-devel@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset
> 
> On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe  wrote:
> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe 
> wrote:
>  I need a better description of the tun process... so far I did not
>  understand why you cannot use standard approach of creating
>  persistent tun with non root access and then use the iproute2
>  wrapper with suid or sudo to setup its configuration.
> 
>  Alon.
> >>> I have no root access on the telephone. But Android 4.0 provides an
> >>> API for VPNs
> >>>
> (http://developer.android.com/reference/android/net/VpnService.html).
> >>> Looking at my method at the method that opens the tun device to
> >>> passed over managment socket might also give an idea how it is done
> in Android:
> >>> http://code.google.com/p/ics-
> openvpn/source/browse/src/de/blinkt/ope
> >>> nvpn/OpenVpnService.java#220
> >>>
> >>> Arne
> >> I understand.
> >>
> >> But... let's discuss another approach...
> >>
> >> Implement android-ip program that uses the Android API, and put
> >> "iproute2 android-ip" in configuration.
> >>
> >> Now, the interface of the program is similar to what iproute is
> >> receiving, but instead of netlink it does android API.
> >>
> >> So actually you can receive requests from openvpn via this interface
> >> without modifying openvpn...
> >>
> >> Maybe I am missing something, please bear with me.
> >>
> > The android API in this case is Java.  There is no C API that can be
> > used. Opening the tun device requires passing the fd of the tun
> device
> > to openvpn. Also the for sockets that should not be routed over the
> > tun device the Java API provides a protect(int fd) API. That means
> the
> > socket from openvpn needs to passed to the Java GUI to call the
> > protect method.
> >
> > I see 2 way to accomplish this:
> >
> > - Using the the java native interface to directly call into java from
> > c and vice versa. This worked but since openvpn was not really usable
> > as a library I got other problem (the google code repository has
> > earlier version of the code which uses this.)
> > - Keep openvpn as seperate process and pass the fd over a unix
> socket.
> > (One of the more obscure Unix apis)
> >
> > The requirement that all information as ip addresses, dns and routes
> > must be available means that the persist-tun device cannot be used if
> > I also want to be to use pull.
> >
> > Calling an external programs could eliminate the "ROUTE" , "DNS",
> > "DOMAIN" , "IFCONFIG" management commands I have introduced. But the
> > patched implements also two fd passing managment commands "PROTECT-
> FD"
> > (passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to
> > openvpn).
> >
> > Arne
> >
> 
> Great, so we can first shrink the patch!
> 
> So two features you implied...
> 
> 1. pass pre-opened tun device
> 
> are you sure there are no alternatives to this? how does the java api
> receives the handle anyway?
> 

I agree with Arne's approach of letting the tun driver be passed through the 
management interface. This is the way things work in Android VPNService land. I 
still need to go through the code though.

> 2. the "protect" API.
> 
> Can you please explain more about the functionality of the "protect"
> API? why is this actually required? maybe there are alternatives.
> 

About the protect API: The VPNService API routes all traffic through the VPN by 
default. The socket used by OpenVPN needs to be "protected" from this, using a 
special function call. Therefore, Android Java needs this call.

Adriaan

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Alon Bar-Lev]

On Thu, May 10, 2012 at 3:01 AM, Arne Schwabe  wrote:
> Am 10.05.12 01:39, schrieb Alon Bar-Lev:
>> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe  wrote:
 I need a better description of the tun process... so far I did not
 understand why you cannot use standard approach of creating persistent
 tun with non root access and then use the iproute2 wrapper with suid
 or sudo to setup its configuration.

 Alon.
>>> I have no root access on the telephone. But Android 4.0 provides an API
>>> for VPNs
>>> (http://developer.android.com/reference/android/net/VpnService.html).
>>> Looking at my method at the method that opens the tun device to passed
>>> over managment socket might also give an idea how it is done in Android:
>>> http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/OpenVpnService.java#220
>>>
>>> Arne
>> I understand.
>>
>> But... let's discuss another approach...
>>
>> Implement android-ip program that uses the Android API, and put
>> "iproute2 android-ip" in configuration.
>>
>> Now, the interface of the program is similar to what iproute is
>> receiving, but instead of netlink it does android API.
>>
>> So actually you can receive requests from openvpn via this interface
>> without modifying openvpn...
>>
>> Maybe I am missing something, please bear with me.
>>
> The android API in this case is Java.  There is no C API that can be
> used. Opening the tun device requires passing the fd of the tun device
> to openvpn. Also the for sockets that should not be routed over the tun
> device the Java API provides a protect(int fd) API. That means the
> socket from openvpn needs to passed to the Java GUI to call the protect
> method.
>
> I see 2 way to accomplish this:
>
> - Using the the java native interface to directly call into java from c
> and vice versa. This worked but since openvpn was not really usable as a
> library I got other problem (the google code repository has earlier
> version of the code which uses this.)
> - Keep openvpn as seperate process and pass the fd over a unix socket.
> (One of the more obscure Unix apis)
>
> The requirement that all information as ip addresses, dns and routes
> must be available means that the persist-tun device cannot be used if I
> also want to be to use pull.
>
> Calling an external programs could eliminate the "ROUTE" , "DNS",
> "DOMAIN" , "IFCONFIG" management commands I have introduced. But the
> patched implements also two fd passing managment commands "PROTECT-FD"
> (passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to
> openvpn).
>
> Arne
>

Great, so we can first shrink the patch!

So two features you implied...

1. pass pre-opened tun device

are you sure there are no alternatives to this? how does the java api
receives the handle anyway?

2. the "protect" API.

Can you please explain more about the functionality of the "protect"
API? why is this actually required? maybe there are alternatives.

Alon.

Re: [Openvpn-devel] [PATCH] Openvpn for Android 4.0 Changeset

[Arne Schwabe]

Am 10.05.12 01:39, schrieb Alon Bar-Lev:
> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe  wrote:
>>> I need a better description of the tun process... so far I did not
>>> understand why you cannot use standard approach of creating persistent
>>> tun with non root access and then use the iproute2 wrapper with suid
>>> or sudo to setup its configuration.
>>>
>>> Alon.
>> I have no root access on the telephone. But Android 4.0 provides an API
>> for VPNs
>> (http://developer.android.com/reference/android/net/VpnService.html).
>> Looking at my method at the method that opens the tun device to passed
>> over managment socket might also give an idea how it is done in Android:
>> http://code.google.com/p/ics-openvpn/source/browse/src/de/blinkt/openvpn/OpenVpnService.java#220
>>
>> Arne
> I understand.
>
> But... let's discuss another approach...
>
> Implement android-ip program that uses the Android API, and put
> "iproute2 android-ip" in configuration.
>
> Now, the interface of the program is similar to what iproute is
> receiving, but instead of netlink it does android API.
>
> So actually you can receive requests from openvpn via this interface
> without modifying openvpn...
>
> Maybe I am missing something, please bear with me.
>
The android API in this case is Java.  There is no C API that can be
used. Opening the tun device requires passing the fd of the tun device
to openvpn. Also the for sockets that should not be routed over the tun
device the Java API provides a protect(int fd) API. That means the
socket from openvpn needs to passed to the Java GUI to call the protect
method.

I see 2 way to accomplish this:

- Using the the java native interface to directly call into java from c
and vice versa. This worked but since openvpn was not really usable as a
library I got other problem (the google code repository has earlier
version of the code which uses this.)
- Keep openvpn as seperate process and pass the fd over a unix socket.
(One of the more obscure Unix apis)

The requirement that all information as ip addresses, dns and routes
must be available means that the persist-tun device cannot be used if I
also want to be to use pull.

Calling an external programs could eliminate the "ROUTE" , "DNS",
"DOMAIN" , "IFCONFIG" management commands I have introduced. But the
patched implements also two fd passing managment commands "PROTECT-FD"
(passes fd from openvpn to GUI) and "OPENTUN" (passes fd from GUI to
openvpn).

Arne