August 2020 - connman

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, 2 weeks

4
4
0 / 0

[PATCH] iptables: Fix incorrect code

by Rahul Jain

[PATCH] iptables: Fix incorrect code Signed-off-by: Bhaskar Dutta <bhaskar.d(a)samsung.com> Signed-off-by: Rahul Jain <rahul.jain(a)samsung.com> --- src/iptables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/iptables.c b/src/iptables.c index 47ea1c2..6feb007 100644 --- a/src/iptables.c +++ b/src/iptables.c @@ -3383,7 +3383,7 @@ static int parse_rule_spec(struct connman_iptables *table, break; if (invert) - ctx->ip->invflags |= IP6T_INV_DSTIP; + ctx->ipv6->invflags |= IP6T_INV_DSTIP; } break; -- 2.7.4

4 months, 2 weeks

5
6
0 / 0

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>

5 months

5
35
0 / 0

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

5 months

5
10
0 / 0

ConnMan returns connect-failed when entering wrong password

by Sven Dembianny

Hi all, when entering a wrong password, I expected ConnMan to return the error string "invalid-key". This worked with wpa_supplicant 2.5, but since upgrading to wpa_supplicant 2.9, ConnMan returns "connect-failed". ConnMan assumes the password to be incorrect, if wpa_supplicant was in the 4WAY_HANDSHAKE state before disconnecting: https://git.kernel.org/pub/scm/network/connman/connman.git/tree/plugin s/wifi.c?h=1.38#n2537 As far as I understand, the problem is that wpa_supplicant now supports offloading the 4-way handshake into the driver and it skips this state completely. For comparison, here is a D-Bus dump with wpa_supplicant 2.5: https://pastebin.com/raw/60064sgt and here with wpa_supplicant 2.9: https://pastebin.com/raw/hQetZq7C Thanks, Sven

5 months, 2 weeks

3
4
0 / 0

Writing plugins: how to provide a "technology"?

by Sergey 'Jin' Bostandzhyan

Hi, I am currently learning how connman plugins work, I started with plugin-api.txt and also looked the sources, then tried to follow the plugin document to get a "proof of concept" going. So far I can see that the init function of my plugin is being called, but that's it. I did register tech, network and device callbacks via connman_network_driver_register(), connman_device_driver_register() and connman_technology_driver_register(), but I do not see any printouts in the callbacks, no probes, nothing. Could someone please explain what needs to be done in order for a technology to become visible? I guess same is valid for "device" and "network". When I look at other plugins (for instance ethernet), the only thing their probes do is to return 0. So how exactly does it work? Am I supposed to use some notification mechanisms that are not mentioned in the plugin documentation or what am I missing? Kind regards, Jin

6 months, 1 week

2
1
0 / 0

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

7 months

4
9
0 / 0

2021

2020

2019

2018

2017

2016

2015

connman August 2020