Re: [PATCH 00/11] Add association state for VPNs

Jussi Laakkonen <[email protected]> Tue, 15 Apr 2025 12:14:52 +0300
Newsgroups dev.linux.lists.connman
Message-ID <[email protected]>
Hi all!

On 2/14/25 08:30, Christian Hewitt wrote:
>> On 24 Jan 2025, at 10:58 pm, Jussi Laakkonen <[email protected]> wrote:
>>
>> This patch set adds the association state also for the VPNs. This state is to
>> indicate that the VPN is waiting for VPN agent to provide input given by user.
>> In this state service.c must not do connect timeout checks as the timers for
>> both differ in length, default being 120s for connect timeout and 300s for VPN
>> agent dialog timeout.
>>
>> In order to facilitate this change the association state had to be implemented
>> also for VPNs. It is common state for services and like with services the
>> association state for VPNs preceeds the configuration state (on VPN side
>> connect state). Both vpn.c plugins on connmand and vpnd side require changes
>> to accommodate this state. When the VPN agent succeeds in getting the input
>> from the user the state transitions from association to connect (configuration)
>> state and, thus, requires no specific changes to VPN plugins.
>>
>> On connmand side the association state is the initial state when VPN is getting
>> connected and the state needs to be accounted as a connecting state in
>> plugins/vpn.c to not to lose transport ident for it and in provider.c as a
>> pre-configuration state to not to start the connect timeout for the VPN before
>> the VPN is in configuration state. The reason for the latter is that the
>> connect timeout should be exact and start from the point when
>> connect/configuration state is entered.
>>
>> On vpnd side association state is, like on connmand side, the initial state for
>> the VPN getting connected. After the VPN agent succeeds getting the information
>> from the user (credentials) the state transitions to connect (configuratioin).
>> There may be a possibility for a VPN plugin to run without VPN agent and thus
>> in these cases it is ensured that the vpn/plugins/vpn.c:vpn_notify() does
>> the state transition in such cases. It is allowed go back to association state
>> from connect state but not from other states.
>>
>> Jussi Laakkonen (11):
>>   agent: Cancel agent request on NoReply D-Bus error
>>   vpn-provider: Use association state for VPN agent input wait
>>   vpn: Add association state before connect state
>>   vpn-agent: Do connect state transition after input dialog check
>>   service: Explicit VPN connect timeout, ignore in VPN agent wait
>>   provider: Handle VPN configuration and association states
>>   vpn: Add support for association state, add state getter
>>   vpn: Check if connecting when setting state or disconnecting
>>   vpn: Add VPN agent use callback for plugins
>>   vpn-provider: Transition to CONNECT state with agentless VPNs
>>   doc: Update VPN documentation for association state
>>
>> doc/vpn-connection-api.txt |  4 +--
>> doc/vpn-overview.txt       |  7 ++++-
>> include/provider.h         |  9 +++---
>> plugins/vpn.c              | 23 ++++++++++++---
>> src/agent.c                |  4 ++-
>> src/connman.h              |  2 ++
>> src/provider.c             | 22 ++++++++++++++-
>> src/service.c              | 52 ++++++++++++++++++++++++++++++----
>> vpn/plugins/vpn.c          | 44 ++++++++++++++++++++++++++++-
>> vpn/plugins/vpn.h          | 12 ++++----
>> vpn/vpn-agent.c            |  6 +++-
>> vpn/vpn-provider.c         | 58 ++++++++++++++++++++++++++++++++++----
>> vpn/vpn-provider.h         |  7 +++++
>> 13 files changed, 220 insertions(+), 30 deletions(-)
> 
> I’ve been using this series combined with the following series and patch for several weeks:
> 
> https://patchwork.kernel.org/project/connman/list/?series=928220
> https://patchwork.kernel.org/project/connman/patch/DB6PR10MB1845EBB07DB785B580B3F6ECE1E02@DB6PR10MB1845.EURPRD10.PROD.OUTLOOK.COM/
> 
> Plus a revert of this commit which I’ve previously flagged as breaking the default “route all traffic down tunnel” with WireGuard (the main use-case for LibreELEC users):
> 
> https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=9eb1772d31b6fcf78e8711976696491aec9ff5df
> 
> For easier testing all patches are in this branch: https://github.com/chewitt/connman/commits/wireguard
> 
> No issues observed, so:
> 
> Tested-by: Christian Hewitt <[email protected]>
> 

Denis: The testing of WireGuard changes was done with these changes as 
well, should I resend these patches? I'll try to find time 
today/tomorrow to check if they still apply, and if not, I'll send v2.

- Jussi