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. [PATCH v2 2/2] dhcp: Remove dead code (Peter Meerwald-Stadler)
2. [PATCH v2 1/2] ntp: Fix potentially leaked addrinfo memory
(Peter Meerwald-Stadler)
3. R: Add speed information to services (MANIEZZO Marco (MM))
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Aug 2016 13:24:32 +0200
From: Peter Meerwald-Stadler <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: [PATCH v2 2/2] dhcp: Remove dead code
Message-ID: <[email protected]>
if type == G_DHCP_IPV6 then client_id is set and checked to be != NULL
otherwise message_type is set and checked to be != NULL
so message_type and client_id cannot both be NULL
CID 1230769
---
gdhcp/client.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/gdhcp/client.c b/gdhcp/client.c
index fbb40ab..e9e38e7 100644
--- a/gdhcp/client.c
+++ b/gdhcp/client.c
@@ -2351,10 +2351,6 @@ static gboolean listener_event(GIOChannel *channel,
GIOCondition condition,
return TRUE;
}
- if (!message_type && !client_id)
- /* No message type / client id option, ignore package */
- return TRUE;
-
debug(dhcp_client, "received DHCP packet xid 0x%04x "
"(current state %d)", ntohl(xid), dhcp_client->state);
--
2.7.4
------------------------------
Message: 2
Date: Tue, 30 Aug 2016 13:24:31 +0200
From: Peter Meerwald-Stadler <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: [PATCH v2 1/2] ntp: Fix potentially leaked addrinfo memory
Message-ID: <[email protected]>
getaddrinfo() allocates a linked list of addrinfo structures;
in case family != AF_NET and != AF_INET6, the list is not feeded
freeaddrinfo() can be moved before the if-statement so that
the list is always freed
CID 1352476
---
src/ntp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ntp.c b/src/ntp.c
index 9b1bb4f..3da1018 100644
--- a/src/ntp.c
+++ b/src/ntp.c
@@ -486,6 +486,7 @@ static void start_ntp(char *server)
family = info->ai_family;
memcpy(×erver_addr, info->ai_addr, info->ai_addrlen);
+ freeaddrinfo(info);
memset(&in6addr, 0, sizeof(in6addr));
if (family == AF_INET) {
@@ -503,7 +504,6 @@ static void start_ntp(char *server)
connman_error("Family is neither ipv4 nor ipv6");
return;
}
- freeaddrinfo(info);
DBG("server %s family %d", server, family);
--
2.7.4
------------------------------
Message: 3
Date: Tue, 30 Aug 2016 12:06:46 +0000
From: "MANIEZZO Marco (MM)" <[email protected]>
To: Marcel Holtmann <[email protected]>, "Blanquicet-Melendez Jose
(MM)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: R: Add speed information to services
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello Marcel,
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,
Marco
-----Messaggio originale-----
Da: Marcel Holtmann [mailto:[email protected]]
Inviato: luned? 29 agosto 2016 16:18
A: Blanquicet-Melendez Jose (MM)
Cc: [email protected]; MANIEZZO Marco (MM)
Oggetto: Re: Add speed information to services
Hi Jose,
>>> 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 difference.
>
> 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 at ll.
>> 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.
Regards
Marcel
________________________________
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.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 10, Issue 43
***************************************
