Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH 0/6] Support SplitRouting variable on vpnd
(Jussi Laakkonen)
----------------------------------------------------------------------
Date: Tue, 20 Oct 2020 17:41:57 +0300
From: Jussi Laakkonen <[email protected]>
Subject: Re: [PATCH 0/6] Support SplitRouting variable on vpnd
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
Sorry for my really late reply. We changed email provider and apparently
these were regarded as spam..
On 9/30/20 9:39 AM, Daniel Wagner wrote:
> Hi Jussi,
>
> Sorry for the delay, I had a few days off :)
>
> On Wed, Sep 23, 2020 at 05:45:44PM +0300, Jussi Laakkonen wrote:
>>>> I've seen issues where the default route is not in the VPN routes list and
>>>> thus, the networking may be inoperable until VPN is disconnected as there
>>>> is
>>>> no default route for routing traffic. I guess this happened after a lot of
>>>> disconnect/reconnect and changing of transport services rapidly. It started
>>>> to occur at some point and this kind of approach helped us with the case.
>>>> But now I see that it was originally in the wrong place, and only
>>>> half-correct. Need to continue with this.
>>> Okay, if there are wrong/stale routes, it's connmand fault.
>> Would it be reasonable to add checks to e.g., plugins/vpn.c when routes are
>> being handled to test whether a non-split routed VPN has the default route
>> assigned? And when it is missing add it since otherwise the routing fails to
>> work.
> You means as safety net? Thinking on it, wouldn't this result in the
> same code as we currently have to set the routing tables? If you have
> good ideas how to improve it, even logging, I am all for it!
Yes, exactly, for some of the not-so-easy to reproduce cases. I'll
return to this when a task related to this lands onto my table again.
>>> I see following options ordered according my preferences:
>>>
>>> - rip it out
>>> - leave it as it is and document, not working for split routing
>>> - add support for split routing
>>>
>> It does make the vpnd side code quite difficult to understand. I think that
>> lead me to wrong tracks originally (we had a separate option for default
>> route but I thought split routing would do the same).
>>
>> We are not using that '-r'. But for me that was an issue to account for with
>> the changes. If someone then uses that '-r' with vpnd it might be a bit
>> annoying to notice it being removed. Not that functionality would change
>> then anyways.
>>
>> It is quite old, so people might expect it to be present. But having it as
>> only partially working is not good either. Would there be any real use cases
>> for this? If not, I'm also rooting for ripping it out.
> Given, that probably no one is using connman-vpnd stand alone, let's rip
> it out. If someone screams we can add the code back but mark it as not
> working for splitted VPN setups as it is today. I don't want to spend
> time at this part for 0-1 user.
Ok, I'm fine with that. It will make the code more readable. I'll try to
keep that in mind when I return to this.
>> This is interesting and I didn't notice the service ordering to be in
>> control. Saving and reading the value from the config makes that part quite
>> odd for me or is it just for restoring the previous state of service order
>> after restart or something else?
> The SplitRouting value is used as 'weight' for the ordering of the
> services. If it is set to true, it has less weight and should be moved
> after the currently ready/online service. Though I know we there is a
> bug with the ordering. IIRC move-after works but not move-before.
Yes, I understand this now quite well, thanks for opening my eyes on
this part. I think we have made some improvements to the service
ordering and have even some unit tests (some of them are TODO still...),
but will return to this as well later on.
>
>> This I think gave me the idea of exposing
>> the SplitRouting value. I had some faint memory that it was acceptable to
>> move VPN controls more to vpnd, and this SplitRouting just seemed to be like
>> that.
> The ordering is what makes enables/disables the split configuration.
>
>> I have another related issue on my hands that should be done at some point.
>> From what I've understood there can be only one VPN per transport medium
>> active at a time (src/connection.c) as it relies on the phy index.
> I am able to run an splitted OpenVPN session ontop of WireGuard default
> route. At least I thought it worked. Don't make look at it again :)
Oh, really. We have simply restricted it for one VPN at a time.
Interesting, need to dive into that. But according to code there would
be one transport/VPN possibility from my understanding.
>
>> We have a
>> dependency system specially for the service ordering, that is currently
>> using struct reference but would be better to use indexes (a TODO for me).
>> So with a connection between the VPN and the transport medium service the
>> ordering seemed to work better in rapidly changing networking environments.
>> Cannot anymore recall all the details, but it may have also something to do
>> with the difference there is in service.c for historical reasons.
> Not totally following you here but I think I get the drift. Anyway,
> ConnMan's Service API is and it's specially the idea to control things
> via the ordered list has its limit. If we start with ConnMan 2.x we
> should not keep it :)
That is not easy to explain without the code. But there may be
improvements on both sides on these issues. I need to tread sometimes
quite carefully with these. But hopefully we can get our codebase much
closer to upstream soon-ish..
Cheers,
Jussi
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 60, Issue 20
***************************************
