I suspect this is going to break anything using non-ASCII passwords. OpenConnect is not designed to be screen-scraped. As discussed, it has interfaces which *are* designed to be used in this circumstance.

On 24 October 2019 11:20:23 BST, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote:
Set LANG and LC_ALL to C locale for each task used to run VPN processes.
This ensures that no translations are used.

The user for running VPN process can be changed with DACPrivileges
configuration (see commit 171989601a7a4fadafda20a7e6d30e9ada3fb516). If
the user is changed to other than what connman is ran with a specific
language may have been set. Plugins relying on correct output would fail in
such case.
vpn/plugins/vpn.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/vpn/plugins/vpn.c b/vpn/plugins/vpn.c
index eef8550e..16946c80 100644
--- a/vpn/plugins/vpn.c
+++ b/vpn/plugins/vpn.c
@@ -624,6 +624,15 @@ static int vpn_connect(struct vpn_provider *provider,
goto exist_err;

+ /*
+ * Change to use C locale, some VPN plugins use screen scraping for
+ * error parsing. To be on the safe side, set both LANG and LC_ALL.
+ * This is required especially when the VPN processes are ran using
+ * user other than root.
+ */
+ connman_task_add_variable(data->task,"LANG", "C");
+ connman_task_add_variable(data->task,"LC_ALL", "C");
ret = vpn_driver_data->vpn_driver->connect(provider, data->task,
data->if_name, cb, dbus_sender,

Sent from my Android device with K-9 Mail. Please excuse my brevity.