If I got your point, the main problem you see in this proposal is related to ESS where
potentially very differently performing radios (for instance 1SS 11a and 3SS 11n) would be
merged in the same Service (same SSID), confusing the user expecting to reach 11n
performances while maybe he's actually connected to the slow mule 11a of the ESS: yes
we didn't wanted (and we won't want) to go in the possibility to detail to the
user all the APs with the same SSID so that he can choose, also because afaik there are no
connection managers (windows, android, linux) doing this. We wanted to add what many other
connection managers are doing which is provide 802.11 standards supported of different
SSIDs: this is a choice that the user can make, to connect one SSID instead of another,
without knowing which actual BSSID inside the ESS he will connect to.
Thanks and Regards,
Da: Marcel Holtmann [mailto:email@example.com]
Inviato: lunedì 29 agosto 2016 16:18
A: Blanquicet-Melendez Jose (MM)
Cc: connman(a)lists.01.org; MANIEZZO Marco (MM)
Oggetto: Re: Add speed information to services
>> Nowadays most of the smartphones and laptops (Windows and
Linux) provide the link speed information to the users, either to allow them to choose the
most suitable network to connect to as well as (After having got connected) to show the
current link speed. Unfortunately, this is something not provided by ConnMan yet.
> the link speed or to be more precise the actual data rate is something that is
constantly changing and not really of massive use.
Please look at my last comment.
>> Looking at the information we have inside ConnMan to implement such a feature, we
found that we already have everything to do this. First of all, wpa_supplicant provides
the list of BSS supported rates from which we could know if a BSS supports "b",
"g" or "a", to distinguish between "g" or "a" we
can just check the band for dual-band APs cases.
> You do realize that dual-band (2.4 GHz and 5 GHz) APs are not a single BSS. They are
two BSS. They are actually two radios. One in 2.4 GHz and the other in 5 GHz and a switch
from one to the other is actually roaming. So the use case of detecting dual-band APs is
mood. The two radios might be in the same casing, but it would make no different if they
are two cases standing next to each other. And ConnMan would not be able to tell the
You are right, they are actually two BSS but both using the same SSID, therefore both
will belong to the same network; this is how wpa_supplicant handles this situation and
consequently also ConnMan. As a consequence, a dual-band AP will be seen by ConnMan as a
single network with two BSS, one on 2.4GHz and another on 5GHz; does not matter whether
they are in the same casing or not. Then, the idea would be to combine the capabilities of
both BSS and doing so the network (Service) will show both capabilities, for instance
"a" and "g". Is this what you mean? Or on the contrary what you mean
is that ConnMan will not be able to distinguish to which of the two BSS user wants to
connect to, "a" or "g" for instance. If it is what you mean, you are
right, but in any case this is not a very common case where the idea would be to leave
ConnMan makes the decision based on the strength as it has done so far. We don't want
to complicate the choice of the user by adding the desired band in such a case.
actually this is a common case these day. Even more common is that you have access points
with 4 radios in it. And in corporate setups you are going to see the next AP with the
same SSID is still in range of the others. That is what roaming is. There are a few
steering IE available, but I doubt that you can make any reliable assumptions on what
technologies a ConnMan service has.
As you noted, the ConnMan service is the WiFi network (identified by SSID). This could
well mean you have an old 2.4 GHz AP with only g and another one with n technology at
home. ConnMan will show your network as Service and not just a single AP. The concept of a
single AP is not exposed by ConnMan.
>> After that, the only missing information is to know whether
"n" and "ac" are also supported, to do that we could take advantage of
the IEs provided by the wpa_supplicant, there we just would have to check the presence of
the VHT and HT capabilities.
>> Finally, by combining information from BSSs using the same SSID we would be able
to provide speed information supported by each service: "a", "b",
"g", "n" and "ac".
> The main question is what are you going to do with it. Since the provided information
during scanning are just pure informational. They have nothing to do with the actual data
rate that link operates in. And that can change any time and normally it does. Any
interference can trigger a change in data rate. Unless the kernel is able to inform us
about changes and wpa_supplicant providing them in an asynchronous /event based fashion to
ConnMan, there is no point in exposing them. We can not poll wpa_supplicant for updates.
We agreed with you. In fact, we had already done the same analysis, the actual data rate
computation depends on too many variables (Some of them even continually changing) and
provide a trusty value is not so easy. That is the reason why in the email I only
mentioned IEEE standards "a", "b", "g", "n" and
"ac". I think I used the wrong word from the very beginning, the actual data
rate is not what we were thinking to provide to the user but the supported IEEE standard.
Even that is hard since noted above, ConnMan represents the WiFi network as Service and
not just a single AP. There are no requirements that your WiFi network is might up of the
same IEEE standards. The only real requirement is that all of them support WPA1 at
minimum. Providing false or incomplete information is worse than providing no information
> So I think first of all, link rate changes need to be propagated
from the kernel before we consider adding speed information to ConnMan.
After having clarify what we would like to do, we just would like to add that the scope
of this modification is in the scan/connection phase, where by providing this information
the user can realize what would be the most suitable network he/she should get connected
by comparing the IEEE standards supported by the available networks in range. Instead,
providing the actual data rate after user is already connected is not the scope.
You can do this for a connected Service. However first of all you would have to figure out
a way to expose what AP you are connected to. ConnMan does not give the concept of a
single AP to the user. It connects to a WiFi network.
Now this means to make this smooth, you have to put a lot of basic features into ConnMan
so that this makes sense in the term of WiFi network (which is a ConnMan Service) and its
changing connections to APs based on roaming.
And mind you that this also has to work with FullMAC WiFi cards where roaming is handled
in the firmware. So I would start at the kernel and ensure that all information are send
over cfg80211 to identify the AP and its supported technologies.
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain proprietary,
confidential and/or legally protected information and is intended solely for the use of
the designated addressee(s) above. If you are not the intended recipient be aware that any
downloading, copying, disclosure, distribution or use of the contents of the above
information is strictly prohibited.
If you have received this communication by mistake, please forward the message back to the
sender at the email address above, delete the message from all mailboxes and any other
electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free.
Therefore we do not assure that this message is complete or accurate and we do not accept
liability for any errors or omissions in the contents of this message.