connman/iwd reconnect issues - ongoing
by KeithG
Group,
I am back. When I tested it last time a couple weeks ago, it worked.
When I tested it again yesterday, it failed. I do not know what
happened, so I 'started over' to see if I can pinpoint what needs to
happen to get connman to reconnect when a wifi SSID is restarted. I
am running a Raspberry Pi3b+ with Arch Linux with its onboard brcmfmac
adapter. I have a connman git compiled version 1.38.r79.g69e9e250 and
iwd r5193.a8768e3 which is later than 1.11 and has specific fixes for
the brcmfmac. I have tried later brcmfmac firmware and a later driver
with the same result so I have reverted and am using the driver and
firmware that ships with arch linux.
I wiped all configs from /var/lib/connman and iwd and restarted as a test.
My main.conf for connman has only 3 edits from the blank one provided
in the package:
PreferredTechnologies = ethernet,wifi
AllowHostnameUpdates = false
AlwaysConnectedTechnologies = ethernet,wifi
My iwd main.conf is:
[General]
UseDefaultInterface=true
We create a *.config file and restart the device to configure the
wireless. The config file we create has these lines:
[global]
Description=DHCP PSK Wi-Fi network configuration for network (SSID)
"spg3", with SSID hex value "73706733"
[service_73706733]
Type=wifi
SSID=73706733
Security=psk
Passphrase=password
Hidden=false
When it reboots, if we check the connman service, it looks like this:
# connmanctl services wifi_b827eb52ccd0_73706733_managed_psk
/net/connman/service/wifi_b827eb52ccd0_73706733_managed_psk
Type = wifi
Security = [ psk ]
State = online
Strength = 48
Favorite = True
Immutable = True
AutoConnect = True
Name = spg3
Ethernet = [ Method=auto, Interface=wlan0,
Address=B8:27:EB:52:CC:D0, MTU=1500 ]
IPv4 = [ Method=dhcp, Address=192.168.2.41, Netmask=255.255.255.0,
Gateway=192.168.2.1 ]
IPv4.Configuration = [ Method=dhcp ]
IPv6 = [ Method=auto, Address=fd21:98c8:1d28:0:ba27:ebff:fe52:ccd0,
PrefixLength=64, Privacy=disabled ]
IPv6.Configuration = [ Method=auto, Address=fd21:98c8:1d28::41,
PrefixLength=64, Privacy=disabled ]
Nameservers = [ 2600:1700:4320:6caf:ba27:ebff:fe0b:9be6,
192.168.2.3, 2600:1700:4320:6caf:ba27:ebff:fe0b:9be6 ]
Nameservers.Configuration = [ ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ lan ]
Domains.Configuration = [ ]
Proxy = [ Method=direct ]
Proxy.Configuration = [ ]
mDNS = False
mDNS.Configuration = False
Provider = [ ]
but the iwctl shows this:
# iwctl known-networks spg3 show
Known Network: spg3
--------------------------------------------------------------------------------
Settable Property Value
--------------------------------------------------------------------------------
Name spg3
Hidden
* AutoConnect no
I cannot change this through the iwctl interface:
# iwctl known-networks spg3 set-property AutoConnect true
# iwctl known-networks spg3 show
Known Network: spg3
--------------------------------------------------------------------------------
Settable Property Value
--------------------------------------------------------------------------------
Name spg3
Hidden
* AutoConnect no
If I force a disconnect by rebooting, restarting the radio or
disconnecting from the router UI, the same thing happens as before.
The disconnection happens and no scanning occurs and it will never
reconnect.
The journal shows the deletion of the interface addresses and
iwd-monitor or connman-monitor shows no activity. I restart iwd, and
it immediately reconnects. If I check the iwctl now, it shows
"AutoConnect yes", so it appears it gets fixed when iwd was restarted:
# iwctl known-networks spg3 show
Known Network: spg3
--------------------------------------------------------------------------------
Settable Property Value
--------------------------------------------------------------------------------
Name spg3
Hidden
* AutoConnect yes
If I try this again, by restarting the radio on the router, I get the
same response in the journal. no scanning ever occurs. if I look at
monitor-iwd, monitor-connman or the journalctl no scanning happens.
I have verified that iwd works fine in standalone mode (internal dhcp)
or with dhcpcd. If I perform the same test, it reconnects in < 2
minutes every time. Also in the log it shows that iwd starts scanning
very soon after it is disconnected and finds the SSID and reconnects
(like all my other wifi devices). I really want connman to work for
this project and especially now that tethering works with the brcmfmac
driver. What can I do to log or help to figure out what is going on?
Keith
1 day, 11 hours
[RFC 0/8] Prevent IPv4 VPN data/DNS leak to IPv6 network(s)
by Jussi Laakkonen
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
traffic.
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
like this.
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(-)
--
2.20.1
1 week, 2 days
Re: [PATCH] service: Allow only user connection after WiFi failure
by Daniel Wagner
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
1 week, 5 days
Re: [PATCH] service: Prevent auto connection during passphrase
request
by Daniel Wagner
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
1 week, 5 days
[PATCH] dnsproxy: Enable DNS servers on connected VPN if split routing changes
by Jussi Laakkonen
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.
---
src/dnsproxy.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/dnsproxy.c b/src/dnsproxy.c
index 4f5c897f..de52df5a 100644
--- a/src/dnsproxy.c
+++ b/src/dnsproxy.c
@@ -2885,6 +2885,7 @@ static void dnsproxy_default_changed(struct connman_service *service)
bool server_enabled = false;
GSList *list;
int index;
+ int vpn_index;
DBG("service %p", service);
@@ -2901,6 +2902,13 @@ static void dnsproxy_default_changed(struct connman_service *service)
if (index < 0)
return;
+ /*
+ * In case non-split-routed VPN is set as split routed the DNS servers
+ * the VPN must be enabled as well, when the transport becomes the
+ * default service.
+ */
+ vpn_index = __connman_connection_get_vpn_index(index);
+
for (list = server_list; list; list = list->next) {
struct server_data *data = list->data;
@@ -2908,6 +2916,9 @@ static void dnsproxy_default_changed(struct connman_service *service)
DBG("Enabling DNS server %s", data->server);
data->enabled = true;
server_enabled = true;
+ } else if (data->index == vpn_index) {
+ DBG("Enabling DNS server of VPN %s", data->server);
+ data->enabled = true;
} else {
DBG("Disabling DNS server %s", data->server);
data->enabled = false;
--
2.20.1
2 weeks
[PATCH] timeserver: Fix false error message
by Justin Maggard
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.
---
src/timeserver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/timeserver.c b/src/timeserver.c
index a55f1f79..040a7aef 100644
--- a/src/timeserver.c
+++ b/src/timeserver.c
@@ -66,7 +66,7 @@ static void ntp_callback(bool success, void *user_data)
return;
}
- if (!gettimeofday(&tv, NULL)) {
+ if (gettimeofday(&tv, NULL) < 0) {
connman_warn("Failed to get current time");
}
--
2.31.0
2 weeks
[PATCH] iwd: Fix typo in error message when stopping AccessPoint mode
by Jonathan Liu
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")
---
plugins/iwd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/iwd.c b/plugins/iwd.c
index 21f646c5..0a25fabf 100644
--- a/plugins/iwd.c
+++ b/plugins/iwd.c
@@ -766,7 +766,7 @@ static void tech_disable_tethering_cb(const DBusError *error, void *user_data)
if (!g_dbus_proxy_method_call(iwdap->proxy, "Stop",
NULL, tech_ap_stop_cb, cbd, NULL)) {
- connman_warn("iwd ap %s could not start AccessPoint mode: %s",
+ connman_warn("iwd ap %s could not stop AccessPoint mode: %s",
cbd->path, error->message);
goto out;
}
--
2.30.1
2 weeks
Re: [PATCH] service: Fix disconnection search before connecting
by Daniel Wagner
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
2 weeks
Re: [PATCH] service: Complete only after user connection retries
by Daniel Wagner
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
2 weeks
Re: [PATCH] service: Add online to ready transition feature
by Daniel Wagner
Hi Emmanuel,
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 :)
Thanks,
Daniel
2 weeks
