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

[Gert Doering]

Hi,

On Fri, May 11, 2012 at 11:52:22PM +0200, Arne Schwabe wrote:
> Am 11.05.12 20:56, schrieb Gert Doering:
> > Changing the build environment to build a shared library out of openvpn
> > is something I do not fully understand yet, though - and don't view
> > a particular useful goal right now.
> The shared library is not used as real shared library. I build
> libopenvpn as complete library and then build a miniature executable
> that calls the main method of the shared library and therefore exactly
> behaves like openvpn as executable.
> 
> The reason for this is that libraries are managed by the android package
> system. For executables I have to carry them as data files and write
> them to a cache partition. By putting the main  code into the library I
> can minimise the amount of data that is written twice to the /data
> parition on Android.

I'm still not sure I fully understand what Android is doing there - but
I don't need to :-) - so that explanation is good enough for me.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpKO2T1MYLP3.pgp
Description: PGP signature

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

[Arne Schwabe]

>> I would like you to try to do so using libtool...
>>
>> Just replace:
>> ---
>> sbin_PROGRAMS = openvpn
>> openvpn_SOURCES = 
>> ---
>> with:
>> ---
>> lib_LTLIBRARIES = openvpn.la
>> openvpn_la_SOURCES = ...
>> openvpn_la_LDFLAGS = \
>>-module -shared -avoid-version -no-undefined
>> ---
>>
>> And add -Dmain=openvpn_main to AM_CFLAGS.
>>
>> Alon.
> You should also change:
> ---
> openvpn_LDADD = ...
> ---
> to:
> ---
> openvpn_la_LDADD = ...
> ---
I can try this sometime later but for the moment I happy with building
the openvpn with the android ndk build system as there a other things
that I prefer to tweaking the build system.

Arne

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

[Arne Schwabe]

Am 11.05.12 20:56, schrieb Gert Doering:
> Changing the build environment to build a shared library out of openvpn
> is something I do not fully understand yet, though - and don't view
> a particular useful goal right now.
The shared library is not used as real shared library. I build
libopenvpn as complete library and then build a miniature executable
that calls the main method of the shared library and therefore exactly
behaves like openvpn as executable.

The reason for this is that libraries are managed by the android package
system. For executables I have to carry them as data files and write
them to a cache partition. By putting the main  code into the library I
can minimise the amount of data that is written twice to the /data
parition on Android.

The building as library and using android build system should seen as
something that is useful for my particular Android application and not
as a general thing or requirement.

Arne

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

[Alon Bar-Lev]

On Sat, May 12, 2012 at 12:56 AM, Alon Bar-Lev  wrote:
> On Sat, May 12, 2012 at 12:52 AM, Arne Schwabe  
> wrote:
>> Am 11.05.12 20:56, schrieb Gert Doering:
>>> Changing the build environment to build a shared library out of openvpn
>>> is something I do not fully understand yet, though - and don't view
>>> a particular useful goal right now.
>> The shared library is not used as real shared library. I build
>> libopenvpn as complete library and then build a miniature executable
>> that calls the main method of the shared library and therefore exactly
>> behaves like openvpn as executable.
>>
>> The reason for this is that libraries are managed by the android package
>> system. For executables I have to carry them as data files and write
>> them to a cache partition. By putting the main  code into the library I
>> can minimise the amount of data that is written twice to the /data
>> parition on Android.
>>
>> The building as library and using android build system should seen as
>> something that is useful for my particular Android application and not
>> as a general thing or requirement.
>>
>> Arne
>>
>
> I would like you to try to do so using libtool...
>
> Just replace:
> ---
> sbin_PROGRAMS = openvpn
> openvpn_SOURCES = 
> ---
> with:
> ---
> lib_LTLIBRARIES = openvpn.la
> openvpn_la_SOURCES = ...
> openvpn_la_LDFLAGS = \
>    -module -shared -avoid-version -no-undefined
> ---
>
> And add -Dmain=openvpn_main to AM_CFLAGS.
>
> Alon.

You should also change:
---
openvpn_LDADD = ...
---
to:
---
openvpn_la_LDADD = ...
---

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

[Alon Bar-Lev]

On Sat, May 12, 2012 at 12:52 AM, Arne Schwabe  wrote:
> Am 11.05.12 20:56, schrieb Gert Doering:
>> Changing the build environment to build a shared library out of openvpn
>> is something I do not fully understand yet, though - and don't view
>> a particular useful goal right now.
> The shared library is not used as real shared library. I build
> libopenvpn as complete library and then build a miniature executable
> that calls the main method of the shared library and therefore exactly
> behaves like openvpn as executable.
>
> The reason for this is that libraries are managed by the android package
> system. For executables I have to carry them as data files and write
> them to a cache partition. By putting the main  code into the library I
> can minimise the amount of data that is written twice to the /data
> parition on Android.
>
> The building as library and using android build system should seen as
> something that is useful for my particular Android application and not
> as a general thing or requirement.
>
> Arne
>

I would like you to try to do so using libtool...

Just replace:
---
sbin_PROGRAMS = openvpn
openvpn_SOURCES = 
---
with:
---
lib_LTLIBRARIES = openvpn.la
openvpn_la_SOURCES = ...
openvpn_la_LDFLAGS = \
-module -shared -avoid-version -no-undefined
---

And add -Dmain=openvpn_main to AM_CFLAGS.

Alon.

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

[Gert Doering]

Hi,

On Fri, May 11, 2012 at 12:07:40AM +0200, Arne Schwabe wrote:
> * 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.

I don't think we can really support that anyway - the IETF has deprecated 
this sort of netmasks in RFC1519 (introduction of CIDR, section 4.2), and 
all major operating systems do not support it anymore.

So the server side would not be able to handle that, unless running
on Android as well...

I'm not sure whether the openvpn code currently enforces it, but I
*am* sure that it will explode on Linux and FreeBSD as soon as you 
try to actually ifconfig/route such networks.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpRcTjRBIcKr.pgp
Description: PGP signature

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

[Alon Bar-Lev]

On Fri, May 11, 2012 at 3:28 PM, Fabian Knittel
 wrote:
> Hi Alon,
>
> 2012/5/11 Alon Bar-Lev :
>> On Fri, May 11, 2012 at 12:11 AM, Fabian Knittel
>>  wrote:
>>> 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?
>>
>> Again, this is not the case of privileged separation as the process
>> *IS* privileged to do the networking setup.
>> People, don't get confused between running under root or not with privileges!
>> Regular user can have privileges like creating tun and modify network
>> setting without being root, as in this case, this is not privilege
>> separation!
>
> To be honest, I'm not sure what you're talking about.

Sorry about that.

> My point was,
> that the ideas and approaches gathered in the wiki[0] might influence
> the interface we're discussing right now. Specifically, Heiko's
> interactive service would probably need a similar interface. (In your
> COM+-approach this would be the interface between OpenVPNUI.Network
> and OpenVPNUI.Tunnel, but as you're suggesting to use COM+, the shape
> of an advanced management interface or unix-domain-socket-like
> interface is ... of no real value.)

In the windows case I also demonstrated that a simpler solution can be
implemented without modifying the way openvpn behaves in term of
management interface.

>
> 0: https://community.openvpn.net/openvpn/wiki/PrivilegeSeparation
>
>> And again, these UI specific issues should should be modularize and
>> not go into mainline as-is.
>
> My point was, that we should agree on a stable interface first. In the
> next step, we can decide whether a specific implementation of that
> interface is worthy of inclusion.

This is good, but we cannot discuss interfaces if people role out the
possibility of different solutions.

> Unless of course, you're thinking
> about COM+ as one of the UI interfaces. But in my opinion, if Windows
> has a communication channel that is close to the semantics and
> capabilities of a UNIX domain socket, we should probably use that as
> _the_ interface and not needlessly start maintaining a separate
> interface per UI/plattform.

*YES* the COM+ approach shows that the OpenVPN-GUI project can use
*EXISTING* openvpn (maybe with minor modifications), and provide the
full *SOLUTION* for windows platform including privilege separation.

This by providing the COM+ objects and optional plugins.

This way the windows specific solution can be maintained completely
independently.

The same applies to this solution as well.
If we can do this without introducing android specific code into the
core, but reach to a state that all can be implemented in a plugin,
then the android solution will be maintained by appropriate interested
parties.

BTW: both windows and android has something in common - the need for
performing the ip setting in plugin.

in windows case, the UI may implement a plugin to call the
OpenVPNUI.Network object.
in the android case, the UI may implement a plugin to call the
management interface.
So we need this anyway.

> [...]
>> The question is do we want to make a library out of VPN with some
>> interface such as openvpn_main() or not, the JNI question is totally
>> unrelated to the mainline project.
>
> I agree that your question is more to the point.
>
> My opinion regarding the question is, that I don't yet see a need for
> a library interface. Executable + unix domain sockets seem just fine.

Right, for now it is sufficient.

>>> * The precise names of the newly introduced management commands.
>>
>> If we provide plugin interface to management interface this can be a
>> contract between the UI and the plugin, so that mainline should not be
>> changed every time there is a special UI need.
>
> If we create a contract that can be upheld by both a plugin and the
> core, then we can agree on the contract first and agree or change the
> implementation of the contract later. If we take several UI needs into
> consideration, we might not need a zoo of management-UI-plugins.

I don't think we will be able to avoid a plugin per special UI need...
But I am sure we can avoid modifying the core code every time a new
special UI appears.

>> If we provide tun engine implementation that supports the management
>> interface, all platforms can benefit from this change.
>
> Sounds great. Why not make the management interface contract of that
> tun engine the main topic of this discussion? That's what I'm aiming
> at. That way, hopefully the short-term patch can go in and the
> contract won't need to change as soon as 2.4 delivers the advanced
> modularisation.

I don't believe in 

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

[Gert Doering]

Hi,

On Thu, May 10, 2012 at 03:42:53PM +0300, Samuli Seppänen wrote:
> 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.

The main problem on iThings right now is not the license but the 
missing access to their internal VPN API - and to use classic
tun devices you need root access...

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpFKvIGeEpD3.pgp
Description: PGP signature

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

[Gert Doering]

Hi,

On Thu, May 10, 2012 at 09:00:05AM +0200, 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

This looks very reasonable to me.

(As for the patch itself, I had no time to go through it yet, sorry)

Changing the build environment to build a shared library out of openvpn
is something I do not fully understand yet, though - and don't view
a particular useful goal right now.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpdrmmRXkF6D.pgp
Description: PGP signature

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

[Fabian Knittel]

Hi Alon,

2012/5/11 Alon Bar-Lev :
> On Fri, May 11, 2012 at 12:11 AM, Fabian Knittel
>  wrote:
>> 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?
>
> Again, this is not the case of privileged separation as the process
> *IS* privileged to do the networking setup.
> People, don't get confused between running under root or not with privileges!
> Regular user can have privileges like creating tun and modify network
> setting without being root, as in this case, this is not privilege
> separation!

To be honest, I'm not sure what you're talking about. My point was,
that the ideas and approaches gathered in the wiki[0] might influence
the interface we're discussing right now. Specifically, Heiko's
interactive service would probably need a similar interface. (In your
COM+-approach this would be the interface between OpenVPNUI.Network
and OpenVPNUI.Tunnel, but as you're suggesting to use COM+, the shape
of an advanced management interface or unix-domain-socket-like
interface is ... of no real value.)

0: https://community.openvpn.net/openvpn/wiki/PrivilegeSeparation

> And again, these UI specific issues should should be modularize and
> not go into mainline as-is.

My point was, that we should agree on a stable interface first. In the
next step, we can decide whether a specific implementation of that
interface is worthy of inclusion. Unless of course, you're thinking
about COM+ as one of the UI interfaces. But in my opinion, if Windows
has a communication channel that is close to the semantics and
capabilities of a UNIX domain socket, we should probably use that as
_the_ interface and not needlessly start maintaining a separate
interface per UI/plattform.

[...]
> The question is do we want to make a library out of VPN with some
> interface such as openvpn_main() or not, the JNI question is totally
> unrelated to the mainline project.

I agree that your question is more to the point.

My opinion regarding the question is, that I don't yet see a need for
a library interface. Executable + unix domain sockets seem just fine.

>> * The precise names of the newly introduced management commands.
>
> If we provide plugin interface to management interface this can be a
> contract between the UI and the plugin, so that mainline should not be
> changed every time there is a special UI need.

If we create a contract that can be upheld by both a plugin and the
core, then we can agree on the contract first and agree or change the
implementation of the contract later. If we take several UI needs into
consideration, we might not need a zoo of management-UI-plugins.

> If we provide tun engine implementation that supports the management
> interface, all platforms can benefit from this change.

Sounds great. Why not make the management interface contract of that
tun engine the main topic of this discussion? That's what I'm aiming
at. That way, hopefully the short-term patch can go in and the
contract won't need to change as soon as 2.4 delivers the advanced
modularisation.

Cheers
Fabian

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

[Alon Bar-Lev]

On Fri, May 11, 2012 at 12:11 AM, Fabian Knittel
 wrote:
> 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?

Again, this is not the case of privileged separation as the process
*IS* privileged to do the networking setup.
People, don't get confused between running under root or not with privileges!
Regular user can have privileges like creating tun and modify network
setting without being root, as in this case, this is not privilege
separation!

And again, these UI specific issues should should be modularize and
not go into mainline as-is.

> * How to call OpenVPN from Java. Via thin JNI wrapper or as a regular
>  executable.

Again, this is not the question.
The question is do we want to make a library out of VPN with some
interface such as openvpn_main() or not, the JNI question is totally
unrelated to the mainline project.

> * The precise names of the newly introduced management commands.

If we provide plugin interface to management interface this can be a
contract between the UI and the plugin, so that mainline should not be
changed every time there is a special UI need.

If we provide tun engine implementation that supports the management
interface, all platforms can benefit from this change.

>
> Anything else?
>
> Cheers
> Fabian

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] [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
> <dej...@fox-it.com> 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 
>>> <mendelt.siebe...@fox-it.com> 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 fea

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 <dej...@fox-it.com> 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
>> <mendelt.siebe...@fox-it.com> 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
> <mendelt.siebe...@fox-it.com> 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,

D

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]
<http://arstechnica.com/information-technology/2011/02/windows-phone-marketplace-bans-the-gpl-and-the-app-store-should-too>

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] [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
>> <dej...@fox-it.com> 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
>>>> 
&

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] [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 <dej...@fox-it.com>
> 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 <dej...@fox-it.com>
> >> 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 <a...@rfc2549.org>
> >> wrote:
> >> >> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
> >> >> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe
> >> >> >> <a...@rfc2549.org>
> >> >> wrote:
> >> >> >>>> I need a better description of the tun process... so far I
> >> >> >>>> did not understand why you

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 <dej...@fox-it.com> 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 <dej...@fox-it.com>
>> 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 <a...@rfc2549.org>
>> wrote:
>> >> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
>> >> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <a...@rfc2549.org>
>> >> 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.
>> >> >&

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 <dej...@fox-it.com>
> 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 <a...@rfc2549.org>
> wrote:
> >> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
> >> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <a...@rfc2549.org>
> >> 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.
> >

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 <alon.bar...@gmail.com> wrote:
> On Thu, May 10, 2012 at 9:35 AM, Adriaan de Jong <dej...@fox-it.com> 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 <a...@rfc2549.org> wrote:
>>> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
>>> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <a...@rfc2549.org>
>>> 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 <dej...@fox-it.com> 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 <a...@rfc2549.org> wrote:
>> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
>> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <a...@rfc2549.org>
>> 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 <a...@rfc2549.org> wrote:
> > Am 10.05.12 01:39, schrieb Alon Bar-Lev:
> >> On Thu, May 10, 2012 at 2:24 AM, Arne Schwabe <a...@rfc2549.org>
> 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

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

[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.

Alon.

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

[Arne Schwabe]

> 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

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

[Alon Bar-Lev]

On Thu, May 10, 2012 at 2:09 AM, Arne Schwabe  wrote:
> Am 10.05.12 00:50, schrieb Alon Bar-Lev:
>> On Thu, May 10, 2012 at 1:36 AM, Arne Schwabe  wrote:
>>> Am 10.05.12 00:09, schrieb Alon Bar-Lev:
 Hmmm... the fact that you are not using git, and create separate
 branch for the changes makes it very difficult to peak.
>>> Sorry. I am new to git and the distributed version systems. I hope this
>>> patch is better. I also pushed the changes to
>>> https://github.com/schwabe/openvpn/.
>> This is good but you need to rebase master... something like:
>> $ git checkout android
>> $ git rebase master
> I will try tommorow.
>
>>> Building with the android build system was easier for me. Openvpn is
>>> only build as a shared library but still used as a standalone
>>> executable. This has to do with the apk packaging and the android market.
>>> Transforming openvpn into a real library turned out to be more difficult
>>> because there multiple points in the code where openvpn more or less
>>> calls exit to clean up.
>> Yes, this is well known, someday we will have to deal with this. Maybe 
>> sooner...
>> Anyway, I can provide you with a branch that produce both executable
>> and library.
> That is really interesting for me and the android port.
>>> But before discussing the best way of building openvpn on android I
>>> would rather like to get input on the other changes.
>> Go over the patch, remove all changes that result from plain
>> indentation changes, or addition of new lines.
>>
>> I also don't understand why the log should be special, and you cannot
>> just use the management interface as-is.
>>
>> Please also try to avoid mixing windows code and posix code.
>>
>> Regarding the tun open, I don't understand why you cannot do this
>> before you execute the openvpn, as persisted tun device.
> Opening tun works as follows:
>
> - Provide information like ip, routes, dns and domain to Android
> - call establish() and get a tun with the specified parameters back.
>>
>> Bottom line, I don't think there is real need to define a new target
>> for android, almost every change you introduce has nothing to do with
>> platform specific.
> Yes. But I needed some target for android. The target mainly deal with
> how interface configuring/routes/ifconfig etc. is handled. With the
> Android 4.0 most of these things have to be done differently.
>> You should explain clearly why each change is needed... and probably
>> split it into own commit.
 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)
>>>
>> Right.
>>
>> If I understand correctly, if I leave out the library creation, and
>> the in-line tap creation, and the management log changes, there are
>> only minor changes, which should be explained one-by-one.
> Yes. The in line tun creation and the managment interface fd passing are
> the important changes of the patchset.
>
> Arne

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.

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

[Arne Schwabe]

Am 10.05.12 00:50, schrieb Alon Bar-Lev:
> On Thu, May 10, 2012 at 1:36 AM, Arne Schwabe  wrote:
>> Am 10.05.12 00:09, schrieb Alon Bar-Lev:
>>> Hmmm... the fact that you are not using git, and create separate
>>> branch for the changes makes it very difficult to peak.
>> Sorry. I am new to git and the distributed version systems. I hope this
>> patch is better. I also pushed the changes to
>> https://github.com/schwabe/openvpn/.
> This is good but you need to rebase master... something like:
> $ git checkout android
> $ git rebase master
I will try tommorow.

>> Building with the android build system was easier for me. Openvpn is
>> only build as a shared library but still used as a standalone
>> executable. This has to do with the apk packaging and the android market.
>> Transforming openvpn into a real library turned out to be more difficult
>> because there multiple points in the code where openvpn more or less
>> calls exit to clean up.
> Yes, this is well known, someday we will have to deal with this. Maybe 
> sooner...
> Anyway, I can provide you with a branch that produce both executable
> and library.
That is really interesting for me and the android port.
>> But before discussing the best way of building openvpn on android I
>> would rather like to get input on the other changes.
> Go over the patch, remove all changes that result from plain
> indentation changes, or addition of new lines.
>
> I also don't understand why the log should be special, and you cannot
> just use the management interface as-is.
>
> Please also try to avoid mixing windows code and posix code.
>
> Regarding the tun open, I don't understand why you cannot do this
> before you execute the openvpn, as persisted tun device.
Opening tun works as follows:

- Provide information like ip, routes, dns and domain to Android
- call establish() and get a tun with the specified parameters back.
>
> Bottom line, I don't think there is real need to define a new target
> for android, almost every change you introduce has nothing to do with
> platform specific.
Yes. But I needed some target for android. The target mainly deal with
how interface configuring/routes/ifconfig etc. is handled. With the
Android 4.0 most of these things have to be done differently.
> You should explain clearly why each change is needed... and probably
> split it into own commit.
>>> 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)
>>
> Right.
>
> If I understand correctly, if I leave out the library creation, and
> the in-line tap creation, and the management log changes, there are
> only minor changes, which should be explained one-by-one.
Yes. The in line tun creation and the managment interface fd passing are
the important changes of the patchset.

Arne

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

[Alon Bar-Lev]

On Thu, May 10, 2012 at 1:36 AM, Arne Schwabe  wrote:
> Am 10.05.12 00:09, schrieb Alon Bar-Lev:
>> Hmmm... the fact that you are not using git, and create separate
>> branch for the changes makes it very difficult to peak.
> Sorry. I am new to git and the distributed version systems. I hope this
> patch is better. I also pushed the changes to
> https://github.com/schwabe/openvpn/.

This is good but you need to rebase master... something like:
$ git checkout android
$ git rebase master

>> I see a mix of changes and a separate build system which I am not sure
>> is needed. You build openvpn as a shared library, it is OK, I had this
>> on my list, but why not use the current build to do so?
> Building with the android build system was easier for me. Openvpn is
> only build as a shared library but still used as a standalone
> executable. This has to do with the apk packaging and the android market.
> Transforming openvpn into a real library turned out to be more difficult
> because there multiple points in the code where openvpn more or less
> calls exit to clean up.

Yes, this is well known, someday we will have to deal with this. Maybe sooner...
Anyway, I can provide you with a branch that produce both executable
and library.

> But before discussing the best way of building openvpn on android I
> would rather like to get input on the other changes.

Go over the patch, remove all changes that result from plain
indentation changes, or addition of new lines.

I also don't understand why the log should be special, and you cannot
just use the management interface as-is.

Please also try to avoid mixing windows code and posix code.

Regarding the tun open, I don't understand why you cannot do this
before you execute the openvpn, as persisted tun device.

Bottom line, I don't think there is real need to define a new target
for android, almost every change you introduce has nothing to do with
platform specific.

You should explain clearly why each change is needed... and probably
split it into own commit.

>
>> 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)
>

Right.

If I understand correctly, if I leave out the library creation, and
the in-line tap creation, and the management log changes, there are
only minor changes, which should be explained one-by-one.

Regards,
Alon.

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

[Arne Schwabe]

Am 10.05.12 00:09, schrieb Alon Bar-Lev:
> Hmmm... the fact that you are not using git, and create separate
> branch for the changes makes it very difficult to peak.
Sorry. I am new to git and the distributed version systems. I hope this
patch is better. I also pushed the changes to
https://github.com/schwabe/openvpn/.

> I see a mix of changes and a separate build system which I am not sure
> is needed. You build openvpn as a shared library, it is OK, I had this
> on my list, but why not use the current build to do so?
Building with the android build system was easier for me. Openvpn is
only build as a shared library but still used as a standalone
executable. This has to do with the apk packaging and the android market.
Transforming openvpn into a real library turned out to be more difficult
because there multiple points in the code where openvpn more or less
calls exit to clean up.

But before discussing the best way of building openvpn on android I
would rather like to get input on the other changes.


> 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)

Arne
From b9a52d5ee919818a2e2ee525e0800e8e1f06b45f Mon Sep 17 00:00:00 2001
From: Arne Schwabe 
Date: Wed, 9 May 2012 23:18:31 +0200
Subject: [PATCH 1/1] Openvpn for Android ICS API

---
 src/openvpn/error.c   |2 +-
 src/openvpn/event.c   |4 ++
 src/openvpn/init.c|   12 +-
 src/openvpn/manage.c  |   99 -
 src/openvpn/manage.h  |5 ++
 src/openvpn/options.c |   16 +--
 src/openvpn/route.c   |   16 +++-
 src/openvpn/socket.c  |   14 ++-
 src/openvpn/ssl.c |2 +
 src/openvpn/syshead.h |2 +-
 src/openvpn/tun.c |   51 -
 src/openvpn/tun.h |   22 ++-
 12 files changed, 228 insertions(+), 17 deletions(-)

diff --git a/src/openvpn/error.c b/src/openvpn/error.c
index d6ad639..e2e24b1 100644
--- a/src/openvpn/error.c
+++ b/src/openvpn/error.c
@@ -312,7 +312,7 @@ void x_msg (const unsigned int flags, const char *format, 
...)
}
 }
 
-  if (!(flags & M_MSG_VIRT_OUT))
+  if (!(flags & M_MSG_VIRT_OUT) )
 {
   if (use_syslog && !std_redir && !forked)
{
diff --git a/src/openvpn/event.c b/src/openvpn/event.c
index 2a13e1c..0463d98 100644
--- a/src/openvpn/event.c
+++ b/src/openvpn/event.c
@@ -753,6 +753,10 @@ po_wait (struct event_set *es, const struct timeval *tv, 
struct event_set_return
  ++out;
  ++j;
}
+  else if(pfdp->revents==0x0020) 
+{
+openvpn_exit (OPENVPN_EXIT_STATUS_ERROR);
+}
  else if (pfdp->revents)
{
  msg (D_EVENT_ERRORS, "Error: poll: unknown revents=0x%04x", 
(unsigned int)pfdp->revents);
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 61ced5d..17e4f4a 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1478,6 +1478,13 @@ do_open_tun (struct context *c)
  do_ifconfig (c->c1.tuntap, guess, TUN_MTU_SIZE (>c2.frame), 
c->c2.es);
}
 
+/* possibly add routes */
+if(ifconfig_order() == ROUTE_BEFORE_TUN) {
+if (!c->options.route_delay_defined)
+do_route (>options, c->c1.route_list, c->c1.route_ipv6_list,
+  c->c1.tuntap, c->plugins, c->c2.es);
+}
+
   /* open the tun device */
   open_tun (c->options.dev, c->options.dev_type, c->options.dev_node,
c->c1.tuntap);
@@ -1509,10 +1516,11 @@ do_open_tun (struct context *c)
   c->c2.es);
 
   /* possibly add routes */
+if(ifconfig_order() == ROUTE_AFTER_TUN) {
   if (!c->options.route_delay_defined)
do_route (>options, c->c1.route_list, c->c1.route_ipv6_list,
  c->c1.tuntap, c->plugins, c->c2.es);
-
+}
   /*
* Did tun/tap driver give us an MTU?
*/
@@ -2467,7 +2475,7 @@ do_option_warnings (struct context *c)
 {
   const struct options *o = >options;
 
-#if 1 /* JYFIXME -- port warning */
+#if 0 /* JYFIXME -- port warning */
   if (!o->ce.port_option_used && (o->ce.local_port == OPENVPN_PORT && 
o->ce.remote_port == OPENVPN_PORT))
 msg (M_WARN, "IMPORTANT: OpenVPN's default port number is now %d, based on 
an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier 
used 5000 as the default port.",
 OPENVPN_PORT);
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 141..f7ca8e1 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -58,6 +58,9 @@
 #define MANAGEMENT_ECHO_FLAGS 0
 #endif
 
+#include 
+
+
 /* tag for blank username/password */
 static const char blank_up[] = "[[BLANK]]";
 
@@ -66,6 +69,9 @@ struct management *management; /* GLOBAL */
 /* static forward declarations */
 static 

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

[Alon Bar-Lev]

Hmmm... the fact that you are not using git, and create separate
branch for the changes makes it very difficult to peak.

I see a mix of changes and a separate build system which I am not sure
is needed. You build openvpn as a shared library, it is OK, I had this
on my list, but why not use the current build to do so?

I suggest you clone the repository at github, create a branch and
order your changes.

Regards,
Alon Bar-Lev.

On Thu, May 10, 2012 at 12:24 AM, Arne Schwabe  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
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>