[OpenWrt-Devel,2/3] packaget/network/services/openvpn: Drop ifconfig/route in favour of ip

From: Daniel Dickinson <openwrt@daniel.thecshore.com>

NB: Only compile tested.

Stop depending on ifconfig/route and use busybox (or real)
iproute2 utility instead.  Depend on virtual ip package provided
by previous commit so as not to force a particular version of
the ip command.

Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
---
 package/network/services/openvpn/Config-nossl.in    | 4 ----
 package/network/services/openvpn/Config-openssl.in  | 4 ----
 package/network/services/openvpn/Config-polarssl.in | 4 ----
 package/network/services/openvpn/Makefile           | 6 +++---
 4 files changed, 3 insertions(+), 15 deletions(-)

On 2016-01-20 20:22, openwrt@daniel.thecshore.com wrote:
> From: Daniel Dickinson <openwrt@daniel.thecshore.com>
> 
> NB: Only compile tested.
> 
> Stop depending on ifconfig/route and use busybox (or real)
> iproute2 utility instead.  Depend on virtual ip package provided
> by previous commit so as not to force a particular version of
> the ip command.
> 
> Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
I'll wait until somebody has properly tested this.

- Felix

On 21/01/16 02:31 PM, Felix Fietkau wrote:
> On 2016-01-20 20:22, openwrt@daniel.thecshore.com wrote:
>> From: Daniel Dickinson <openwrt@daniel.thecshore.com>
>>
>> NB: Only compile tested.

Based on live testing it appears that openvpn upstream does not work 
properly at least with the busybox ip applet, but likely also with full 
iproute2 due to race condition (tun device goes away before ip command 
runs and sets up networking).

Regards,

Daniel

>>
>> Stop depending on ifconfig/route and use busybox (or real)
>> iproute2 utility instead.  Depend on virtual ip package provided
>> by previous commit so as not to force a particular version of
>> the ip command.
>>
>> Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
> I'll wait until somebody has properly tested this.
>
> - Felix
>

Hi,

On Sun, Jan 31, 2016 at 03:49:58PM -0800, Daniel Dickinson wrote:
> On 21/01/16 02:31 PM, Felix Fietkau wrote:
> > On 2016-01-20 20:22, openwrt@daniel.thecshore.com wrote:
> >> From: Daniel Dickinson <openwrt@daniel.thecshore.com>
> >>
> >> NB: Only compile tested.
> 
> Based on live testing it appears that openvpn upstream does not work 
> properly at least with the busybox ip applet, but likely also with full 
> iproute2 due to race condition (tun device goes away before ip command 
> runs and sets up networking).

That would surprise me a bit... can I have the openvpn log for that race
condition?  Is this something special in OpenWRT?  Normally, the tun device
can never "go away" unless OpenVPN tells it to - and if we do that, we do
not call ip/ifconfig on it afterwards.

(Also, for the busybox ip applet, our use of ip is not exactly esoteric -
setup ipv4/ipv6 addresses on tun if, add ipv4/ipv6 routes)

gert,
   openvpn upstream

On 01/02/16 02:57 AM, Gert Doering wrote:
> Hi,
>
> On Sun, Jan 31, 2016 at 03:49:58PM -0800, Daniel Dickinson wrote:
>> On 21/01/16 02:31 PM, Felix Fietkau wrote:
>>> On 2016-01-20 20:22, openwrt@daniel.thecshore.com wrote:
>>>> From: Daniel Dickinson <openwrt@daniel.thecshore.com>
>>>>
>>>> NB: Only compile tested.
>>
>> Based on live testing it appears that openvpn upstream does not work
>> properly at least with the busybox ip applet, but likely also with full
>> iproute2 due to race condition (tun device goes away before ip command
>> runs and sets up networking).
>
> That would surprise me a bit... can I have the openvpn log for that race
> condition?  Is this something special in OpenWRT?  Normally, the tun device
> can never "go away" unless OpenVPN tells it to - and if we do that, we do
> not call ip/ifconfig on it afterwards.

I'll have to set up a test environment to replicate the situation 
because I removed the offending compile in order to get things working. 
  However while the tun device was clearly not present I am wondering if 
the problem was not that it went away but that it wasn't accessible yet 
when the ip command was run (i.e. the opposite to what I initially 
assumed (which is that ip was too late and a timeout had occurred)).  I 
didn't recall seeing anything about either bringing up or tearing down 
the tun device at the log level I was on (I think verbosity 3).

Regards,

Daniel

>
> (Also, for the busybox ip applet, our use of ip is not exactly esoteric -
> setup ipv4/ipv6 addresses on tun if, add ipv4/ipv6 routes)
>
> gert,
>     openvpn upstream
>