Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH] plugins/wifi: Do not disable network on
Disconnect (Patrik Flykt)
2. Re: Error when using autoconnect (Patrik Flykt)
3. Re: [PATCH] Supporting wifi load balancing and band steering
(Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Mar 2016 13:44:22 +0200
From: Patrik Flykt <[email protected]>
To: Naveen Singh <[email protected]>
Cc: [email protected], Naveen Singh <[email protected]>
Subject: Re: [PATCH] plugins/wifi: Do not disable network on
Disconnect
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2016-03-14 at 15:07 -0700, Naveen Singh wrote:
> Thanks Patrik for the history. So looks like code was disabling
> network in case of disconnect was received while device was in 4 way
> hand shake state. Now by moving the code out from the function we
> pretty much let wpa_supplicant try to connect on its own.
>
> Should not we let wpa_supplicant try to connect on its own
> irrespective of reason code. Once wpa_supplicant is armed with a
> profile (which would have happened as a part of a previous
> AddNetwork), wpa_supplicant would keep trying to connect to that SSID
> for ever. The only time when connman chooses a different SSID is when
> wpa_supplicant should stop scanning and try connecting with the new
> SSID.
>
> Tying this with reason code may lead to issue. Consider following
> scenario when there are multiple AP with same SSID and device is
> connected to one.
>
> 1) Device is connected with BSSID1.
> 2) BSSID1 disappears so disconnect does not happen with any specific
> reason code. Reason code may be 0 in this case.
> 3) So in this case we would end up disabling the network and
> wpa_supplicant will not try to connect on its own.
> 4) The next connect attempt from connman is happening for the same
> SSID connman will not even do AddNetwork as disabling the network is
> not removing the network and hence network path may not be NULL.
>
> I think until and unless there is a bug in wpa_supplicant where it
> stops trying to connect even if it has an active profile connman
> should never disable the network. And when connman decides to connect
> to a different service, remove the previous one, add the new one and
> let wpa_supplicant handle things from there.
ConnMan in general cannot leave wpa_supplicant to connect on its own. As
there are other networking technologies with priority higher than WiFi,
that network may have been connected meanwhile. When that is the case,
wpa_supplicant need to be told it does and not should not do anything
meanwhile. Also, as ConnMan got a list of networks from wpa_supplicant,
ConnMan also wants to try the second and third best networks to connect.
In addition ConnMan breaks connections only when a better other network
technology becomes available, not when another previously seen WiFi
reappears.
So unless the proper set of reason codes cannot be obtained from
wpa_supplicant indicating that the disconnection is due to a lower level
issue that can be ignored, wpa_supplicant should not be left connecting
by its own.
Cheers,
Patrik
------------------------------
Message: 2
Date: Mon, 21 Mar 2016 13:54:44 +0200
From: Patrik Flykt <[email protected]>
To: Francis Leblanc-Lebeau <[email protected]>
Cc: [email protected]
Subject: Re: Error when using autoconnect
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Fri, 2016-03-18 at 13:47 -0400, Francis Leblanc-Lebeau wrote:
> I am using connman 1.31 on a ARM target (yocto build). I can properly
> configure a Wifi connection in connmanctl, but when I try to enable
> auto connect, I get this error:
>
> connmanctl> config wifi --autoconnect yes
connmanctl wants to know which WiFi service to autoconnect, so the line
goes like:
connmanctl config wifi_ac3fa44fd496_4e455447454152205233363030_managed_psk
autoconnect on
Cheers,
Patrik
------------------------------
Message: 3
Date: Mon, 21 Mar 2016 16:49:48 +0200
From: Patrik Flykt <[email protected]>
To: Naveen Singh <[email protected]>
Cc: [email protected], Naveen Singh <[email protected]>
Subject: Re: [PATCH] Supporting wifi load balancing and band steering
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2016-03-14 at 18:49 -0700, Naveen Singh wrote:
> > + if (callbacks_pointer &&
> callbacks_pointer->update_assoc_status_code) {
> > +
> callbacks_pointer->update_assoc_status_code(interface,
> status_code);
> > + }
> > + }
>
>
> Currently the order of wpa_supplicant properties must be such
> that all
> necessary information is available when the callback call is
> made here.
> If (or when) something changes with wpa_supplicant, it is
> safer if the
> attributes are collected first with the calling code reacting
> after
> that. Otherwise some information might not have been collected
> from the
> messages.
>
> Here one should follow the callback_*() convention so that the
> code is
> more uniform overall.
>
> Do you mean instead of update_assoc_status_code and
> update_disconnect_reasoncode make it callback_update_assoc_status_code
> and callback_update_disconnect_reasoncode respectively. I looked into
> the code and I do not see any of this. Am I missing something here?
In other parts of the code functions like
callback_interface_added(GSupplicantInterface *interface) are used that
then check for the interface pointer being non-NULL as well as for the
respective callbacks_pointer member.
The division into gsupplicant and plugins/wifi.c is a bit artificial
sometimes. Yes, gsupplicant is a "communcations" library, while the
(re)action takes place in plugins/wifi.c. It is actually a matter of
debate which one is the correct place, the idea should be that
gsupplicant plasters over the biggest wrinkles wpa_supplicant will
produce making the intention and (re)action clear in plugins/wifi.c.
Whether this particular case deserves handling and where is interesting;
the criteria is basically that the developer goes through a total memory
erase and sees the code anew after that; armed with only the code and
commit messages the implementation split which is then clearer to the
unaided mind is the one we'd want in the code...
Cheers,
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 5, Issue 25
**************************************
