[PATCH] Force BSS expiration
by Yasser
We were having a problem with our wifi scanning, where the list of
wifi available would become empty and would not be repopulated until
after a long delay. Researching the problem it seemed that it was
related to BSS expiration age. There were already some people who had
faced the same issue, so inspired by this we developed the following
patch which allows us to set the BSS expiration age to match ConnMan
long scanning interval to avoid the loss of networks during a long
interval between two scans.
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index bfb52db..08d6b9e 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -267,7 +267,8 @@ int
g_supplicant_interface_connect(GSupplicantInterface *interface,
int g_supplicant_interface_disconnect(GSupplicantInterface *interface,
GSupplicantInterfaceCallback callback,
void *user_data);
-
+int g_supplicant_interface_set_bss_expiration_age(GSupplicantInterface
*interface,
+ unsigned int
bss_expiration_age);
int g_supplicant_interface_set_apscan(GSupplicantInterface *interface,
unsigned int ap_scan);
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 6052f7b..fe6ad48 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -981,6 +981,46 @@ static void interface_capability(const char *key,
DBusMessageIter *iter,
key, dbus_message_iter_get_arg_type(iter));
}
+struct g_supplicant_bss_expiration_age
+{
+ GSupplicantInterface *interface;
+ unsigned int bss_expiration_age;
+};
+
+static void set_bss_expiration_age(DBusMessageIter *iter, void *user_data)
+{
+ struct g_supplicant_bss_expiration_age *data = user_data;
+ unsigned int bss_expiration_age = data->bss_expiration_age;
+
+ dbus_free(data);
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_UINT32,
&bss_expiration_age);
+}
+
+int g_supplicant_interface_set_bss_expiration_age(GSupplicantInterface
*interface,
+ unsigned int
bss_expiration_age)
+{
+ struct g_supplicant_bss_expiration_age *data;
+ int ret;
+
+ data = dbus_malloc0(sizeof(*data));
+
+ if (!data)
+ return -ENOMEM;
+
+ data->bss_expiration_age = bss_expiration_age;
+ data->interface = interface;
+
+ ret = supplicant_dbus_property_set(interface->path,
+ SUPPLICANT_INTERFACE ".Interface",
+ "BSSExpireAge", DBUS_TYPE_UINT32_AS_STRING,
+ set_bss_expiration_age, NULL, data, NULL);
+ if (ret < 0)
+ dbus_free(data);
+
+ return ret;
+}
+
+
struct set_apscan_data
{
unsigned int ap_scan;
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 910b739..57b63e2 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1522,6 +1522,7 @@ static void interface_create_callback(int result,
void *user_data)
{
struct wifi_data *wifi = user_data;
+ char * bgscan_range_max;
DBG("result %d ifname %s, wifi %p", result,
g_supplicant_interface_get_ifname(interface),
@@ -1537,6 +1538,13 @@ static void interface_create_callback(int result,
wifi->interface_ready = true;
finalize_interface_creation(wifi);
}
+ /* Force the BSS expiration age to match ConnMan long scanning
interval to avoid the loss of networks during a long interval between
two scannings. */
+ if ((bgscan_range_max = strrchr(BGSCAN_DEFAULT,':')) != NULL &&
+
g_supplicant_interface_set_bss_expiration_age(interface,
strtol(bgscan_range_max + 1, (char**)NULL, 10) + 10) >= 0) {
+ DBG("bss expiration age successfully updated");
+ } else {
+ DBG("bss expiration age update has failed");
+ }
}
static int wifi_enable(struct connman_device *device)
2 months, 1 week
[PATCH v1 00/11] Set IPv6 default route
by Daniel Wagner
Currently, ConnMan relies on the kernel to set the IPv6 default route
(accept_ra=1). This works only if the system has one interface
active. Obviously, ConnMan should be in charge updating the routing
IPv6 routing table as well. This series addresses this problem.
I've still limited IPv6 testing environment, so I hope this works
not just for me.
- The first three few patches improve the logging.
- Patch 4 and 5 allow ConnMan to disable accept_ra
- Patch 6 to 10 add the missing code to forward the default route to
route selection code (connection.c)
- The last patch fixes a bug in connetion, so far ConnMan would
not clear the IPv6 default route.
Daniel Wagner (11):
inet: Add index to debug output when sending RS
inet: Improve the routing logging
connection: Improve logging
ipconfig: Factor out sysfs getter/setter
ipconfig: Disable accept_ra on managed interfaces
inet: Add source address to RS callback
network: Forward IPv6 gateway information to service
dhcpv6: Do not clear gateway address when setting IP
network: Add IPv6 gateway when setting the IPv6 address
connection: Reorder gateway set/unset operations
connection: Delete IPv6 default routes
src/6to4.c | 3 +-
src/connection.c | 80 +++++++++++++---------
src/connman.h | 3 +-
src/dhcpv6.c | 10 ++-
src/inet.c | 16 +++--
src/ipconfig.c | 175 ++++++++++++++++++++++-------------------------
src/network.c | 25 ++++++-
7 files changed, 172 insertions(+), 140 deletions(-)
--
2.29.2
2 months, 3 weeks
Re: dhcp discover timeout
by Daniel Wagner
Hi Pieter,
On Mon, Nov 30, 2020 at 02:14:03PM +0000, Pieter Cardoen wrote:
> I'm noticing that the dhcp discover indeed continues sending requests:
> Send 6 discovers with 5 seconds interval - wait 65 seconds - repeat.
Glad this works. Thanks for confirming.
> connmand[611]: x1 {add} address 169.254.98.96/16 label x1 family 2
> connmand[611]: x1 {add} route 169.254.0.0 gw 0.0.0.0 scope 253 <LINK>
> connmand[611]: x1 {add} route 0.0.0.0 gw 0.0.0.0 scope 253 <LINK>
>
> Why is the static ip address assigned?
The 169.254.x.x/16 IPs are link local addresses (rfc3927). ConnMan will
fallback to the IPv4LL when DHCP fails. But in background ConnMan will
continue to send out DHCP request, although in a less aggressive
way. There is a back-off algorithm involved.
When eventually there is DHCP response, ConnMan will assign the IP
address from DHCP but will keep the IPv4LL alongside. CannMan can't know
if the IPv4LL is in use, so it plays safe and keeps it.
You should see two IP address assign in this case, when doing 'ip a'.
Hope this helps.
Thanks,
Daniel
3 months
Re: dhcp discover timeout
by Daniel Wagner
Hi Pieter,
On Wed, Oct 07, 2020 at 10:12:03AM +0000, Pieter Cardoen wrote:
> We are using connman as network manager for our embedded devices. We are currently facing an issue regarding DHCP.
>
> I've noted that if a service is configured to use DHCP, a DHCP discover message is sent multiple times (DISCOVER_RETRIES). If the DHCP server doesn't respond in time, a fallback scenario is used and a fixed static IP address is configured instead.
>
> For or application, this behaviour is unexpected and a device should keep sending discover messages until the end of times 😋.
>
> We currently applied a dirty fix (see below). What is the reason of this fallback behaviour and is it possible to configure connman to keep sending discovers in a better way?
Which version of ConnMan are you using. The current version should keep
sending DHCP discovery message.
Thanks,
Daniel
3 months
[PATCH v1 11/11] connection: Delete IPv6 default routes
by Daniel Wagner
The correct way to delete the default route is to use
__connman_inet_del_default_from_table. connman_inet_clear_ipv6_gateway_address()
will only remove the additional route to reach the gateway on given
interface but not the default route. IPv4 and IPv6 seems to behave
slightly different, as connman_inet_clear_ipv4_gateway_address removes
the default route as well.
---
src/connection.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index d1e07febf931..2642a02b22a9 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -579,12 +579,12 @@ static void unset_default_gateway(struct gateway_data *data,
}
if (do_ipv4 && data->ipv4_gateway)
- connman_inet_clear_gateway_address(index,
- data->ipv4_gateway->gateway);
+ __connman_inet_del_default_from_table(RT_TABLE_MAIN,
+ index, data->ipv4_gateway->gateway);
if (do_ipv6 && data->ipv6_gateway)
- connman_inet_clear_gateway_address(index,
- data->ipv6_gateway->gateway);
+ __connman_inet_del_default_from_table(RT_TABLE_MAIN,
+ index, data->ipv6_gateway->gateway);
}
static struct gateway_data *find_default_gateway(void)
--
2.29.2
3 months
[PATCH v1 10/11] connection: Reorder gateway set/unset operations
by Daniel Wagner
To make the code more consistent with the rest do first the IPv4
operations and then the IPv6.
---
src/connection.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index d5c936ee3183..d1e07febf931 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -504,14 +504,14 @@ static void set_default_gateway(struct gateway_data *data,
goto done;
}
- if (do_ipv6 && data->ipv6_gateway)
- status6 = __connman_inet_add_default_to_table(RT_TABLE_MAIN,
- index, data->ipv6_gateway->gateway);
-
if (do_ipv4 && data->ipv4_gateway)
status4 = __connman_inet_add_default_to_table(RT_TABLE_MAIN,
index, data->ipv4_gateway->gateway);
+ if (do_ipv6 && data->ipv6_gateway)
+ status6 = __connman_inet_add_default_to_table(RT_TABLE_MAIN,
+ index, data->ipv6_gateway->gateway);
+
if (status4 < 0 || status6 < 0)
return;
@@ -578,13 +578,13 @@ static void unset_default_gateway(struct gateway_data *data,
return;
}
- if (do_ipv6 && data->ipv6_gateway)
- connman_inet_clear_ipv6_gateway_address(index,
- data->ipv6_gateway->gateway);
-
if (do_ipv4 && data->ipv4_gateway)
connman_inet_clear_gateway_address(index,
data->ipv4_gateway->gateway);
+
+ if (do_ipv6 && data->ipv6_gateway)
+ connman_inet_clear_gateway_address(index,
+ data->ipv6_gateway->gateway);
}
static struct gateway_data *find_default_gateway(void)
--
2.29.2
3 months
[PATCH v1 0/3] Change auto connect strategy for iwd
by Daniel Wagner
As reported by KeithG, ConnMan's auto connect doesn't work well with
iwd. ConnMan disabled the autoconnect modus of iwd for all
networks. This let iwd chill and slow down the scaning thus finding a
network took pretty long. This series will set the auto_connect
property for iwd's KnowNetworks when the corresponding ConnMan service
has the AutoConnect set. In my simple setup it seems to work.
Daniel Wagner (3):
network: Add connman_network_set_autoconect()
service: Propagade autoconnect mode to network
iwd: Enable/disable auto_connect on known networks
include/network.h | 4 +
plugins/iwd.c | 258 ++++++++++++++++++++++++++++++----------------
src/network.c | 8 ++
src/service.c | 4 +
4 files changed, 184 insertions(+), 90 deletions(-)
--
2.29.2
3 months
4G modem re-register
by Jupiter
Hi,
I am running oFono and Connman for uBlox SARA modem in QMI on iMX6,
when the modem is deregistered due to low signal, it cannot not be
re-registered automatically.
The SARA modem is capable of re-register, I can verify that capacity
in SARA EVK, but why that capacity cannot be performed in an oFono
device? What could I be missing in oFono configuration?
Thank you.
Kind regards,
- jh
3 months, 2 weeks
[PATCH] vpn-provider: Emit connection created signal if loading from keyfile
by Jussi Laakkonen
Emit the connection created signal also when loading a VPN connection
from keyfile. This signal was sent in every other case where a VPN
connection was created (via D-Bus or from config). Emit the signal only
when new one is created, i.e., not when modifying existing VPN.
---
vpn/vpn-provider.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/vpn/vpn-provider.c b/vpn/vpn-provider.c
index bf20ed6e..5d0fb2ce 100644
--- a/vpn/vpn-provider.c
+++ b/vpn/vpn-provider.c
@@ -2112,9 +2112,12 @@ static struct vpn_provider *provider_create_from_keyfile(GKeyFile *keyfile,
return NULL;
}
- if (provider_register(provider) == 0)
+ if (!provider_register(provider)) {
connection_register(provider);
+ connection_added_signal(provider);
+ }
}
+
return provider;
}
--
2.20.1
3 months, 3 weeks
Different WIFI reconnect problem
by tomg＠mycabin.org
I'm having an issue with Connman re-connecting to an AP. In this case,
we have a fairly standard Intel wifi chip. We're connected to an AP
that is closeand has good signal. The user, however, shutds down his AP
at night, and in the morning restarts it. At this point connman
reconnects, bur our application that is still running receives only the
connection event. That event doesn't contain any of the network state
information, or th ecurrent state of the connection, so our application
can't tell if it's up or not. This only happens when the AP has be down
for a long time. at 10 or 15 minute disconnect is fine.
Attached is the output from running connman -d -n and capturing the
output. I would appreciate any help looking for where this is
happening, and why. If you can give me any pointers, it would most
helpful.
Thanks,
Tom Green
3 months, 3 weeks
