[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)
3 weeks, 5 days
Why can't connman automatically enable and connect to cellular network interface?
by JH
Hi,
I installed oFono plugin to an embedded system where the cellular is
used, I suppose that the connman should automatically enable and
connect to cellular when it first time boot up, it didn't, I have to
manually run the connmanctl command to enable and to connect it. In a
product due to limited Flash storage size, I'll not install connmanctl
and there will be no manual interactive process, how can I set up
connman to automatically enable and connect to cellular network
interface?
Thank you.
Kind regards,
- jupiter
1 year
Race condition on too fast stop&&start resulting in Error /net/connman/technology/wifi: Not supported that does not recovery without another restart
by KARBOWSKI Piotr
Hi,
I am facing issue with connman-1.37 regarding the wireless network
access. If I restart connman that was already running, I will get not
working wireless connection
# connmanctl scan wifi
Error /net/connman/technology/wifi: Not supported
I can reproduce it on two separated Gentoo ~amd64 systems. One has Intel
9462 and the other with Intel 8265. The wireless connection never
recovery unless I restart connman one more time.
If I not use restart, but stop && start with sleep 3 in between for
example, everything works.
It looks to me like a race condition with whatever connman does to
iwlwifi device upon stopping, that is still 'on going' after connmand
exited, and when new one starts, it lacks code to retry bringing device
up after a delay when it fails for the first time, unless it silently
fails inside, somewhere.
Steps to reproduce:
While connman is running, run /etc/init.d/connman stop &&
/etc/init.d/connman start
The `connmanctl scan wifi` will not work regardless of how long one will
wait. The init script is the most basic one, all it does is
starts/terminates /usr/sbin/connmand.
Steps to reproduce with a workaround:
While connman is running, run /etc/init.d/connman stop && sleep 3 &&
/etc/init.d/connman start
The `connmanctl scan wifi` will work after a few seconds.
-- Piotr.
1 year, 5 months
ipv4 gateway is missing after configurations
by Daniel WANG
Hi,
Gateway address of eth0 cannot be configured or retrieved in IPv4 manual mode after some configurations.
The connection diagram: eth0 is connected to a switch chip that exposes swop0 and swop1. Ethernet cable is connected to swop1.
Version is v1.35.
Reproduce step:
1. eth0 is configured as IPv4 dhcp mode. All are ok. IP of eth0 is 10.177.71.43.
2. eth0 is re-configured as IPv4 manual mode by "connmanctl> config ethernet_xxxxxxxxxxxx_cable --ipv4 manual 192.168.0.2 255.255.255.0 192.168.0.1".
Then gateway of eth0 is empty and also cannot be configured again using "conmanctl".
>From "connmanctl", the status of Eth0 is as below:
Ethernet = [ Method=auto, Interface=eth0, Address=xx:xx:xx:xx:xx:xx, MTU=1500 ]
IPv4 = [ Method=manual, Address=192.168.0.2, Netmask=255.255.255.0 ]
IPv4.Configuration = [ Method=manual, Address=192.168.0.2, Netmask=255.255.255.0, Gateway=192.168.0.1 ]
1. Restart connman.service, the IPv4 manual mode is ok again. The status is as below:
Ethernet = [ Method=auto, Interface=eth0, Address=xx:xx:xx:xx:xx:xx, MTU=1500 ]
IPv4 = [ Method=manual, Address=192.168.0.2, Netmask=255.255.255.0, Gateway=192.168.0.1 ]
IPv4.Configuration = [ Method=manual, Address=192.168.0.2, Netmask=255.255.255.0, Gateway=192.168.0.1 ]
Sometimes, gateway is missing also in dhcp mode, but normally manual mode is easy to reproduce.
Is this a defect of ConnMan?
Thanks in advance for your reply.
Best Regards,
Daniel
*Please consider the environment before printing this e-mail
1 year, 5 months
Auto-connecting GSM/3G data when roaming
by Tarmo Kuuse
Hi!
I'd like for my device to automatically connect to 3G data in roaming
whenever GSM network permits it. I'd very much like to set this up as
default during manufacturing. What configuration options do I have?
Connman version 1.36, ofono version 1.21 (debian buster).
So far I tried setting configuration option
"AutoConnectRoamingServices=true" in file "/etc/connman/main.conf" and
restarted connman and ofono, but this doesn't seem to have any effect.
Option RoamingAllowed remains "false" in ofono config
(/var/lib/ofono/248030010014875/gprs). It seems like connman does not
tell ofono to enable roaming, so it remains disabled. Is this
configuration option perhaps not supported in 1.36?
I can tell ofono to enable roaming manually - either via the config file
or dbus interface, but I'd prefer that connman does that automatically
whenever I provision a SIM card with "connmanctl connect cellular_xxx"
or setting up the /var/lib/connman/ configuration files.
As context: working on a 3G-equipped gateway device, factory-installed
with a roaming-enabled SIM card and typically shipped to a foreign
country (mostly within EU where data roaming incurs no penalty). It's
rather desirable that 3G comes online without requiring any setup
whatsoever once the gateway is powered on in destination country.
--
Kind regards
Tarmo Kuuse
1 year, 5 months
IP Pool collision resolution not working when two technologies tethered
by Nuno Gonçalves
Hi,
Connman assigns by default the DHCP pool 192.168.0.x to the tether interface.
If another interface comes online with a IP in this subnet, then
__connman_ippool_newaddr calls collision_cb() to restart the tether
interface so that it gets a chance to get a new pool.
Unfortunately if two technologies are tethered (WiFi and Gadget), then
this logic does not work. It fails at
__connman_tethering_set_disabled, since tethering_enabled == 2.
I really don't understand the big picture to offer a patch for this. I
guess it's not enough to just remove this check!
Thanks,
Nuno
1 year, 5 months
provision an already connected service
by Christophe Ronco
Hi,
I have a problem when I try to provision a service that is already
connected and wasn't provisioned before.
Here is what happened:
Initial situation:
I use connman 1.36. I only have one Ethernet service.
Ethernet service is not provisioned so it defaults to DHCP, found a DHCP
server and obtained an IP address.
Event:
I create /etc/network/connman/kconf.config (/etc/network/connman is my
storage dir in my setup) with these data:
[service_lan]
Type = ethernet
IPv4 = 192.168.4.181/192.168.4.4/255.255.254.0
Nameservers = 8.8.8.8
These values are taken into account for Ethernet service:
root@klk-wiis-020006:~ # connmanctl
connmanctl> services ethernet_7076ff030010_cable
/net/connman/service/ethernet_7076ff030010_cable
Type = ethernet
Security = [ ]
State = online
Favorite = True
Immutable = True
AutoConnect = True
Name = Wired
Ethernet = [ Method=auto, Interface=eth0, Address=70:76:FF:03:00:10,
MTU=1500 ]
IPv4 = [ Method=fixed, Address=192.168.4.181, Netmask=255.255.254.0,
Gateway=192.168.4.4 ]
IPv4.Configuration = [ Method=fixed, Address=192.168.4.181,
Netmask=255.255.254.0, Gateway=192.168.4.4 ]
IPv6 = [ Method=auto, Address=fdf4:ffb1:9715:b409:7276:ffff:fe03:10,
PrefixLength=64, Privacy=disabled ]
IPv6.Configuration = [ Method=auto, Privacy=disabled ]
Nameservers = [ 8.8.8.8 ]
Nameservers.Configuration = [ ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ klksi.fr ]
Domains.Configuration = [ ]
Proxy = [ Method=direct ]
Proxy.Configuration = [ ]
mDNS = False
mDNS.Configuration = False
Provider = [ ]
But current configuration is not modified (still got DHCP address):
root@klk-wiis-020006:~ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 70:76:FF:03:00:10
inet addr:192.168.4.110 Bcast:192.168.5.255 Mask:255.255.254.0
inet6 addr: fdf4:ffb1:9715:b409:7276:ffff:fe03:10/64 Scope:Global
inet6 addr: fe80::7276:ffff:fe03:10/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1510 errors:0 dropped:8 overruns:0 frame:0
TX packets:190 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:182964 (178.6 KiB) TX bytes:42668 (41.6 KiB)
In connman debug traces (attached) it seems that service is not
disconnected-reconnected. That's why there is a difference between
current real eth0 configuration and connman DBUS properties. This can be
fixed by a connman restart (this time, information in kconf.config file
will be used to connect ethernet device using fixed IP address).
If I do the same thing with an already provisioned service, it is
correctly disconnected and reconnected. At the end of operation, eth0
IP, gateway, ... is aligned with configuration in kconf.config file even
without a connman restart.
I made a patch (attached) to fix this problem. The idea is to force
service disconnection when connman knows that a new configuration is
available for this service. I have simply copied what is done in
unregister_service (src/config.c).
My questions are:
1) Do you think the behavior described here is a bug or should I not do
this (provision a connected service) / do this differently?
2) If it is a bug, is this the right way to fix it?
I will be without mail access until end of July. If you think this is a
bug and wants a patch quicker than that, please do the correct patch. If
you can wait and give me advice on what would be a correct patch, I can
submit this patch when I am back from holidays.
Best Regards,
Christophe Ronco
1 year, 6 months
Failed to bring WiFi up
by JH
Hi,
I am running connman on uBlox EMMY WiFi in sdio interface, it brought
up the interface, but could not assign the IP address to it, there are
some mwifiex_sdio error which I don't know what is going on,
appreciate your insight advice. Thank you.
Jul 08 08:51:27 solar connmand[183]: Skipping disconnect of
5450472d4d434e46_managed_psk, network is connecting.
Jul 08 08:51:27 solar connmand[183]: mlan0 {RX} 74 packets 8824 bytes
Jul 08 08:51:27 solar connmand[183]: mlan0 {TX} 71 packets 9585 bytes
Jul 08 08:51:27 solar connmand[183]: mlan0 {update} flags 102403 <UP,LOWER_UP>
Jul 08 08:51:27 solar connmand[183]: mlan0 {newlink} index 3 address
D4:CA:6E:64:E3:9D mtu 1500
Jul 08 08:51:27 solar connmand[183]: mlan0 {newlink} index 3 operstate
5 <DORMANT>
Jul 08 08:51:37 solar connmand[183]: mlan0 {RX} 77 packets 9163 bytes
Jul 08 08:51:37 solar connmand[183]: mlan0 {TX} 75 packets 10125 bytes
Jul 08 08:51:37 solar connmand[183]: mlan0 {update} flagsmwifiex_sdio 36867 <UP>
Jul 08 08:51:37 solar connmand[183]: mlan0 {newlink} index 3 address
D4:CA:6E:64:E3:9D mtu 1500
Jul 08 08:51:37 solar connmand[183]: mlan0 {newlink} index 3 operstate 2 <DOWN>
Jul 08 08:52:01 solar connmand[183]: mlan0 {RX} 78 packets 9276 bytes
Jul 08 08:52:01 solar connmand[183]: mlan0 {TX} 75 packets 10125 bytes
Jul 08 08:52:01 solar connmand[183]: mlan0 {update} flags 102403 <UP,LOWER_UP>
Jul 08 08:52:01 solar connmand[183]: mlan0 {newlink} index 3 address
D4:CA:6E:64:E3:9D mtu 1500
Jul 08 08:52:01 solar connmand[183]: mlan0 {newlink} index 3 operstate
5 <DORMANT>
Jul 08 08:52:11 solar connmand[183]: mlan0 {RX} 81 packets 9615 bytes
Jul 08 08:52:11 solar connmand[183]: mlan0 {TX} 79 packets 10665 bytes
Jul 08 08:52:11 solar connmand[183]: mlan0 {update} flags 36867 <UP>
Jul 08 08:52:11 solar connmand[183]: mlan0 {newlink} index 3 address
D4:CA:6E:64:E3:9D mtu 1500
Jul 08 08:52:11 solar connmand[183]: mlan0 {newlink} index 3 operstate 2 <DOWN>
Jul 08 08:52:19 solar connmand[183]: Network SSID not set
root@solar:/root# [ 4160.455462] mwifiex_sdio mmc0:0001:1: info:
trying to associate to 'TPG-MCNF' bssid 50:04:b8:60:c3:0c
[ 4160.486629] mwifiex_sdio mmc0:0001:1: info: associated to bssid
50:04:b8:60:c3:0c successfully
[ 4170.557961] mwifiex_sdio mmc0:0001:1: info: successfully
disconnected from 50:04:b8:60:c3:0c: reason code 3
[ 4178.096368] ieee80211 phy0: mwifiex_cfg80211_sched_scan_start :
Invalid Sched_scan parameters
[ 4187.082236] ieee80211 phy0: mwifiex_cfg80211_sched_scan_start :
Invalid Sched_scan parameters
1 year, 6 months
dnsproxy: invalid answer where there are no DNS servers available
by Nuno Gonçalves
Hi,
Typing "ping abcd", where abcd does not exist on /etc/hosts or in the
search domains, will usually hang for a while with Connman.
I've compared with other systems and my conclusion is that libnss_dns
is retrying the DNS request to connman, since connman answer does not
include the query field.
This behaviour comes from [1], where both a invalid Query and no
upstream servers are handled in the same way.
I believe the query field must be part of the answer when the Query
message was valid, but just happens to not be possible to resolve.
Thanks,
Nuno
[1] https://git.kernel.org/pub/scm/network/connman/connman.git/tree/src/dnspr...
1 year, 6 months
[PATCH] service: Prevent sending D-Bus error reply twice with hidden networks
by Jussi Laakkonen
When the input request has timed out or some other error has occurred do
not allow to send duplicate D-Bus error replies. This would result in
crashes when hidden network is first informed with ETIMEDOUT and error
is returned and if the __connman_device_request_hidden_scan() reports an
error or that it is already running (EALREADY) and then second error
reply is sent.
After each reply to pending D-Bus message (reply_pending()) the
service->pending is set NULL but since request_input_cb() holds the
reference to the pending D-Bus message (user_data) there will be a
second reply.
This fixes the issue by 1) recording the error also when D-Bus error is
other than Canceled to prevent connecting attempt at done label and 2)
skipping hidden network connect in such case as well.
---
src/service.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/service.c b/src/service.c
index f71a3de7..6f467eaf 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5666,12 +5666,15 @@ static void request_input_cb(struct connman_service *service,
__connman_service_return_error(service,
ECONNABORTED,
user_data);
- goto done;
} else {
+ err = -ETIMEDOUT;
+
if (service->hidden)
__connman_service_return_error(service,
ETIMEDOUT, user_data);
}
+
+ goto done;
}
if (service->hidden && name_len > 0 && name_len <= 32) {
--
2.20.1
1 year, 6 months
