September 2019 - 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)

1 month

4
4
0 / 0

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

4
23
0 / 0

Connman and IWD - Scanning Network - Update?

by stef204

Hi, With reference to this <https://lists.01.org/pipermail/connman/2018-August/022915.html> and this <https://lists.01.org/pipermail/iwd/2018-August/004751.html> are there any updates or further progress to achieve scanning networks with ConnMan + IWD? Thanks.

1 year, 3 months

2
4
0 / 0

Insights on connmand -d

by JH

Could anyone give some insights on what connmand -d differs to connmand -n running by systemctl? From reading the documentation, my understanding is it should be identical except increasing debug level to printing out more debug messages, but the systemd service connmand -n incapable of bringing my LTE modem up makes my wandering what I could get wrong here, could the connman -n service messages be blocked by journal logs? Appreciate anyone helps to fix it, Thank you. Kind regards. On 9/28/19, JH <jupiter.hce(a)gmail.com> wrote: > Hi, > > I thought connmand -d just for running debug mode, then I was puzzled, > if I run systemctl start connman, the LTE cannot be connected, if I > run connmand -d, the LTE modem can be connected on, is it LTE modem > problem or connman problem? > > Thank you. > > Kind regards, > > - jh >

1 year, 3 months

2
2
0 / 0

magic connmand -d

by JH

Hi, I thought connmand -d just for running debug mode, then I was puzzled, if I run systemctl start connman, the LTE cannot be connected, if I run connmand -d, the LTE modem can be connected on, is it LTE modem problem or connman problem? Thank you. Kind regards, - jh

1 year, 3 months

1
0
0 / 0

[PATCH 0/4] RE: Propose patch for continuous online check for connected services

by aleksandar＠analyticsfire.com

From: Aleksandar Mitev <shondll(a)yahoo.com> Hi Daniel, Following your advice on every commit, I resubmit the patches again. I hope I've got everything sorted out. I agree with the name change, indeed "perpetual" sounds more epic but does not have the necessary semantics. The state diagram in the doc section is updated as well. Best, Aleksandar Aleksandar Mitev (4): gweb: added timeout to socket connections service: perform continuous online checks service: Added a compile config for online check doc: updated state diagram for services README | 10 ++++++ configure.ac | 6 ++++ doc/overview-api.txt | 25 +++++++++----- gweb/gweb.c | 27 +++++++++++++++ src/service.c | 78 +++++++++++++++++++++++++++++++++++++++++--- 5 files changed, 133 insertions(+), 13 deletions(-) -- 2.17.1

1 year, 3 months

1
4
0 / 0

[PATCH v2 0/2] Fix connections to VPN servers on local network

by Santtu Lakkala

When VPN server resides on local network, a route via default gateway must not be added for it to remain reachale. Add a check using existing IPv4 helper, and introduce a new helper for IPv6. Santtu Lakkala (2): inet: Add connman_inet_compare_ipv6_subnet() connection: Fix connections to local VPN servers include/inet.h | 1 + src/connection.c | 13 +++++++++++ src/inet.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 75 insertions(+) -- 2.20.1

1 year, 3 months

2
3
0 / 0

[PATCH] PrefixLength handling for IPv4 and better error reporting

by Benjamin Cama

Hi, Here are two patches I am using for some time which allow specifying a prefixlen for IPv4 by D-Bus, which I find very handy. The second one also help catching errors. They are a bit old so I do not remember the details, but I hope they help. Regards, Benjamin

1 year, 3 months

2
4
0 / 0

[PATCH 0/3] Re: Propose patch for perpetual online check for connected services

by aleksandar＠analyticsfire.com

From: Aleksandar Mitev <shondll(a)yahoo.com> Hi, Thanks for the lively discussion on this proposed change. Taking into account all the notes and concerns I think I came up with a balanced solution: - regular online check is now governed by a compile time optio rather than a runtime one in the configration file - the proposed update to the state machine is disabled by default leaving the current behaviour in place. Btw, please advise on a better use of compile time defines (if you happen to find the current implementation not suiatable) as there are no usual #ifdef..#endif blocks in the project. >On 9/4/19 5:22 PM, Slava Monich wrote: >>> As of v1.37, when a service reaches the READY state, then the online >>> check is started. If it succeeds, the a transition to ONLINE state >>> happens. You are right in thinking that my proposed change will cause >>> a downgrading to READY again, but you see, according to the state >>> machine, another round of online checking will begin, possibly >>> promoting the service back to ONLINE it it ever succeeds (ex. the >>> Internet disruption was temporary). In general, this is a chance for >>> any of the other services in READY state to take over. >> >> Are you sure that another service WILL actually take over when some >> other service is stuck in the READY state? That's the key point. > >I agree. There are many small problems along the road. > Yes, it does happen in our use case (provided the number of failed online checks is reached). >> If such a handover doesn't happen then this transition back to READY is >> useless. It will be just generating additional network traffic and >> that's it. >> >> If handover does indeed happen then it's a major change of behavior and >> must be configurable. We (Sailfish OS) consider READY as of the >> "connected" states. We don't need and don't want to automatically switch >> from WiFi to mobile data if WiFi gets stuck in the READY state. We still >> consider it connected and let the user to turn it off and switch to >> mobile data, if the user notices that it's not actually working. > >Okay, understood. If we going to mess with the current state machine we >need to keep a compact mode. I suppose compile time would be good enough? > >>> Finally, if a failed online check is not reliable enough to determine >>> Internet reachability, then it can be disabled altogether and replaced >>> with a simple ping check (from a separate service) as in the case of >>> mwan3 tool for Openwrt. However, in that case one will miss the >>> checking of DNS working. >>> >>> Please share more details if you think I am missing smth here. >>> >> >> Have you considered the VPN scenario? When VPN is connected, you may not >> be able to run online check for the transport interface - it won't have >> any routes to anything other than local subnet and the VPN server. > >Indeed, VPN can be pretty tricky. This needs a lot of testing. > >@Slava: I highly appreciate your feedback! I haven't used connman with VPN, unfortunately for this is not a use case in our application. So I believe there are a lot of other projects out there that have similar setups to ours - simple in nework topology, but needing a network manager trying its best to keep you connected. Those would really only benefit from the proposed change. Best, Aleksandar Aleksandar Mitev (3): Added timeout to socket connections Added logic to perform perpetual online checks Defined a compile time config of perpetual online check README | 10 ++++++ configure.ac | 6 ++++ gweb/gweb.c | 32 +++++++++++++++++++ src/service.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++--- 4 files changed, 131 insertions(+), 4 deletions(-) -- 2.17.1

1 year, 3 months

2
6
0 / 0

[PATCH] agent: Always set driver for queued message.

by Jussi Laakkonen

This addresses the issue of not being able to cancel agent queries in case the query timeouts or when component (e.g., a VPN plugin) has requested something via agent and the component dies when the query is still active. As a result the queries are stacked on top of another if the agent creates new one for every query. It is imperative to always set the driver for the message to be queued via agent.c because otherwise sending cancel request will fail. This is because the cancel request would be sent to a NULL interface as driver is omitted. In this case, following is logged: connman-vpnd[4835]: src/agent.c:send_cancel_request() send cancel req to :1.2951 /org/agent/path/vpnagent iface (null) dbus-daemon[1553]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.3387" (uid=0 pid=4835 comm="/usr/sbin/connman-vpnd -d -n") interface="(unset)" member="Cancel" error name="(unset)" requested_reply="0" destination=":1.2951" (uid=100000 pid=27084 comm="/usr/bin/agent") --- src/agent.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/agent.c b/src/agent.c index 8f7b19ba..d6113af7 100644 --- a/src/agent.c +++ b/src/agent.c @@ -238,12 +238,12 @@ int connman_agent_queue_message(void *user_context, driver = get_driver(); DBG("driver %p", driver); - if (driver && driver->context_ref) { + if (driver && driver->context_ref) queue_data->user_context = driver->context_ref(user_context); - queue_data->driver = driver; - } else + else queue_data->user_context = user_context; + queue_data->driver = driver; queue_data->msg = dbus_message_ref(msg); queue_data->timeout = timeout; queue_data->callback = callback; -- 2.20.1

1 year, 3 months

2
1
0 / 0

2021

2020

2019

2018

2017

2016

2015

connman September 2019