[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)
1 year, 6 months
connman wifi disconnect problem
by KeithG
I have been trying to diagnose a problem I am having with my RPis. I am
using iwd and connman to manage my ethernet connectivity. What I have
noticed is that after a while, sometimes, connectivity stops and I cannot
reconnect except after a reboot. I have seen this on RPi3's more so than
with RPi1/2. I have only noticed it with wlan0 and not with ethernet.
From the journal, it looks like the network goes down (wlan0), connman
quickly notes it is down and pulls the ip address and sets the interface
down and then avahi identifies that it is down. It is interesting that
sometime before this, the ipv4 address was withdrawn. I am running an
openWRT router (other side of the DHCP equation) and this RPI MAC has a
reserved ipv4 address on the router.
If I restart connman on the RPi, it will not regain connectivity on ipv4 or
ipv6 on wlan0. If I reboot the router and then restart connman on the RPi,
it will not regain connectivity. I have to power cycle the RPI to get it to
connect again. If I plug in the ethernet cable, it grabs an address
immediately and everything is back, but it will still not reconnect over
wifi. I must reboot the RPi to get it to reconnect. I will see if I can
figure out how to have journal log more info on connman...
Any idea what this could be? I will flash the router with ddwrt and see if
it is the router.
In my /etc/connman/main.conf, I have this:
[General]
FallbackNameservers = 8.8.8.8,8.8.4.4
DefaultAutoConnectTechnologies = ethernet,wifi
PreferredTechnologies = ethernet,wifi
AllowHostnameUpdates = false
SingleConnectedTechnology = true
AlwaysConnectedTechnologies = ethernet,wifi
AutoConnectRoamingServices = true
The journal shows this:
Jun 20 18:02:19 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:02:20 rune64 systemd[1]: dbus-org.freedesktop.timedate1.service:
Succeeded.
Jun 20 18:02:35 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:02:39 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
... lots of these 'not responding'...
Jun 20 18:07:54 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Withdrawing address record for
2601:241:4200:255:ba27:ebff:fe52:ccd0 on wlan0.
Jun 20 18:07:55 rune64 connmand[259]: wlan0 {del} address
2601:241:4200:255:ba27:ebff:fe52:ccd0/64 label (null)
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Leaving mDNS multicast group on
interface wlan0.IPv6 with address 2601:241:4200:255:ba27:ebff:fe52:ccd0.
Jun 20 18:07:55 rune64 avahi-daemon[6529]: Joining mDNS multicast group on
interface wlan0.IPv6 with address fdcb:9d61:70f3:0:ba27:ebff:fe52:ccd0.
Jun 20 18:07:57 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:10 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:13 rune64 kernel: nfs: server 192.168.2.198 not responding,
timed out
Jun 20 18:08:14 rune64 connmand[259]: wlan0 {del} route 2601:241:4200:255::
gw :: scope 0 <UNIVERSE>
1 year, 8 months
ipv6 test web page down
by KeithG
DOn't know if this is the right place or not, but since moving to connman,
I have noticed that the ipv6 test page is down. the ipv4 one works fine,
but I get a mention in the log:
"connmand[254]: Failed to find URL:
http://ipv6.connman.net/online/status.html"
If I try to get to it from a browser, I get a '502 bad gateway error'
If I use curl on the cli, I get this:
# curl ipv4.connman.net/online/status.html
<html>
<head>
</head>
<body>
</body>
</html>
# curl ipv6.connman.net/online/status.html
<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx</center>
</body>
</html>
I think something is not set right on the server...
Keith
1 year, 8 months
Any experience running Apple's Bonjour Conformance Tests against
connman?
by Michael Sweet
Hi,
I'm in the process of developing a Yocto-based embedded solution (Wi-Fi only, similar to Raspberry Pi Zero W) with connman as the network manager. This solution needs to pass Apple's Bonjour Conformance Tests, and I've been having some difficulties getting the current version (1.38) of connman to pass.
I've set the AddressConflictDetection option to true in connman's main.conf which helps me get through most of the IPv4LL tests, but the hot-plug tests (where you have to force the Wi-Fi interface to disassociate from the AP) are failing.
Thoughts?
________________________
Michael Sweet
1 year, 10 months
[PATCH 0/2] A couple of small fixes
by Daniel Wagner
Two small fixes found while ramping up again...
Daniel Wagner (2):
vpn: Send D-Bus response when connecting for daemon-less setups
session: Fix state initializiation
src/session.c | 2 +-
vpn/plugins/vpn.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.27.0
1 year, 10 months
corrupted DNS entry with connman
by Terry Bolinger
We have a product that we are selling that uses the Beaglebone Black SBC with Debian Jessie as a small network appliance in a residential environment. Connman is the network manager in this distribution. We are experiencing a very random issue where occasionally the DNS servers being returned by a network DHCP server get corrupted. All other configurations are fine - IP address, gateway, etc. When this happens, the unit still has local network connection but loses the connection to the Internet (as you would expect). This impacts the operation of the unit in a very negative manner. We have a user interface that shows the configuration settings and when the Primary DNS server gets corrupted, the user interface field normally shows the DNS server as " [ ". The Secondary DNS server is mostly blank when this happens. Manually changing the Primary DNS Server to a good nameserver always resolves the issue.
It happens often enough that it's annoying us because of the support calls we get, but it happens so infrequently that it's very difficult to reproduce. In fact, I've never seen it on my test units - I've only seen it on units installed in the field.
In almost all applications, the network appliance is connected directly to the local network router provided by the ISP or the user. We believe that something happens from the router that causes this issue (and it could even be with specific routers - we just don't know). In one particular instance, a unit had been working for several months just fine, but then there was a power outage, and after rebooting from the power outage, the Primary DNS was showing the " [ " and the Secondary DNS was blank, and we had to manually enter a good nameserver.
Since it's so hard to reproduce, I'm looking at some bandaid approaches using some scripts. But, before I did that, I thought I'd check to see if connman might have some options that I could use to resolve the issue. One potentially available option I was reading about was the use of the nodnsproxy option. This one might be extremely hard to determine if it has resolved the issue or not, as it is so hard to reproduce but would be simple to implement, if it were a potential solution. This would assume that DNS proxy feature in connman was in conflict with the external DNS server, as I was reading, which might be a real stretch.
A second option I was looking at was the "FallbackNameservers" option. However, I don't understand how this works. Does connman do a test to verify Internet connection or proper DNS operation, and if it fails that test, it "falls back" to a secondary DNS server and then if that also fails, it falls back to the "FallbackNameservers"? If this is how this works, this is a possibility to explore - I would try setting the FallBack servers to available DNS servers such as the Google nameserver at 8.8.8.8.
By the way, the connman version on my Debian distribution is V1.32. I see that connman is up to at least 1.37. Is it possible that upgrading connman might resolve this issue?
I apologize - I'm comfortable with simple networking but I'm by no means a networking expert and I'm really hoping for a sanctioned option to resolve this issue.
Any guidance would be appreciated.
1 year, 11 months
