May 2021 - connman - Ml01.01.Org

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, 4 months

3
7
0 / 0

Re: IoT WiFi scan for connman SSID selection and configuration remotely

by Daniel Wagner

On Mon, May 24, 2021 at 07:59:26AM +0000, VAUTRIN Emmanuel (Canal Plus Prestataire) wrote: > By my side, I am using wpa-supplicant that is well implemented. > There is a recent opened discussion on scanning still not implemented > with iwd, it may be your problem. Nope, scanning _is_ implemented since day 0 of the iwd plugin.

1 year, 4 months

2
1
0 / 0

Re: IoT WiFi scan for connman SSID selection and configuration remotely

by Jupiter

Hi Emmanuel, That seems what I was missing, running Scan prior to running GetService did the trick, it looks more reliable. Thank you very much, greatly appreciate it. Kind regard, - jupiter On 5/24/21, VAUTRIN Emmanuel (Canal Plus Prestataire) <Emmanuel.VAUTRIN(a)cpexterne.org> wrote: >> Thanks for your response and advice, I did try to use the same command >> script dbus-send net.connman.Manager.GetServices, but I had to abandon >> it due to unreliable responses, my device has 2 interfaces of 4G LTE >> and WiFi, I could reliably get 4G LTE entry all the time, but I could >> only get a list of WiFi SSIDs sometime, not sure if it is normal >> behavior or what I could be missing? >> >> I ran your dbus-send net.connman.Technology.Scan command, didn't seem >> useful response: > Hi Jupiter, > > In fact, the Scan command will perform the scan, so you need to launch it > first (you will probably notice a delay corresponding to the scan) and then > you can get an up-to-date service list. > > By my side, I am using wpa-supplicant that is well implemented. > There is a recent opened discussion on scanning still not implemented > with iwd, it may be your problem. > > > B.R. > > Emmanuel

1 year, 4 months

2
1
0 / 0

Re: IoT WiFi scan for connman SSID selection and configuration remotely

by Jupiter

Hi Emmanuel, Thanks for your response and advice, I did try to use the same command script dbus-send net.connman.Manager.GetServices, but I had to abandon it due to unreliable responses, my device has 2 interfaces of 4G LTE and WiFi, I could reliably get 4G LTE entry all the time, but I could only get a list of WiFi SSIDs sometime, not sure if it is normal behavior or what I could be missing? I ran your dbus-send net.connman.Technology.Scan command, didn't seem useful response: $ dbus-send --system --print-reply --dest=net.connman /net/connman/technology/wifi net.connman.Technology.Scan method return time=1621820527.013800 sender=:1.4 -> destination=:1.22 serial=120 reply_serial=2 Thank you very much. Kind regards, jupiter On 5/21/21, VAUTRIN Emmanuel (Canal Plus Prestataire) <Emmanuel.VAUTRIN(a)cpexterne.org> wrote: > Hi Jupiter, > >> For users to select a proper SSID to configure connman WiFi, the >> device needs to scan WiFi SSIDs, we don't have Python in our device's >> small footprint, we cannot run connmanctl. >> >> Are there any methods in connman to run WiFi scan? What alternative >> open source (in C or C++) are you using for scanning WiFi SSID to find >> your WiFi SSID name to configuring connman WiFi remotely? > > I am not pretty sure having understood your need, but > there is the dbus interface to both performing a scan and retrieving the > service list. > > If you want to test by inline commands, you can use dbus-send > dbus-send --system --print-reply --dest=net.connman > /net/connman/technology/wifi net.connman.Technology.Scan > dbus-send --system --print-reply --dest=net.connman / > net.connman.Manager.GetServices > or gdbus call > gdbus call --system -d net.connman -o /net/connman/technology/wifi -m > net.connman.Technology.Scan > gdbus call --system -d net.connman -o / -m net.connman.Manager.GetServices > > After that, you will need to integrate these 2 interfaces from ConnMan dbus > API. > Hoping it will solve your problem, > > Emmanuel >

1 year, 4 months

2
1
0 / 0

IoT WiFi scan for connman SSID selection and configuration remotely

by Jupiter

Hi, For users to select a proper SSID to configure connman WiFi, the device needs to scan WiFi SSIDs, we don't have Python in our device's small footprint, we cannot run connmanctl. Are there any methods in connman to run WiFi scan? What alternative open source (in C or C++) are you using for scanning WiFi SSID to find your WiFi SSID name to configuring connman WiFi remotely? Thank you. Kind regards, - jupiter

1 year, 4 months

2
1
0 / 0

Re: How to configure an IoT wifi setup

by Denis Kenzior

Hi Diego, >>> In theory 2 can be done today, either by iwd or combo iwd/hostapd with >> some >>> manual magic. > > We do exactly this on our devices, when we explored things a while back it was not really an option to do it all with iwd, so we use iwd for the client part, create a new interface on the same WiFi adapter and fire up a hostapd + dnsmasq combo on it as a "configuration AP", if the device is not configured yet. The advantage is that iwd works in parallel in client mode so we can get the list of available networks and test that the configuration provided by the user really works without having to disconnect the user from the "configuration AP" until configuration is complete. Awesome, thanks for confirming that this can be done. In theory iwd should be getting to the point where our AP mode support should be good enough for simple scenarios like this one. > > Creating a second interface in AP mode works on all the WiFi adapters we have encountered, which are mainly Intel and Qualcomm. > Keith, Any P2P capable adapter should be able to do this (so pretty much any modern hardware). There was an earlier discussion on the list where I suggested that we add a config option to main.conf to start iwd either in station + p2p or station + ap mode. Patches are always welcome! Regards, -Denis

1 year, 4 months

1
0
0 / 0

Re: How to configure an IoT wifi setup

by Denis Kenzior

Hi Keith, On 5/19/21 2:36 PM, KeithG wrote: > Group, > > I am not sure if this is the right terminology but this is what I am > trying to do: > Power up a headless device. If it does not get an ethernet or wifi > connection, it launches AP mode of some sort and allows a device to > connect then configure the wifi connection by selecting an AP and > typing in a password. > > This works with hostapd/dsnmasq, currently. I want to switch over to > connman and/or iwd to do this, but have not been successful in doing > this. So do you know how this works, exactly? > > If I set up connman by: > "# connmanctl tether wifi on SSID password" I can connect and 'see' my > new SSID, but I cannot scan for any APs to set up. I do not know how > to set the SSID IP address, if this has been enabled in connman. Daniel or Marcel can correct me if I'm wrong, but I don't think this is a usecase connman supports. Tethering is just that, sharing your ethernet/wwan/whatever connection over wifi. > > I have tried with iwctl as well: > set up /etc/iwd/main.conf > [General] > EnableNetworkConfiguration=true > APRanges=192.168.1.0/24 > > # iwctl device wlan0 set-property Mode ap > # iwctl ap wlan0 start SSID password > > With this I can connect, but once again, I cannot scan for any > available SSIDs to connect to. It is not important that I be able to > connect, but I do need to see the SSIDs so the user can set it up then > reboot (or restart connman/iwd) to connect to the new 'known' SSID. So I think there are two ways of doing this: 1. Being able to scan while in AP mode. This is something that has been brought up before as desirable, etc. But no one has made any contributions just yet. All this does is lets you see the surrounding SSIDs... 2. Use multiple interfaces if your hw supports them. So 1 interface in AP mode, the other in station mode. Then you could connect to the headless device on the ap interface and run iwd on the station interface as usual to set up the network. In theory 2 can be done today, either by iwd or combo iwd/hostapd with some manual magic. Regards, -Denis

1 year, 4 months

3
2
0 / 0

Re: [RFC connman 1/1] WIP: Add WPA3-SAE support

by Marcel Holtmann

Hi Ariel, >>>> I am not really into the WiFi topic anymore, so I am adding the iwd >>>> mailing list. Maybe we get some input for the new SAE Security >>>> property, e.g. how this could work with iwd. >>> >>> don’t change the Service API. Even WPA3 Personal is just PSK and so there is >>> no need to add another security property entry. >> >> I somehow expected PSK also covers WPA3. This means any code for >> enabling WPA3 for wpa_supplicant should go solely into plugins/wifi.c. >> Thanks for clarifying this point. > > Thanks for discussing the implementations details. > > So AFAIU from the above, the patchset is implementing wpa_supplicant > WPA3-SAE support in the right place: wifi plugin. Any change required? I > understand that documentation should be updated probably, anything else? if you need to update the Service API documentation, then you are doing something wrong. >>> Actually if you are using iwd, then the detail between WPA2 and WPA3 >>> is never exposed to ConnMan. >> >> Nice! I didn't know that iwd already supports WPA3. > > I'm planning to extend the support to iwd in a follow-up patchset. I'd > like to get this approved/merged first. No idea what would be needed for iwd support. It already does support WPA3. With iwd, no changes to ConnMan are needed for WPA3 support. Regards Marcel

1 year, 4 months

2
1
1 / 0

[PATCH] service: Fix preferred service reordering on ready state

by VAUTRIN Emmanuel (Canal Plus Prestataire)

When a service reaches the ready state, the service list shall always be reordered according to the PreferredTechnologies config options. This issue can be reproduced with PreferredTechnologies=ethernet,wifi, by following the steps below: 1. Starting, Ethernet (E) plugged, with a known Wifi (W) network. E idle -> online, W idle -> ready 2. Unplug Ethernet. E online -> idle, W ready -> online 3. Plug Ethernet. E idle -> ready, W online Even if Ethernet has the highest priority, it will never be online, except if Wifi connection is lost. Fixes: e600366f6035 ("service: Start online check on IP address update") --- src/service.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/src/service.c b/src/service.c index 20917a8923a4..cadd9fc76881 100644 --- a/src/service.c +++ b/src/service.c @@ -4711,15 +4711,11 @@ static void apply_relevant_default_downgrade(struct connman_service *service) struct connman_service *def_service; def_service = connman_service_get_default(); - if (!def_service) + if (!def_service || def_service != service || + def_service->state != CONNMAN_SERVICE_STATE_ONLINE) return; - if (def_service == service && - def_service->state == CONNMAN_SERVICE_STATE_ONLINE) { - def_service->state = CONNMAN_SERVICE_STATE_READY; - __connman_notifier_leave_online(def_service->type); - state_changed(def_service); - } + downgrade_state(def_service); } static void switch_default_service(struct connman_service *default_service, @@ -5898,8 +5894,7 @@ static int service_update_preferred_order(struct connman_service *default_servic unsigned int *tech_array; int i; - if (!default_service || default_service == new_service || - default_service->state != new_state) + if (!default_service || default_service == new_service) return 0; tech_array = connman_setting_get_uint_list("PreferredTechnologies"); @@ -6051,12 +6046,12 @@ static int service_indicate_state(struct connman_service *service) service->new_service = false; - default_changed(); - def_service = connman_service_get_default(); service_update_preferred_order(def_service, service, new_state); + default_changed(); + __connman_service_set_favorite(service, true); reply_pending(service, 0); -- 2.25.1

1 year, 4 months

1
0
0 / 0

Re: [PATCH 0/1] start online check even if service is not the default service

by Christophe Ronco

Hi, >> Yes this is a big problem for me. If WiFi service stays online and >> Ethernet service stays ready, the default route is on WiFi so all >> traffic goes through WiFi instead of wired. This is bad and not what end >> user wants when he wrote "PreferredTechnologies = ethernet, wifi, >> cellular" in main.conf. WiFi is a backup and must not be used if >> Ethernet is OK. Looking at comments in main.conf I see current behavior >> (using WiFi service for default route when Ethernet service is working) >> as a bug. > Your concern makes totally sense. > >> I don't think that reproducing my problem is difficult, can you tell me >> if you see the same behavior ? If not, could you send your debug logs, >> I'll try to understand what I did wrong. > I confirm it to be completely reproducible. > Moreover, I think that our validation team has noticed that after > the update from 1.37 to1.38. > It is not my priority, but will try to check it the next weeks. Happy to see this is seen as a real problem. My previous patch is not enough to fix this problem. Even with the patch if you do: 1) start with Ethernet cable plugged => Wired service Online, WiFi service not ready 2) unplug Ethernet cable => Wired service does not exist, WiFi service goes online 3) replug Ethernet cable => Wired service Online, WiFi service Ready 4) unplug Ethernet cable => Wired service does not exist, WiFi service stays Ready So I have done something to call __connman_service_wispr_start each time a service is ready. It fixes my problem but the online check is sometimes done twice. Maybe this is OK, maybe this is not the right way to do it, I don't know. __connman_service_wispr_start is called twice when replugging the Ethernet cable (step 2 and 4). It is called once when wired service becomes ready (because of my patch) and another time from default_changed when default service changes from WiFi to new Wired (online) service. This comes from patch 69e9e25032946887aede3ebb6233739e7ceb2d49 done before 1.39. I am a bit lost on when this online check should be started. Each time a service becomes ready seems good to me but I am not sure at all. If anybody has clearer ideas on this subject, I'll be happy to make or test a better patch. Christopĥe

1 year, 4 months

3
2
0 / 0

2022

2021

2020

2019

2018

2017

2016

2015

connman May 2021