Unable to establish openvpn connection under Debian [rp_filter restored to 0, notifier disconnect underflow]

Unable to establish openvpn connection under Debian [rp_filter restored to 0, notifier disconnect underflow]

[Thomas Bartosik]

Hi!

I'm struggling to get connman+openvpn running on a current Debian machine.

My Gentoo notebook works fine with nearly exactly the same versions:
- connman 1.41
-- DEBIAN: built this myself as I got "netlink: attribute type 1 has an invalid length" with the stock 1.36 .deb in the Debian 11 repo and thought that was the problem
--- config used: ./bootstrap && ./configure --enable-openvpn --prefix="" && CFLAGS="-march=native -O3" make -j4 && checkinstall --fstrans=no -D make install
--- NB: the ./bootstrap step is missing in the README file
-- GENTOO: this is the most recent stable version in the repo

- openvpn
-- DEBIAN: openvpn 2.5.1 (official repo)
-- GENTOO: openvpn 2.5.3 (official latest stable)

However, on Debian I get
connmand[64470]    : rp_filter set to 2 (loose mode routing), old value was 0
connmand[64470]    : rp_filter restored to 0
connmand[64470]    : notifier disconnect underflow
connmand[64470]    : ipconfig state 6 ipconfig method 1
openvpn[64488]     : event_wait : Interrupted system call (code=4)
openvpn[64488]     : SIGTERM received, sending exit notification to peer
connman-vpnd[64477]: pid 64488 was not killed, retrying after 2 sec


On my Gentoo notebook, I don't get "rp_filter restored to 0" but see "Setting domainname to <domain>" and then it continues to set routes etc.

I'm pretty clueless as to what I could do to fix this.. It's the exact same provisioning config (that in turn uses the openvpn conf file)

Using openvpn standalone works nicely with the same openvpn conf file on Debian as well, just not with connman. That's why I basically rule out hardware or other OS differences.


The relevant sections with debug mode turned on are as follows (I tried to keep it as short as possible, hope that's the right spot and enough details):

Apr  8 17:29:44 Debian-host connmand[66999]: rp_filter set to 2 (loose mode routing), old value was 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/service.c:service_rp_filter() connected vpn_openvpn.domain.com_openvpn.domain.com ipconfig 0x55cb25086c60 method 2 count 2 filter 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/resolver.c:connman_resolver_append() index 54 domain (null) server 10.XX.XX.44
Apr  8 17:29:44 Debian-host connmand[66999]: src/resolver.c:append_resolver() index 54 domain (null) server 10.XX.XX.44 lifetime 0 flags 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/dnsproxy.c:__connman_dnsproxy_append() index 54 server 10.XX.XX.44
Apr  8 17:29:44 Debian-host connmand[66999]: src/dnsproxy.c:create_server() index 54 server 10.XX.XX.44
Apr  8 17:29:44 Debian-host connmand[66999]: src/resolver.c:connman_resolver_append() index 54 domain (null) server 10.XX.XX.34
Apr  8 17:29:44 Debian-host connmand[66999]: src/resolver.c:append_resolver() index 54 domain (null) server 10.XX.XX.34 lifetime 0 flags 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/dnsproxy.c:__connman_dnsproxy_append() index 54 server 10.XX.XX.34
Apr  8 17:29:44 Debian-host connmand[66999]: src/dnsproxy.c:create_server() index 54 server 10.XX.XX.34
Apr  8 17:29:44 Debian-host connmand[66999]: src/timeserver.c:ts_reset() No timeservers set.
Apr  8 17:29:44 Debian-host connmand[66999]: src/service.c:service_indicate_state() service 0x55cb25088150 old association - new ready/idle => ready
Apr  8 17:29:44 Debian-host connmand[66999]: plugins/vpn.c:vpn_disconnect_check()
Apr  8 17:29:44 Debian-host connmand[66999]: src/session.c:service_state_changed() service 0x55cb25088150 state 4
Apr  8 17:29:44 Debian-host connmand[66999]: src/resolver.c:connman_resolver_append() index 54 domain openvpn.domain.com server (null)
Apr  8 17:29:44 Debian-host connmand[66999]: src/resolver.c:append_resolver() index 54 domain openvpn.domain.com server (null) lifetime 0 flags 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/dnsproxy.c:__connman_dnsproxy_append() index 54 server (null)
Apr  8 17:29:44 Debian-host connmand[66999]: src/dnsproxy.c:update_domain() index 54 domain openvpn.domain.com
Apr  8 17:29:44 Debian-host connmand[66999]: src/dbus.c:connman_dbus_reply_pending() sender net.connman.Service path /net/connman/service/vpn_openvpn.domain.com_openvpn.domain.com
Apr  8 17:29:44 Debian-host connmand[66999]: src/service.c:service_save() service 0x55cb25088150 new 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/ipconfig.c:__connman_ipconfig_save() ipconfig 0x55cb25086c60 identifier vpn_openvpn.domain.com_openvpn.domain.com method fixed
Apr  8 17:29:44 Debian-host connmand[66999]: src/ipconfig.c:__connman_ipconfig_save() ipconfig 0x55cb25085560 identifier vpn_openvpn.domain.com_openvpn.domain.com method off
Apr  8 17:29:44 Debian-host connman-vpnd[67023]: vpn/vpn-provider.c:provider_property_changed() provider 0x556a97d4fb90 key Timeservers
Apr  8 17:29:44 Debian-host connman-vpnd[67023]: vpn/vpn-provider.c:provider_property_changed() provider 0x556a97d4fb90 key State
Apr  8 17:29:44 Debian-host connmand[66999]: src/notifier.c:__connman_notifier_connect() type 7
Apr  8 17:29:44 Debian-host connmand[66999]: src/ipconfig.c:disable_ipv6()
Apr  8 17:29:44 Debian-host connmand[66999]: src/ipconfig.c:set_ipv6_state() vpn0 1
Apr  8 17:29:44 Debian-host connman-vpnd[67023]: vpn/vpn-provider.c:provider_property_changed() provider 0x556a97d4fb90 key Domains
Apr  8 17:29:44 Debian-host connman-vpnd[67023]: vpn/vpn-provider.c:provider_property_changed() provider 0x556a97d4fb90 key Proxy
Apr  8 17:29:44 Debian-host connmand[66999]: src/service.c:single_connected_tech() keeping 0x55cb25088150 /net/connman/service/vpn_openvpn.domain.com_openvpn.domain.com
Apr  8 17:29:44 Debian-host connmand[66999]: src/service.c:single_connected_tech() disconnecting 0x55cb2507d720 /net/connman/service/ethernet_606d3c4e4cc0_cable
Apr  8 17:29:44 Debian-host connmand[66999]: src/service.c:__connman_service_disconnect() service 0x55cb2507d720
Apr  8 17:29:44 Debian-host connmand[66999]: src/agent.c:connman_agent_cancel() context 0x55cb2507d720
Apr  8 17:29:44 Debian-host connmand[66999]: src/stats.c:__connman_stats_service_unregister() service 0x55cb2507d720
Apr  8 17:29:44 Debian-host connmand[66999]: src/network.c:__connman_network_disconnect() network 0x55cb25077cf0
Apr  8 17:29:44 Debian-host connmand[66999]: plugins/ethernet.c:eth_network_disconnect() network 0x55cb25077cf0
Apr  8 17:29:44 Debian-host connmand[66999]: src/network.c:connman_network_set_connected() network 0x55cb25077cf0 connected 1/0 connecting 0 associating 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/network.c:set_disconnected() service 0x55cb2507d720 ipv4 0x55cb25076000 ipv6 0x55cb25078670
Apr  8 17:29:44 Debian-host connmand[66999]: src/network.c:set_disconnected() method ipv4 4 ipv6 5
Apr  8 17:29:44 Debian-host connmand[66999]: src/dhcpv6.c:__connman_dhcpv6_start_release() network 0x55cb25077cf0 dhcp 0x55cb25074d20 client 0x55cb25085150 stateless 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/dhcpv6.c:__connman_dhcpv6_stop()
Apr  8 17:29:44 Debian-host connmand[66999]: src/dhcpv6.c:remove_network() dhcp 0x55cb25074d20
Apr  8 17:29:44 Debian-host connmand[66999]: src/dhcpv6.c:dhcpv6_release() dhcp 0x55cb25074d20
Apr  8 17:29:44 Debian-host connmand[66999]: src/network.c:connman_network_unref_debug() 0x55cb25077cf0 name Wired ref 4 by src/dhcpv6.c:1858:__connman_dhcpv6_stop()
Apr  8 17:29:44 Debian-host connmand[66999]: src/dhcp.c:__connman_dhcp_stop() ipconfig_table 0x55cb25072e40 ipconfig 0x55cb25076000
Apr  8 17:29:44 Debian-host connmand[66999]: src/ipconfig.c:__connman_ipconfig_unref_debug() 0x55cb25076000 ref 2 by src/dhcp.c:739:__connman_dhcp_stop()
Apr  8 17:29:44 Debian-host connmand[66999]: src/network.c:connman_network_unref_debug() 0x55cb25077cf0 name Wired ref 3 by src/dhcp.c:741:__connman_dhcp_stop()
Apr  8 17:29:44 Debian-host connmand[66999]: src/dhcp.c:dhcp_release() dhcp 0x55cb250754e0
Apr  8 17:29:44 Debian-host connmand[66999]: src/dhcp.c:dhcp_invalidate() dhcp 0x55cb250754e0 callback 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/6to4.c:__connman_6to4_remove() tunnel ip address (null)
Apr  8 17:29:44 Debian-host connmand[66999]: src/service.c:__connman_service_nameserver_remove() service 0x55cb2507d720 nameserver 192.168.123.1 auto 0
Apr  8 17:29:44 Debian-host connmand[66999]: src/resolver.c:connman_resolver_remove() index 47 domain (null) server 192.168.123.1
Apr  8 17:29:44 Debian-host connmand[66999]: src/dnsproxy.c:__connman_dnsproxy_remove() index 47 server 192.168.123.1
Apr  8 17:29:44 Debian-host connmand[66999]: src/dhcp.c:dhcp_invalidate() last address 192.168.123.216
Apr  8 17:29:44 Debian-host connmand[66999]: src/inet.c:connman_inet_clear_address() index 47 address 192.168.123.216 prefix_len 24 peer (null) broadcast (null)
Apr  8 17:29:44 Debian-host connmand[66999]: src/inet.c:__connman_inet_modify_address() cmd 0x15 flags 0 index 47 family 2 address 192.168.123.216 peer (null) prefixlen 24 broadcast (null) p2p false
Apr  8 17:29:44 Debian-host connmand[66999]: src/ipconfig.c:__connman_ipconfig_set_gateway()
Apr  8 17:29:44 Debian-host connmand[66999]: src/service.c:__connman_service_ipconfig_indicate_state() service 0x55cb2507d720 (ethernet_606d3c4e4cc0_cable) old state 5 (online) new state 6 (disconnect) type 1 (IPv4)
Apr  8 17:29:44 Debian-host connmand[66999]: rp_filter restored to 0


Here's the openvpn domain.conf:

dev tun
persist-key
cipher AES-256-CBC
data-ciphers AES-256-CBC
auth SHA256
client
comp-lzo adaptive
resolv-retry infinite
remote openvpn.domain.com 1194 udp
auth-user-pass /etc/openvpn/domain_creds
ca /etc/openvpn/domain_ca.crt
cert /etc/openvpn/domain_user.crt
key /etc/openvpn/domain_user.key
remote-cert-tls server
script-security 2
lport 0
verify-x509-name "openvpn.domain.com" name
auth-nocache
explicit-exit-notify

And the provisioning file:

[provider_openvpn]
Type = OpenVPN
Name = domain
Host = openvpn.domain.com
Domain = openvpn.domain.com
OpenVPN.ConfigFile = /etc/openvpn/domain.conf

I have not been able to succeed (on either OS) with using just the provisioning file's OpenVPN.* parameters. This should however not be the problem, as it works on Gentoo.

I don't have access to the openVPN server side.

Any pointers appreciated!
If I can provide more debugging info, please say so.

Thanks a lot in advance (and for a bloat-free connection manager)!
Thomas

Re: Unable to establish openvpn connection under Debian [rp_filter restored to 0, notifier disconnect underflow]

[Daniel Wagner]

Hi Thomas,

On Fri, Apr 08, 2022 at 03:53:53PM +0000, Thomas Bartosik wrote:
> Hi!
> 
> I'm struggling to get connman+openvpn running on a current Debian machine.
> 
> My Gentoo notebook works fine with nearly exactly the same versions:
> - connman 1.41
> -- DEBIAN: built this myself as I got "netlink: attribute type 1 has an invalid length" with the stock 1.36 .deb in the Debian 11 repo and thought that was the problem

Yes, those netlink message were corrupted due bugs in the code.

> --- config used: ./bootstrap && ./configure --enable-openvpn --prefix="" && CFLAGS="-march=native -O3" make -j4 && checkinstall --fstrans=no -D make install
> --- NB: the ./bootstrap step is missing in the README file
> -- GENTOO: this is the most recent stable version in the repo
> 
> - openvpn
> -- DEBIAN: openvpn 2.5.1 (official repo)
> -- GENTOO: openvpn 2.5.3 (official latest stable)
> 
> However, on Debian I get
> connmand[64470]    : rp_filter set to 2 (loose mode routing), old value was 0
> connmand[64470]    : rp_filter restored to 0

Debian has different defaults for the rp_filter. So this is just ConnMan
saying let's use the more relaxed routing filter.

> connmand[64470]    : notifier disconnect underflow
> connmand[64470]    : ipconfig state 6 ipconfig method 1
> openvpn[64488]     : event_wait : Interrupted system call (code=4)
> openvpn[64488]     : SIGTERM received, sending exit notification to peer
> connman-vpnd[64477]: pid 64488 was not killed, retrying after 2 sec

Hmm, connman-vpnd wants to kill openvpn, but why? Hmm, just a random
idea: are the capalities preventing a proper working? Try to drop all
the caps boundings in connman-vpn.service.

Daniel

Re: Unable to establish openvpn connection under Debian [rp_filter restored to 0, notifier disconnect underflow]

[Thomas Bartosik]

Hi Daniel, thanks for answer!

On 14.04.22 20:45, Daniel Wagner wrote:
> Hi Thomas,
>
> On Fri, Apr 08, 2022 at 03:53:53PM +0000, Thomas Bartosik wrote:
>> Hi!
>>
>> I'm struggling to get connman+openvpn running on a current Debian machine.
>>
>> My Gentoo notebook works fine with nearly exactly the same versions:
>> - connman 1.41
>> -- DEBIAN: built this myself as I got "netlink: attribute type 1 has an invalid length" with the stock 1.36 .deb in the Debian 11 repo and thought that was the problem
> Yes, those netlink message were corrupted due bugs in the code.
If we get this working, I'll consider opening a bug report with Debian. Maybe a version fixing this can be backported to bullseye.
> Hmm, connman-vpnd wants to kill openvpn, but why? Hmm, just a random
> idea: are the capalities preventing a proper working? Try to drop all
> the caps boundings in connman-vpn.service.

tl;dr: Skip down to below the syslog output/snip, I found the error!

---8<------------

Tried this just now, process is verified to have no boundings anymore:

root@tbartosik-linux:~# grep Cap /proc/$(pgrep connman-vpn)/status
CapInh:0000000000000000
CapPrm:00000000000034e9
CapEff:00000000000034e9
CapBnd:00000000000034e9
CapAmb:0000000000000000
root@tbartosik-linux:~# vi /lib/systemd/system/connman-vpn.service
root@tbartosik-linux:~# systemctl daemon-reload
root@tbartosik-linux:~# killall connman-vpnd
root@tbartosik-linux:~# service connman restart
root@tbartosik-linux:~# grep Cap /proc/$(pgrep connman-vpn)/status
CapInh:0000000000000000
CapPrm:000001ffffffffff
CapEff:000001ffffffffff
CapBnd:000001ffffffffff
CapAmb:0000000000000000

Still no joy, however. The error stays the same.

Tried a more relaxed compilation without specifying CFLAGS and disabled parallel compilation (i.e. make -j1), did not fix it either.

I use openrc instead of systemd on Gentoo, and I don't use apparmor on Gentoo. Apparmor on Debian however does not list a loaded profile for connman processes.
I don't think systemd or the startup configuration of connman services by systemd is related, as this also happens when I just start the services from bash (which I did as I passed the debug switch).

Is there anything more I can do to improve the verbosity so we know *why* openvpn gets terminated?

I dug a little deeper.

It seems src/task.c is the only place where processes get killed, right? It seems to boil down to connman_task_stop() as this is the only function calling check_kill() which we definitely know gets called by the log entry "pid XXX was not killed, retrying after 2 sec". connman_task_stop() in turn only gets called in vpn/plugins/vpn.c and vpn/vpn-agent.c (ignoring vpn/plugins/pptp.c and vpn/plugins/l2tp.c which don't apply here I'd say).

vpn/plugins/vpn.c only has two locations: vpn_remove() and vpn_disconnect().

vpn_disconnect() has a debug statement DBG("disconnect provider %p:", provider); and I can see this in the logs:

connmand[51826]: src/service.c:__connman_service_ipconfig_indicate_state() service 0x564edbbccaa (ethernet_606d3c4e4cc0_cable) old state 5 (online) new state 6 (disconnect) type 1 (IPv4)
connmand[51826]: rp_filter restored to 0
connmand[51826]: src/service.c:service_rp_filter() disconnected ethernet_606d3caabbcc_cable ipconfig 0x564ed3e4eeb0 method 4 count 1 filter 0
connmand[51826]: src/timeserver.c:ts_reset() No timeservers set.
connmand[51826]: src/service.c:service_indicate_state() service 0x564edbbccaa old online - new disconnect/ready => ready
connmand[51826]: src/notifier.c:__connman_notifier_leave_online() type 2
connmand[51826]: plugins/vpn.c:vpn_disconnect_check()
connmand[51826]: src/session.c:service_state_changed() service 0x564edbbccaa state 4
connmand[51826]: src/service.c:service_save() service 0x564edbbccaa new 0
connmand[51826]: src/ipconfig.c:__connman_ipconfig_save() ipconfig 0x564ed3e4eeb0 identifier ethernet_606d3caabbcc_cable method dhcp
connmand[51826]: src/ipconfig.c:__connman_ipconfig_save() ipconfig 0x564ed3e48c30 identifier ethernet_606d3caabbcc_cable method auto
connman-vpnd[51848]: vpn/vpn-provider.c:connman_property_changed() key State
connman-vpnd[51848]: vpn/vpn-provider.c:set_state() old state online/ready new state ready
connman-vpnd[51848]: vpn/vpn-provider.c:set_state() set state ready connman_online=true
connmand[51826]: src/service.c:single_connected_tech() keeping 0x564edbbccaa /net/connman/service/ethernet_606d3caabbcc_cable
connmand[51826]: src/service.c:single_connected_tech() disconnecting 0x564edaabbcc /net/connman/service/vpn_ovpn_domain_com_ovpn_domain_com
connmand[51826]: src/service.c:single_connected_tech() keeping 0x564edbbccaa /net/connman/service/ethernet_606d3c4e4cc0_cable
connmand[51826]: src/service.c:single_connected_tech() disconnecting 0x564edaabbcc /net/connman/service/vpn_ovpn_domain_com_ovpn_domain_com
connmand[51826]: src/service.c:__connman_service_disconnect() service 0x564edaabbcc
connmand[51826]: src/agent.c:connman_agent_cancel() context 0x564edaabbcc
connmand[51826]: src/stats.c:__connman_stats_service_unregister() service 0x564edaabbcc
connmand[51826]: src/provider.c:connman_provider_disconnect() provider 0x564ed3e517a0
connmand[51826]: plugins/vpn.c:provider_disconnect() provider 0x564ed3e517a0
connmand[51826]: plugins/vpn.c:disconnect_provider() data 0x564ed3e6cc50 path /net/connman/vpn/connection/ovpn_domain_com_ovpn_domain_com
connmand[51826]: src/provider.c:provider_indicate_state() state 6
connmand[51826]: src/service.c:__connman_service_ipconfig_indicate_state() service 0x564edaabbcc (vpn_ovpn_domain_com_ovpn_domain_com) old state 4 (ready) new state 6 (disconnect) type 1 (IPv4)
connmand[51826]: src/service.c:service_rp_filter() disconnected vpn_ovpn_domain_com_ovpn_domain_com ipconfig 0x564ed3e58460 method 2 count 0 filter 0
connmand[51826]: src/resolver.c:connman_resolver_remove() index 12 domain (null) server 10.x.x.x
connmand[51826]: src/dnsproxy.c:__connman_dnsproxy_remove() index 12 server 10.x.x.x
connmand[51826]: src/resolver.c:connman_resolver_remove() index 12 domain (null) server 10.x.x.x
connmand[51826]: src/dnsproxy.c:__connman_dnsproxy_remove() index 12 server 10.x.x.x
connmand[51826]: src/resolver.c:connman_resolver_remove() index 12 domain openvpn.domain.com server (null)
connmand[51826]: src/dnsproxy.c:__connman_dnsproxy_remove() index 12 server (null)
connmand[51826]: src/dnsproxy.c:update_domain() index 12 domain openvpn.domain.com
connmand[51826]: src/timeserver.c:ts_reset() No timeservers set.
connmand[51826]: src/service.c:service_indicate_state() service 0x564ed3aabbcc old ready - new disconnect/idle => disconnect
connmand[51826]: src/resolver.c:connman_resolver_remove() index 12 domain openvpn.domain.com server (null)
connmand[51826]: plugins/vpn.c:vpn_disconnect_check()
connmand[51826]: src/session.c:service_state_changed() service 0x564edaabbcc state 6
connmand[51826]: src/provider.c:provider_service_changed() service 0x564edaabbcc vpn_ovpn_domain_com_ovpn_domain_com state 6 index 12/-1
connmand[51826]: src/wispr.c:__connman_wispr_stop() service 0x564edaabbcc
connmand[51826]: src/wpad.c:__connman_wpad_stop() service 0x564edaabbcc
connmand[51826]: src/service.c:downgrade_state() service 0x564edbbccaa state4 6 state6 4
connmand[51826]: src/connection.c:__connman_connection_update_gateway() default 0x564ed3998877
connmand[51826]: src/notifier.c:__connman_notifier_disconnect() type 7
connmand[51826]: notifier disconnect underflow
connmand[51826]: ipconfig state 6 ipconfig method 1
connmand[51826]: src/provider.c:provider_indicate_state() state 6
connmand[51826]: ipconfig state 6 ipconfig method 1
connmand[51826]: src/6to4.c:__connman_6to4_remove() tunnel ip address (null)
connmand[51826]: src/inet.c:connman_inet_clear_address() index 12 address a.b.c.d prefix_len 32 peer a.b.c.e broadcast (null)
connmand[51826]: src/inet.c:__connman_inet_modify_address() cmd 0x15 flags 0 index 12 family 2 address a.b.c.d peer a.b.c.e prefixlen 32 broadcast (null) p2p false
connman-vpnd[51848]: vpn/vpn-provider.c:do_disconnect() conn 0x5574a6cceeaa provider 0x5574a6ffeeaa
connman-vpnd[51848]: vpn/vpn-provider.c:__vpn_provider_disconnect() provider 0x5574a6ffeeaa
connman-vpnd[51848]: vpn/plugins/vpn.c:vpn_disconnect() disconnect provider 0x5574a6ffeeaa:

----8<----------

So single_connected_tech() kills the new connection!

I removed "SingleConnectedTechnology=true" in /etc/connman/main.conf and it works now as it should!

I seem to have added this because of routing/DNS problems if I remember correctly.

Does this work as intended? I'd somehow not count a VPN as a seperate connected technology, as it only works when another connection is present anyway.

I'd like to prefer wired over wifi and only have one technology connected and still be able to open a VPN. Is this possible? I'll stick with "PreferredTechnologies=ethernet,wifi" for the time being and see whether the problems come back.

If that's not possible then please add some info in the man page that using VPN with "SingleConnectedTechnology=true" is impossible. I'd also vote for an error condition/log statement when a VPN connection is started and this option is true as this can by definition not work out, as every VPN needs two connections. Or don't count VPNs :-)

I have a few other problems/questions as well:

- connmanctl operates on (internal?) service names, not the human readable ones. This pretty cumbersome/somewhat unexpected, and leads to error messages that don't really guide the user to the correct way of specifying a services. I guess the human readable IDs can be ambiguous, but maybe try them and only error out when they really are non-unique? The missing column titles in the "services" output also make it hard to know what exactly <service> in commands (like "connect" means). This is an example of an error message:

Error /net/connman/service/vpnname: Method "Connect" with signature "" on interface "net.connman.Service" doesn't exist


- The VPN server I connect to does not route public traffic, so I need my default route to stay as it is (in my LAN).

After searching around a long time I managed to fix this by using connmanctl's move-before command for my local LAN (before the VPN).

Is there any better way to achieve this? (Did I not RTFM enough? I know the manual states the order is important, that's why I tried it.)

Specifying "Networks=<only VPN networks>" in /var/lib/connman-vpn/myvpnname.config did not change this. I would have expected this to do exactly what I mean.


Thanks for your time!

Connman is a great product as it's so lightweight. Configuration however sometimes trips me up ;-)

Re: Unable to establish openvpn connection under Debian [rp_filter restored to 0, notifier disconnect underflow]

[Daniel Wagner]

Hi Thomas,

On Tue, Apr 19, 2022 at 09:56:48AM +0000, Thomas Bartosik wrote:
> Hi Daniel, thanks for answer!
> tl;dr: Skip down to below the syslog output/snip, I found the error!

Nice!

> I'd like to prefer wired over wifi and only have one technology
> connected and still be able to open a VPN. Is this possible? I'll
> stick with "PreferredTechnologies=ethernet,wifi" for the time being
> and see whether the problems come back.

I can't remember all the details of the connection algorithm anymore,
but the SingleConnectedTechnology option is currently incompatible with
VPNs.

> If that's not possible then please add some info in the man page that
> using VPN with "SingleConnectedTechnology=true" is impossible.

I just send out a patch which updates the man page.

> I'd also vote for an error condition/log statement when a VPN connection
> is started and this option is true as this can by definition not work
> out, as every VPN needs two connections. Or don't count VPNs :-)

I agree it makes sense to filter out VPN when
SingleConnectedTechnology is used.

> I have a few other problems/questions as well:
> 
> - connmanctl operates on (internal?) service names, not the human
> readable ones. This pretty cumbersome/somewhat unexpected, and leads
> to error messages that don't really guide the user to the correct way
> of specifying a services. I guess the human readable IDs can be
> ambiguous, but maybe try them and only error out when they really are
> non-unique? The missing column titles in the "services" output also
> make it hard to know what exactly <service> in commands (like
> "connect" means). This is an example of an error message:
> 
> Error /net/connman/service/vpnname: Method "Connect" with signature "" on interface "net.connman.Service" doesn't exist

connmanctl is not really user friendly indeed and I fear the tool needs
a bit of a rewrite.

> - The VPN server I connect to does not route public traffic, so I need
>   my default route to stay as it is (in my LAN).
>
> After searching around a long time I managed to fix this by using
> connmanctl's move-before command for my local LAN (before the VPN).
>
> Is there any better way to achieve this? (Did I not RTFM enough? I
> know the manual states the order is important, that's why I tried it.)

The order of the services defines the routing table, hence the
move-before and move-after is the interface to change it.

> Specifying "Networks=<only VPN networks>" in
> /var/lib/connman-vpn/myvpnname.config did not change this. I would
> have expected this to do exactly what I mean.

Because there is no Networks entry defined for the config. I know that
ConnMan lacks good documentation but we have at least all the config
options listed in the man pages. So if it's not mentioned than it
doesn't exists.

> Connman is a great product as it's so lightweight. Configuration
> however sometimes trips me up ;-)

Thanks, unfortunately, there are only a few contributions and no one is
willing to spend time or money to move this project really forward
(fixing obvious bugs, fixing obvious shortcomings such as configuration,
...). This means not will change unless someone steps up.

Daniel