[PATCH v2 0/8] Rewrite OpenConnect plugin and enhance support for VPN auth errors
by Jussi Laakkonen
This set of patches contains almost complete rewrite of OpenConnect VPN plugin,
introduces a method for informing VPN agent about authentication errors and
adds support for easier use of boolean type setting strings.
First of all, as the biggest change, OpenConnect VPN plugin is rewritten to
support the different authentication methods, which is configurable in provider
settings. If the configuration is omitted, cookie based authentication is set
as default. Support for automatic cookie (first use credentials to get cookie
and then connect with the cookie), credentials and separate public key with
private key and PKCS#12 credential authentication is introduced. Credentials
and PKCS#12 password is queried from VPN agent. Also support for the three
openconnect protocols is added also as provider settings for the OpenConnect
plugin. New options for OpenConnect are added as well to support allowing self
signed certificates and to toggle connection parameters, which may be required
with different server setups.
Second, the authentication and connection errors are tracked by vpn-provider.c
when vpn_provider_indicate_error() is called with appropriate error code. These
errors can be utilized in VPN plugins to indicate VPN agent that saved
authentication credentials should be cleared. After succesful connection or
after saving provider settings the error counters are cleared. Main reason for
implementing these into provider is that saving the values in plugin private
data would be cleared after the connection is terminated, and provider is more
permanent during the runtime of vpnd.
And last, a new function to better support setting strings expected to be
boolean in value ("true" or "false") is implemented. This function can be used
to check if the setting string is explicitly the desired boolean value as the
default value in case of missing or invalid value is to be given.
Jussi Laakkonen (8):
vpn-provider: Implement simple connection and auth error counters
vpn-agent: Implement function to add auth failures to VPN agent msg
doc: Add VpnAgent.AuthFailure to VPN agent API documentation
vpn-provider: Implement setting string to bool conversion function
openconnect: Rewrite plugin to support more auth methods and protocols
openconnect: No PKCS auth mode restriction and support interactive
mode
doc: Add new OpenConnect PKCS#12 parameters to VPN agent API
doc: Add new OpenConnect configuration options to VPN config format
doc/vpn-agent-api.txt | 16 +
doc/vpn-config-format.txt | 77 ++-
vpn/plugins/openconnect.c | 1317 ++++++++++++++++++++++++++++++++-----
vpn/vpn-agent.c | 53 ++
vpn/vpn-agent.h | 3 +
vpn/vpn-provider.c | 56 +-
vpn/vpn-provider.h | 8 +
7 files changed, 1373 insertions(+), 157 deletions(-)
--
2.20.1
1 year, 4 months
In case there are multiple context of cellular, how can tethering
select one as route context?
by 원덕재
Hello connman,
I’m focus on wifi tethering for embedded device with connman v1.33.
I have two cellular contexts as below.
#ls /var/lib/connman
cellular_11111111111111_context1
cellular_22222222222222_context2
when I turn on the tethering, wifi as AP is connected to first context(cellular_11111111111111_context1) for WAN.
So, all client use to cellular_1111111111111_context1 to access WAN.
I want to second context(cellular_22222222222222_context2) instead cellular_11111111111111_context1 for this case.
Could you let me know how can I select context2 as WAN?
I’m looking for some reference, but I can’t find a clue.
Thanks.
DJ
1 year, 4 months
[PATCH] vpnc: Implement disconnect function to cancel queued VPN agent msg
by Jussi Laakkonen
Queued VPN agent messages must be canceled if the plugin timeouts
without starting the process. This fixes the issue of having multiple
VPN agent queries stacked on another in such scenario, where VPNC is
awaiting for user input.
---
vpn/plugins/vpnc.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/vpn/plugins/vpnc.c b/vpn/plugins/vpnc.c
index cb24a2b4..808c36cd 100644
--- a/vpn/plugins/vpnc.c
+++ b/vpn/plugins/vpnc.c
@@ -815,6 +815,14 @@ static int vc_connect(struct vpn_provider *provider,
return run_connect(data);
}
+static void vc_disconnect(struct vpn_provider *provider)
+{
+ if (!provider)
+ return;
+
+ connman_agent_cancel(provider);
+}
+
static int vc_error_code(struct vpn_provider *provider, int exit_code)
{
switch (exit_code) {
@@ -850,6 +858,7 @@ static int vc_device_flags(struct vpn_provider *provider)
static struct vpn_driver vpn_driver = {
.notify = vc_notify,
.connect = vc_connect,
+ .disconnect = vc_disconnect,
.error_code = vc_error_code,
.save = vc_save,
.device_flags = vc_device_flags,
--
2.20.1
1 year, 4 months
[PATCH 0/7] Rewrite OpenConnect plugin and enhance support for VPN auth errors
by Jussi Laakkonen
This set of patches contains almost complete rewrite of OpenConnect VPN plugin,
introduces a method for informing VPN agent about authentication errors and
adds support for easier use of boolean type setting strings.
First of all, as the biggest change, OpenConnect VPN plugin is rewritten to
support the different authentication methods, which is configurable in provider
settings. If the configuration is omitted, cookie based authentication is set
as default. Support for automatic cookie (first use credentials to get cookie
and then connect with the cookie), credentials and separate public key with
private key and PKCS#12 credential authentication is introduced. Credentials
and PKCS#12 password is queried from VPN agent. Also support for the three
openconnect protocols is added also as provider settings for the OpenConnect
plugin. New options for OpenConnect are added as well to support allowing self
signed certificates and to toggle connection parameters, which may be required
with different server setups.
Second, the authentication and connection errors are tracked by vpn-provider.c
when vpn_provider_indicate_error() is called with appropriate error code. These
errors can be utilized in VPN plugins to indicate VPN agent that saved
authentication credentials should be cleared. After succesful connection or
after saving provider settings the error counters are cleared. Main reason for
implementing these into provider is that saving the values in plugin private
data would be cleared after the connection is terminated, and provider is more
permanent during the runtime of vpnd.
And last, a new function to better support setting strings expected to be
boolean in value ("true" or "false") is implemented. This function can be used
to check if the setting string is explicitly the desired boolean value as the
default value in case of missing or invalid value is to be given.
Jussi Laakkonen (7):
vpn-provider: Implement simple connection and auth error counters
vpn-agent: Implement function to add auth failures to VPN agent msg
doc: Add VpnAgent.AuthFailure to VPN agent API documentation
vpn-provider: Implement setting string to bool conversion function
openconnect: Rewrite plugin to support more auth methods and protocols
doc: Add new OpenConnect PKCS#12 parameters to VPN agent API
doc: Add new OpenConnect configuration options to VPN config format
doc/vpn-agent-api.txt | 16 +
doc/vpn-config-format.txt | 77 ++-
vpn/plugins/openconnect.c | 1086 ++++++++++++++++++++++++++++++++-----
vpn/vpn-agent.c | 53 ++
vpn/vpn-agent.h | 3 +
vpn/vpn-provider.c | 54 +-
vpn/vpn-provider.h | 8 +
7 files changed, 1141 insertions(+), 156 deletions(-)
--
2.20.1
1 year, 4 months
High CPU useage during DNS resolution over TCP
by Blanquicet Melendez Jose (M)
Hi everyone,
We are currently using ConnMan with tethering active on WIFI technology and an online service that allows devices connected to WIFI AP to access Internet.
In such situation, ConnMan works as DNS-Proxy given that devices connected to WIFI AP use it as DNS resolver. It means that ConnMan receives DNS requests and it has to process and forward them to DNS servers of online service.
Now, we noticed that when DNS requests uses TCP instead of UDP (There are specific cases when TCP needs to be use, see RFC7766 [1]), ConnMan takes too much CPU resources. For example, if a tool like top is used to monitor CPU load, it is possible to see how ConnMan quickly starts taking more and more resources, arriving even to ~60% of CPU load on an embedded system where a DNS request over UDP does not reach neither 5%.
Digging into the DNS-Proxy implementation on ConnMan, we noticed a difference between TCP and UDP implementation. Unlike UDP, the TCP socket towards DNS server is configured to be called each time data can be written (GLib watch condition G_IO_OUT). The problem is that using such configuration, the callback is triggered each time data can be written without blocking, which means many many times in a second. According to our analysis, that is what could be taking that much CPU resources from the moment socket is open (DNS request from devices connected to tethering Technology or from target itself), until socket is closed (DNS server responses or 30 seconds of idle-timeout):
src/dnsproxy.c:2510
if (data->protocol == IPPROTO_TCP) {
g_io_channel_set_flags(data->channel, G_IO_FLAG_NONBLOCK, NULL);
data->watch = g_io_add_watch(data->channel,
G_IO_OUT | G_IO_IN | G_IO_HUP | G_IO_NVAL | G_IO_ERR,
tcp_server_event, data);
data->timeout = g_timeout_add_seconds(30, tcp_idle_timeout,
data);
} else
data->watch = g_io_add_watch(data->channel,
G_IO_IN | G_IO_NVAL | G_IO_ERR | G_IO_HUP,
udp_server_event, data);
Has someone else seen this? What do you think about our analysis?
BTW, for testing, DNS requests over TCP can be generated using "vc" option of nslookup tool.
[1] https://tools.ietf.org/html/rfc7766
Thanks,
Jose
VISITA IL NOSTRO SITO WEB! - VISIT OUR WEB SITE! www.magnetimarelli.com Confidential Notice: This message - including its attachments - may contain proprietary, confidential and/or legally protected information and is intended solely for the use of the designated addressee(s) above. If you are not the intended recipient be aware that any downloading, copying, disclosure, distribution or use of the contents of the above information is strictly prohibited. If you have received this communication by mistake, please forward the message back to the sender at the email address above, delete the message from all mailboxes and any other electronic storage medium and destroy all copies. Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free. Therefore we do not assure that this message is complete or accurate and we do not accept liability for any errors or omissions in the contents of this message.
1 year, 4 months
Insights on connmand -d
by JH
Could anyone give some insights on what connmand -d differs to
connmand -n running by systemctl? From reading the documentation, my
understanding is it should be identical except increasing debug level
to printing out more debug messages, but the systemd service connmand
-n incapable of bringing my LTE modem up makes my wandering what I
could get wrong here, could the connman -n service messages be blocked
by journal logs? Appreciate anyone helps to fix it,
Thank you.
Kind regards.
On 9/28/19, JH <jupiter.hce(a)gmail.com> wrote:
> Hi,
>
> I thought connmand -d just for running debug mode, then I was puzzled,
> if I run systemctl start connman, the LTE cannot be connected, if I
> run connmand -d, the LTE modem can be connected on, is it LTE modem
> problem or connman problem?
>
> Thank you.
>
> Kind regards,
>
> - jh
>
1 year, 5 months
