On Mon, 2016-02-29 at 22:33 +0100, Hendrik Donner wrote:
> Doesn't connman_task_add_argument(task,
"--ifmode", "tun"); need to be
> set if there is no option specifying tun? Or is the --dev-type given as
> default for openvpn in patch 3/5 unnecessary?
the VPNC plugin works differently, because struct vpnc_options contains
default values. I added VPNC.InterfaceMode with "tun" as default, that
should be applied when the configuration is written in
vc_write_config_data if no other value got specified. And man 8 vpnc
says tun is the default, so i guess the connman_task_add_argument(task,
"--ifmode", "tun"); line wasn't even needed in the first place.
I know see that this is probably not working: all values in struct
vpnc_options get piped to vpnc because vpnc prompts for them in a
specififc order and i guess it won't even prompt for the Interface Mode.
It should work with the same logic that I implemented for the OpenVPN
plugin, will change that for v3.
According to man 8 openvpn, --dev-type is needed when the device name
does not begin with "tun" or "tap", so the OpenVPN plugin needs to
Ok, thanks for letting me omit reading said man page :-).
The VPNC. options mirror the official VPNC configuration options
man 8 vpnc). The same largely holds for OpenVPN. So VPNC.InterfaceMode
is on purpose, it should look more familiar to VPNC users.
Here I'd like some consistency from ConnMan as it'd make adding options
to vpn cofiguration easier. Vpn settings are anyway only a subset of all
possible configurations, so when specifying identical behavior they
should be named the same. Unfortunately not everything went this way in
So error message and fallback to tun? Or returning an error value
failing device creation in the caller?
Fallback to TUN and log a warning.