Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH] service: Add online to ready transition feature
(Daniel Wagner)
2. Re: [PATCH] service: Prevent auto connection during passphrase request
(Daniel Wagner)
3. Re: [PATCH] service: Complete only after user connection retries
(Daniel Wagner)
4. Re: [PATCH] service: Fix disconnection search before connecting
(Daniel Wagner)
5. Re: [PATCH] service: Allow only user connection after WiFi failure
(Daniel Wagner)
6. Re: [PATCH] iwd: Fix typo in error message when stopping AccessPoint mode
(Daniel Wagner)
7. Re: [PATCH] timeserver: Fix false error message (Daniel Wagner)
8. Re: [PATCH] dnsproxy: Enable DNS servers on connected VPN if split
routing changes
(Daniel Wagner)
9. Re: [RFC 0/8] Prevent IPv4 VPN data/DNS leak to IPv6 network(s)
(Daniel Wagner)
10. Re: [RFC 1/8] ipconfig: Add disabling of IPv6, support method
restore and refactor (Daniel Wagner)
----------------------------------------------------------------------
Date: Sat, 27 Mar 2021 13:24:02 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] service: Add online to ready transition feature
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210327122402.l754ap33arn7n...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Emmanuel,
On Mon, Feb 22, 2021 at 09:21:57AM +0100, Daniel Wagner wrote:
> On Mon, Feb 15, 2021 at 04:56:50PM +0000, VAUTRIN Emmanuel (Canal Plus
> Prestataire) wrote:
> > WARNING: Experimental feature!!!
> > Global config option, which allows keeping calling the online check
> > request to guarantee that end-to-end connectivity is still successful.
> > If not, the default service transitions to READY state, enabling another
> > service to become the default one, in replacement.
>
> Can you resend, maybe attach it, as the patch seemed to be whitespace
> damaged. I wanted to test it for a while :)
I gave it a longer test and I didn't see any fallouts so far. Thus, I
applied it now.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 13:39:58 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] service: Prevent auto connection during
passphrase request
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210327123958.d43cq2tr5qzsg...@beryllium.lan>
Content-Type: text/plain; charset=utf-8
Hi Emmanuel,
On Thu, Mar 11, 2021 at 01:03:09PM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> + if (err == -EINPROGRESS) {
> + index = __connman_service_get_index(service);
> + g_hash_table_replace(passphrase_requested,
> + GINT_TO_POINTER(index), true);
> + }
> +
src/service.c: In function ‘__connman_service_connect’:
src/service.c:6723:31: warning: passing argument 3 of ‘g_hash_table_replace’
makes pointer from integer without a cast [-Wint-conversion]
6723 | GINT_TO_POINTER(index), true);
| ^~~~
| |
I think you could just insert the service instead of the bool
and use g_hash_table_remove() when done instead the bool. This would
also release the hash table resources.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 13:42:54 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] service: Complete only after user connection
retries
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210327124254.iorhou27y3u4p...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Emmanuel,
On Thu, Mar 11, 2021 at 01:04:11PM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> When a user connection fails, let the report_error_cb manage
> exclusively service update, after all retries.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 13:49:51 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] service: Fix disconnection search before
connecting
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210327124951.wt7ydiddfeoi4...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Emmanuel,
On Thu, Mar 11, 2021 at 01:05:00PM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> At the beginning of a connection, the search of potential disconnection
> shall not stop at the first idle service.
>
> Fixes: e89d4abfaf36 ("service: Clear up connect logic when called from D-Bus")
Thanks for the fixes tag. Makes sense not to stop the logic at the
state.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 14:03:44 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] service: Allow only user connection after WiFi
failure
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210327130344.cp7fgplf72elc...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Emmanuel,
On Fri, Mar 26, 2021 at 04:59:04PM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> > We have our own implementation of the WiFi plugin and I haven't tried
> > with the plugin upstream has so this is just a guess/concern from my part.
> It is important to share you concern, but I think you should face the
> same behavior, with or without it. The easiest way is to test it.
The trick is that 'reason' should be auto in case we do normal
reconnects. Well, this is almost like the original idea. My argument
still applies that we might retry to login into a network with stale
credentials. I don't know how likely this is. I assume more serious
setups are using certificates anyway and don't rely on user/password
these days. So let's try this out and see what happens.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 14:08:29 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] iwd: Fix typo in error message when stopping
AccessPoint mode
To: Jonathan Liu <net...@gmail.com>
Cc: connman@lists.01.org
Message-ID: <20210327130829.fnzode4esj5kr...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Jonathan,
On Mon, Mar 15, 2021 at 05:00:01PM +1100, Jonathan Liu wrote:
> The error text indicates that it could not start AccessPoint mode when
> it is actually trying to stop AccessPoint mode.
>
> Fixes: 648ed549f0ac ("iwd: Add support for tethering")
Patch applied.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 14:09:56 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] timeserver: Fix false error message
To: Justin Maggard <jmaggar...@gmail.com>
Cc: connman@lists.01.org, Justin Maggard <jmagg...@arlo.com>
Message-ID: <20210327130956.45gqpchrlwymp...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Justin,
On Thu, Mar 25, 2021 at 12:32:51PM -0700, Justin Maggard wrote:
> The gettimeofday() function returns -1 on error, but ntp_callback() was
> testing for 0 instead since 7af765d10 (clock: Add TimeSynced signal
> emitted when the system time has been synced), resulting in "Failed to
> get current time" error messages.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 14:13:40 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] dnsproxy: Enable DNS servers on connected VPN if
split routing changes
To: Jussi Laakkonen <jussi.laakko...@jolla.com>
Cc: connman@lists.01.org
Message-ID: <20210327131340.chntido2pexxi...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Fri, Mar 26, 2021 at 02:45:53PM +0200, Jussi Laakkonen wrote:
> If split routing is enabled on a connected VPN the DNS servers of the
> VPN should be enabled as well when the default service is switched to be
> the transport service.
Good catch! I didn't realize we didn't do this already. I am using
systemd-resolved for this very feature. Maybe I can stop using it now :)
Patch applied.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 15:00:04 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [RFC 0/8] Prevent IPv4 VPN data/DNS leak to IPv6
network(s)
To: Jussi Laakkonen <jussi.laakko...@jolla.com>
Cc: connman@lists.01.org
Message-ID: <20210327140004.afy2pwte2hkmn...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Fri, Mar 26, 2021 at 05:58:17PM +0200, Jussi Laakkonen wrote:
> Therefore, this simply does disable IPv6 on all connected services when the
> IPv4 VPN is connected with the help of changes done to ipconfig.c. Setting the
> internal value to block IPv6 use within ConnMan is utilized only when there
> can
> be multiple connected technologies as otherwise the transport will get
> replaced
> and VPN is re-connected using the new transport.
The current IPv6 support is pretty strange anyway. We rely on the kernel
to do slaac & co and don't manage the IPv6 routing table. I started with
an attempt to fix this but I got lost in the implementation. At this
point I think it makes more sense to start over with IPv6. Disabling the
kernel support for IPv6 on pure IPv4 connection makes sense.
> If multiple connected technologies is enabled and a new service connects then
> in this case it cannot first establish an IPv6 connection at all but if the
> particular service then ranks over the current service the VPN will be
> disconnected, IPv6 is re-enabled and the new service starts to establish an
> IPv6 connection. Otherwise the new service remains with IPv4
> connectivity only - but if it is IPv6 only the service cannot connect and this
> is expected (might it be good to have this feature as a configurable
> option?).
Good question. It sounds a bit like a corner case scenario. Do you think
it's likely we need to support it? If not I'd say we document it and
leave it away for the time being. No need to make things more complex
than necessary.
> To be future-proof it may be better to have the new services to have their
> IPv6
> network not enabled but forcefully disabled in case at the time of connection
> an IPv4 VPN is connected. Not only due to the fact that an IPv6 address is not
> attempted to be retrieved with the current approach for a newly connected
> network. Alternative would be to call
> __connman_provider_set_ipv6_for_connected() in case the default service is an
> IPv4 VPN to get the service list traversed. But in that case IPv6 connectivity
> may have been established and there might be a small timeframe for leaking
> traffic.
Hmm, it's a valid point but I have no idea if this is just another
corner case which makes things very complex. As I said currently ConnMan
doesn't do IPv6 correctly, this includes the routing. It relies heavily
on the IPv6 stack in the kernel.
Thanks,
Daniel
------------------------------
Date: Sat, 27 Mar 2021 15:02:08 +0100
From: Daniel Wagner <w...@monom.org>
Subject: Re: [RFC 1/8] ipconfig: Add disabling of IPv6, support method
restore and refactor
To: Jussi Laakkonen <jussi.laakko...@jolla.com>
Cc: connman@lists.01.org
Message-ID: <20210327140208.6to64dpdtwmau...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Fri, Mar 26, 2021 at 05:58:18PM +0200, Jussi Laakkonen wrote:
> -static bool get_ipv6_state(gchar *ifname)
> +#define PROC_IPV4_CONF_PREFIX "/proc/sys/net/ipv4/conf"
> +#define PROC_IPV6_CONF_PREFIX "/proc/sys/net/ipv6/conf"
> +
> +static int read_conf_value(const char *prefix, const char *ifname,
> + const char *suffix, int *value)
Could you split the patch and introduce the read/write_conf_value
changes with the new feature? This is a nice cleanup!
I have a similar patch for this for the IPv6 work I done. If you are
interested to look at it I can share the patches.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- connman@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org
------------------------------
End of connman Digest, Vol 65, Issue 10
***************************************
