On Thu, Apr 08, 2021 at 10:55:35PM +0200, Andrej Shadura wrote:
> > Well not completely true. In case of wpa_supplicant I am sure we need to
> > update the plugins/wifi.c plugin. Just to make it clear, I wont do it
> > due to lack of time. For iwd, I expect only small or even none needed
> > modification on ConnMan side. Maybe ask on the iwd mailing list or on
> > the #iwd IRC channel about the feature.
> Apparently Tizen have implemented WPA3 support for connman. I’m planning
> to take their patches, polish them up a bit and submit here. Would you
> review them when they’re ready or should I prod some other member of the
Ah that's nice to hear. Sure, post the patches and I review them. I am
interested to see what's necessary to support WPA3. I hope most of it is
in plugins/wifi.c :)
On 05.02.21 10:25, VAUTRIN Emmanuel (Canal Plus Prestataire) wrote:
>> Well, the ts sync engine is stopped at this point. ts_service is NULL on
>> the initial startup. So why should 'service == ts_service' checks not
>> behave correctly? ts_service = NULL is looks correct. If you think the
>> checks are not correct then we need to review them now. Adding
>> 'ts_service = service' before the timerservers_list check looks bogus
>> and is papering over a problem if 'ts_servce = NULL;' doesn't work.
> In fact, it is the contrary, my goal was not to change the checks.
> If I follow this proposal:
> 1. Starting with a current service and a not empty config timeserver list,
> but in manual mode, we have timerservers_list == NULL
> -> ts_service = NULL
and timeserver_sync_start() is not called, as we bail out.
> 2. Switching to auto mode, we have ts_service == NULL
> -> no synchro in __connman_timeserver_sync()
and since timeserver_sync_start() has never be called nothing will happen.
ts_service should really only be touched right before we call
timeserver_sync_start() and set to NULL as soon we stop the
The return timeservers_list should contain all server we should poll.
This sounds like __connman_timeserver_get_all() should return
a valid list.
On 06.04.21 11:19, VAUTRIN Emmanuel (Canal Plus Prestataire) wrote:
> Hi Daniel,
> As a reminder, I send these information again.
>> 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);
>> | ^~~~
>> | |
> In fact, I have copied the similar code from wispr_portal_browser_reply_cb.
> Maybe a global fix is necessary on this part.
It's similar but not the same. The wispr code inserts a pointer and
not a bool. That's why the compiler complains.
>> 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.
> The aim is to avoid a new connection on the same interface, whichever > the service is, so the index, representative of the interface, shall
And the wispr code removes the entry at the end of usage, see
g_hash_table_remove. This code wont remove the entries after use, it
just sets to false, which could possible leaking memory.
I am currently using connman to config WiFi to connect to WiFi
routers, here is the setting:
I now need to set up a WiFi P2P connection, my WiFi module supports
P2P, what should I change to set up a WiFi P2P connection in a connman
From: Jussi Laakkonen <jussi.laakkonen(a)jolla.com>
Use C locale in the OpenConnect VPN plugin for the task because screen
scraping is used to get information on the process. This is required
because when the user is changed to other than root the translations are
enabled if language settings define so.
vpn/plugins/openconnect.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/vpn/plugins/openconnect.c b/vpn/plugins/openconnect.c
index 4b3b1af7..eae6af10 100644
@@ -883,6 +883,16 @@ static int run_connect(struct oc_private_data *data)
if (!vpnhost || !*vpnhost)
vpnhost = vpn_provider_get_string(provider, "Host");
+ * Change to use C locale because of screen scraping is used. To be on
+ * the safe side, set both LANG and LC_ALL. This is required
+ * especially when the VPNC process is ran using a user other than
+ * root. Note that this is a temporary solution.
+ * TODO: remove this when screen scraping is replaced with library use.
+ connman_task_add_variable(task,"LANG", "C");
+ connman_task_add_variable(task,"LC_ALL", "C");
As a reminder, I send these information again.
> 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);
> | ^~~~
> | |
In fact, I have copied the similar code from wispr_portal_browser_reply_cb.
Maybe a global fix is necessary on this part.
> 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.
The aim is to avoid a new connection on the same interface, whichever
the service is, so the index, representative of the interface, shall be used.
The iwd plugin support native autoconnect so we need to disable the
core autoconnect algorithm in this case. Only lightly tested.
I saw some corner case with iwd's autoconnect algorithm. For example
there are two network net0 and net1. Both have autoconnect set. iwd
connects to net0. Then net0 dissapears and iwd chooses to connect
net1. Now user decides to disconnect from net1. After that net0
appears again, iwd doesn't auto connect to it anymore.
Daniel Wagner (4):
service: Remove unused __connman_service_disconnect_all()
network: Add __connman_network_native_autoconnect()
service: Factor autoconnect trigger code into a new function
service: Teach autoconnect algorithm native mode
include/service.h | 1 +
src/connman.h | 2 +-
src/network.c | 7 +++
src/service.c | 132 ++++++++++++++++++++++++----------------------
4 files changed, 77 insertions(+), 65 deletions(-)
This change is quite big, touching many places around the codebase and may
have still some quirks to be polished out and therefore this is sent as an
RFC first. The core idea of this is to prevent leaking of any data to an IPv6
network when an IPv4 VPN is used with dual-stack transport or when there are
other connected IPv6 cabable technologies. Leak can happen when the DNS server
of the VPN responds also to AAAA requests providing an IPv6 address as well. In
that case IPv6 of the transport/other connected service will be used and
traffic bypasses VPN.
Prevention of data leak is achieved by disabling IPv6 on adapter basis with
disable_ipv6 and autoconf values. It was not seen reasonable to disable IPv6
on system basis as there may be other interfaces that are not managed by
ConnMan (blacklisted) which may require IPv6 to function properly.
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.
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?).
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
It was also considered and prototyped to do this with DNS filtering but that
did prove to be a bit problematic, hence the added delays in some cases to DNS
requests and respective responses. Also disabling only the routes was
considered but since it depends on the IPv6 network type and autoconfiguration
of the interface it seemed to be safer and more consistent to do the change
But being a RFC any opinnion and comment is welcome. We have done some testing
and in those this seems to work well. One thing to consider is whether to
always set the autoconf value for an IPv6 enabled network interface or not, or
to save it along other IPv6 values to be able to restore the previous value in
case ConnMan crashes when the VPN is connected and IPv6 is disabled.
Jussi Laakkonen (8):
ipconfig: Add disabling of IPv6, support method restore and refactor
network: Support ipconfig.c changes for IPv6 force option
network: Prevent enabling IPv6 for network if internally disabled
service: Support IPv6 enable/disable for connected services
provider: Toggle IPv6 on the transport of IPv4 VPN connection
vpn: Return transport ident with get_property()
provider: Add function to get transport ident from VPN
service: Sort VPNs using the transport service if connected
plugins/vpn.c | 2 +
src/connman.h | 20 +++-
src/ipconfig.c | 290 +++++++++++++++++++++++++++++++++----------------
src/network.c | 61 ++++++++---
src/provider.c | 130 ++++++++++++++++++++++
src/service.c | 203 ++++++++++++++++++++++++++++++++--
6 files changed, 583 insertions(+), 123 deletions(-)