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: Disabling the network on Disconnect Notification
(Naveen Singh)
2. Re: Disabling the network on Disconnect Notification
(Naveen Singh)
3. RE: tether question (Zheng, Wu)
4. [PATCH] config: Fix memory leak when realloc fails
(Nishant Chaprana)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Feb 2016 16:47:17 -0800
From: Naveen Singh <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: Disabling the network on Disconnect Notification
Message-ID:
<cagtdzkmep0hapm-hft8qum-wrcfic4hj+rjnftic5rngrhq...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Feb 22, 2016 at 12:18 AM, Patrik Flykt
<[email protected]> wrote:
>
> Hi,
>
> On Fri, 2016-02-19 at 22:50 -0800, Naveen Singh wrote:
>> On Thu, Feb 18, 2016 at 11:20 PM, Patrik Flykt
>> <[email protected]> wrote:
>> >
>> > Hi,
>> >
>> > On Thu, 2016-02-18 at 22:52 -0800, Naveen Singh wrote:
>> >> Hi All
>> >> On the disconnect notification from wpa_supplicant (when the interface
>> >> state becomes G_SUPPLICANT_STATE_DISCONNECTED), connman disables the
>> >> network (SSID). This is done from interface_state function in
>> >> plugins/wifi.c:
>> >>
>> >> if
>> >> (g_supplicant_interface_enable_selected_network(interface,
>> >> FALSE) != 0)
>> >> DBG("Could not disable selected network");
>> >>
>> >> This severely impacts wpa_supplicant's attempt of getting device
>> >> connected back to WiFi. Lot of enterprise AP now have band steering
>> >> and/or load balancing enabled as a result of which they keep sending
>> >> deauth frames to client till it picks the correct BSSID for
>> >> connection. Now if wpa_supplicant is left alone, it would properly
>> >> converge to the right BSSID where the association would stick (by
>> >> blacklisting a BSSID if it does not allow or deny the connection and
>> >> trying the next one)
>> >>
>> >> But now with the very first disconnect notification, connman disables
>> >> the whole network which ends up disabling the whole SSID and
>> >> wpa_supplicant does not continue with its connection attempts.
>> >> Next time when this SSID gets enabled from connman (as a part of next
>> >> connect), the same story repeats. End result device sometimes never
>> >> get connected. The above piece of code is impacting L2 level roaming
>> >> decisions in connman. And I do not think connman has any intention or
>> >> desire to interfere in any BSSID level roaming decision of
>> >> wpa_supplicant.
>> >>
>> >> Even for the AP which sends deauth with reason code 6/7/4,
>> >> wpa_supplicant has internal logic to get device connected fast. This
>> >> also gets impacted quite a bit because of disable logic.
>> >>
>> >> Even logs look very confusing at the time of disconnection. You see a
>> >> successful association (because of wpa_s connection attempt) followed
>> >> by an internally generated disconnect.
>> >>
>> >> I did a test by removing this code and following are the events that
>> >> happened on receiving deauth:
>> >>
>> >> 1) Client receives deauth frame (reason code 15)
>> >> 2) wpa_supplicant blacklists the current AP and schedule a scan.
>> >> 3) It generates disconnect notification to connman
>> >
>> > At this point a properly designed API would not tell that the network
>> > disconnected, as it obviously is looking for another AP to connect to.
>> > wpa_supplicant does not have the worlds greatest API design in place as
>> > we've seen with other patches in the recent past...
>> >
>> I had a discussion with Jouni on this and he agreed in principle that
>> we need two API. Once when the initial connection is lost and second
>> when wpa_supplicant has tried connecting with all the known BSSID. But
>> the problem is that wpa_supplicant will never stop try connecting it.
>> If all the known BSSID are blacklisted and still device cannot get
>> connected, wpa_s will clear the blacklist and try again. So there is
>> no way we can say when to generate the second event.
>
>
> This is fixed by having wpa_supplicant getting its act together and
> informing any client of a disconnected network once the list of known
> BSSIDs has been tried once. No earlier and no later. The client, in this
> case ConnMan, is not supposed to know more of the network details than
> wpa_supplicant.
>
>> One of the proposal that came out from that discussion was to not
>> immediately handle the disconnect notification from wpa_s. Delay it by
>> say 20 sec, and if the connected event happens before the timer expiry
>> cancel the timer and do nothing but if nothing happens for 20 sec,
>> make the state disconnected. But in my view it is not correct to do
>> first because for that 20 sec data path is still ON (as application is
>> not notified) even if there is no L2 level connection. Also I am not
>> sure what should be the proper value for timeout.
>
> This is a solution that won't work. It leaves ConnMan without WiFi
> connectivity for 20s after going out of range or loosing the connection
> otherwise. So one has to wait 20s for a reconnection when going out of
> range from one's home WiFi? Why was this even proposed in the first
> place...
>
>> >> 4) Connman released its current IP.
>> >> 5) wpa_supplicant gets the scan result and finds all the AP
>> >> advertising the same SSID.
>> >> 6) It proceeds with the connection with next BSSID.
>> >> 7) It connects back with this BSSID
>> >> 8) Connman gets device the IP address
>> >>
>> >> If deauth is received with reason code 6 or 7 or 4 then there is even
>> >> no scan and device gets connected real fast.
>> >>
>> >> Let me know your thoughts on this. I will send my patch soon
>> >
>> > ConnMan can implement the workaround not to drop the connection when it
>> > is obvious that wpa_supplicant will be looking for another AP to connect
>> > to. Then again we don't want ConnMan to be stuck with connecting
>> > forever, either.
>>
>> I think the only change my patch would do is to not disable the
>> network. Everything still would be handled the same way. As far as
>> connman is concerned the state is disconnected and it has even
>> released the IP address.
>
> In addition the service is disconnected.
>
>> On the next connection connman immediately
>> proceeds with DHCP REQ (asking for same IP). And I think
>> conservatively speaking it is probably a good thing to get a new IP
>> address than sitting on the old IP address (Some user may have two AP
>> in their house broadcasting same SSID but both of them are acting as a
>> DHCP server).
>
> At this point ConnMan has already selected another service, if
> available, so there is no guarantees that the same WiFi will be
> reconnected.
>
> The only thing that might work here is that one or more of the reason
> codes 6, 7 or 4 will not be sent in any other circumstances than doing
> this unnecessary disconnect notification from wpa_supplicant and is an
> indication that the notification can be ignored. Probably it does not
> work out that nicely.
>
> Cheers,
>
> Patrik
>
>
Hi Patrik
Thanks for your inputs. What i see is that with disconnect
notification from wpa_supplicant connman ends up issuing a connect to
the wpa_supplicant. This is an internally generated connect. This
happens because auto_connect is invoked from the service state machine
when the service state is disconnected.
This connect always is for the same service (even though I have two
service configured as favorite) I always see that this connect request
is issued for the same service. Do you think it makes sense to honor
this connect request only in the case wpa_supplicant is not trying to
get device connected. If the supplicant state is CONNECTED or
ASSOCIATING then we should not honor this request and probably drop
this additional connect request. Let me know your thought on this.
Regards
Naveen
------------------------------
Message: 2
Date: Wed, 24 Feb 2016 16:49:30 -0800
From: Naveen Singh <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: Disabling the network on Disconnect Notification
Message-ID:
<CAGTDzKn4ba06xypkX+98j92SGY2Ko5pJFmcu=nh+gkp8lvp...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Feb 24, 2016 at 4:47 PM, Naveen Singh <[email protected]> wrote:
> On Mon, Feb 22, 2016 at 12:18 AM, Patrik Flykt
> <[email protected]> wrote:
>>
>> Hi,
>>
>> On Fri, 2016-02-19 at 22:50 -0800, Naveen Singh wrote:
>>> On Thu, Feb 18, 2016 at 11:20 PM, Patrik Flykt
>>> <[email protected]> wrote:
>>> >
>>> > Hi,
>>> >
>>> > On Thu, 2016-02-18 at 22:52 -0800, Naveen Singh wrote:
>>> >> Hi All
>>> >> On the disconnect notification from wpa_supplicant (when the interface
>>> >> state becomes G_SUPPLICANT_STATE_DISCONNECTED), connman disables the
>>> >> network (SSID). This is done from interface_state function in
>>> >> plugins/wifi.c:
>>> >>
>>> >> if
>>> >> (g_supplicant_interface_enable_selected_network(interface,
>>> >> FALSE) != 0)
>>> >> DBG("Could not disable selected network");
>>> >>
>>> >> This severely impacts wpa_supplicant's attempt of getting device
>>> >> connected back to WiFi. Lot of enterprise AP now have band steering
>>> >> and/or load balancing enabled as a result of which they keep sending
>>> >> deauth frames to client till it picks the correct BSSID for
>>> >> connection. Now if wpa_supplicant is left alone, it would properly
>>> >> converge to the right BSSID where the association would stick (by
>>> >> blacklisting a BSSID if it does not allow or deny the connection and
>>> >> trying the next one)
>>> >>
>>> >> But now with the very first disconnect notification, connman disables
>>> >> the whole network which ends up disabling the whole SSID and
>>> >> wpa_supplicant does not continue with its connection attempts.
>>> >> Next time when this SSID gets enabled from connman (as a part of next
>>> >> connect), the same story repeats. End result device sometimes never
>>> >> get connected. The above piece of code is impacting L2 level roaming
>>> >> decisions in connman. And I do not think connman has any intention or
>>> >> desire to interfere in any BSSID level roaming decision of
>>> >> wpa_supplicant.
>>> >>
>>> >> Even for the AP which sends deauth with reason code 6/7/4,
>>> >> wpa_supplicant has internal logic to get device connected fast. This
>>> >> also gets impacted quite a bit because of disable logic.
>>> >>
>>> >> Even logs look very confusing at the time of disconnection. You see a
>>> >> successful association (because of wpa_s connection attempt) followed
>>> >> by an internally generated disconnect.
>>> >>
>>> >> I did a test by removing this code and following are the events that
>>> >> happened on receiving deauth:
>>> >>
>>> >> 1) Client receives deauth frame (reason code 15)
>>> >> 2) wpa_supplicant blacklists the current AP and schedule a scan.
>>> >> 3) It generates disconnect notification to connman
>>> >
>>> > At this point a properly designed API would not tell that the network
>>> > disconnected, as it obviously is looking for another AP to connect to.
>>> > wpa_supplicant does not have the worlds greatest API design in place as
>>> > we've seen with other patches in the recent past...
>>> >
>>> I had a discussion with Jouni on this and he agreed in principle that
>>> we need two API. Once when the initial connection is lost and second
>>> when wpa_supplicant has tried connecting with all the known BSSID. But
>>> the problem is that wpa_supplicant will never stop try connecting it.
>>> If all the known BSSID are blacklisted and still device cannot get
>>> connected, wpa_s will clear the blacklist and try again. So there is
>>> no way we can say when to generate the second event.
>>
>>
>> This is fixed by having wpa_supplicant getting its act together and
>> informing any client of a disconnected network once the list of known
>> BSSIDs has been tried once. No earlier and no later. The client, in this
>> case ConnMan, is not supposed to know more of the network details than
>> wpa_supplicant.
>>
>>> One of the proposal that came out from that discussion was to not
>>> immediately handle the disconnect notification from wpa_s. Delay it by
>>> say 20 sec, and if the connected event happens before the timer expiry
>>> cancel the timer and do nothing but if nothing happens for 20 sec,
>>> make the state disconnected. But in my view it is not correct to do
>>> first because for that 20 sec data path is still ON (as application is
>>> not notified) even if there is no L2 level connection. Also I am not
>>> sure what should be the proper value for timeout.
>>
>> This is a solution that won't work. It leaves ConnMan without WiFi
>> connectivity for 20s after going out of range or loosing the connection
>> otherwise. So one has to wait 20s for a reconnection when going out of
>> range from one's home WiFi? Why was this even proposed in the first
>> place...
>>
>>> >> 4) Connman released its current IP.
>>> >> 5) wpa_supplicant gets the scan result and finds all the AP
>>> >> advertising the same SSID.
>>> >> 6) It proceeds with the connection with next BSSID.
>>> >> 7) It connects back with this BSSID
>>> >> 8) Connman gets device the IP address
>>> >>
>>> >> If deauth is received with reason code 6 or 7 or 4 then there is even
>>> >> no scan and device gets connected real fast.
>>> >>
>>> >> Let me know your thoughts on this. I will send my patch soon
>>> >
>>> > ConnMan can implement the workaround not to drop the connection when it
>>> > is obvious that wpa_supplicant will be looking for another AP to connect
>>> > to. Then again we don't want ConnMan to be stuck with connecting
>>> > forever, either.
>>>
>>> I think the only change my patch would do is to not disable the
>>> network. Everything still would be handled the same way. As far as
>>> connman is concerned the state is disconnected and it has even
>>> released the IP address.
>>
>> In addition the service is disconnected.
>>
>>> On the next connection connman immediately
>>> proceeds with DHCP REQ (asking for same IP). And I think
>>> conservatively speaking it is probably a good thing to get a new IP
>>> address than sitting on the old IP address (Some user may have two AP
>>> in their house broadcasting same SSID but both of them are acting as a
>>> DHCP server).
>>
>> At this point ConnMan has already selected another service, if
>> available, so there is no guarantees that the same WiFi will be
>> reconnected.
>>
>> The only thing that might work here is that one or more of the reason
>> codes 6, 7 or 4 will not be sent in any other circumstances than doing
>> this unnecessary disconnect notification from wpa_supplicant and is an
>> indication that the notification can be ignored. Probably it does not
>> work out that nicely.
>>
>> Cheers,
>>
>> Patrik
>>
>>
>
> Hi Patrik
> Thanks for your inputs. What i see is that with disconnect
> notification from wpa_supplicant connman ends up issuing a connect to
> the wpa_supplicant. This is an internally generated connect. This
> happens because auto_connect is invoked from the service state machine
> when the service state is disconnected.
>
> This connect always is for the same service (even though I have two
> service configured as favorite) I always see that this connect request
> is issued for the same service. Do you think it makes sense to honor
> this connect request only in the case wpa_supplicant is not trying to
> get device connected. If the supplicant state is CONNECTED or
> ASSOCIATING then we should not honor this request and probably drop
> this additional connect request. Let me know your thought on this.
>
> Regards
> Naveen
This:
I always see that this connect request is issued for the same service.
should be read as:
I always see that this connect request is issued for the previously
connected service.
Regards
Naveen
------------------------------
Message: 3
Date: Thu, 25 Feb 2016 01:53:06 +0000
From: "Zheng, Wu" <[email protected]>
To: Jukka Rissanen <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: tether question
Message-ID:
<2cf57a644018a745b8fe029c7223e16e12f65...@shsmsx104.ccr.corp.intel.com>
Content-Type: text/plain; charset="utf-8"
Hi Jukka Rissanen,
It is what I want.
Thanks.
Best Regards
Zheng Wu
-----Original Message-----
From: Jukka Rissanen [mailto:[email protected]]
Sent: Wednesday, February 24, 2016 4:09 PM
To: Zheng, Wu <[email protected]>
Cc: [email protected]
Subject: Re: tether question
Hi,
On Wed, 2016-02-24 at 05:07 +0000, Zheng, Wu wrote:
> Hi partik,
>
> I am trying to enable tether of connman in kernel-3.10 of edison.
> Meet some issues. Please help, thanks.
>
> I want to make sure if kernel-3.10 support the tethering feature of
> connman or not?
Tethering with edison is a bit tricky because the Broadcom wifi chip used in
edison requires different firmware for AP mode. So when one activates
tethering, someone needs to load another firmware to the chip. This cannot be
connman as it does not know anything about edison.
That is why the activation of tethering needs to be initiated differently in
that device.
I have a script that can toggle the AP mode on/off, see it here
http://git.yoctoproject.org/cgit/cgit.cgi/meta-eca/tree/meta-eca/recipe
s-support/toggle-ap-mode/files/ap-mode-toggle
Because of this there is a program that monitors the power button and toggles
AP mode on/off when you press it. See detail here
http://git.yoctoproject.org/cgit/cgit.cgi/meta-eca/tree/meta-eca/recipe
s-support/pwr-button-handler/files
The issue is not really connman issue so probably this mailing list is not a
proper place to discuss this further.
Cheers,
Jukka
------------------------------
Message: 4
Date: Thu, 25 Feb 2016 12:22:42 +0530
From: Nishant Chaprana <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: [PATCH] config: Fix memory leak when realloc fails
Message-ID: <[email protected]>
This patch fixes realloc failure case, when realloc fails it
returns NULL and previously allocated memory was getting lost in
this scenario, So all memory should be freed before returning.
---
src/config.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/config.c b/src/config.c
index 344b8ce..e3108eb 100644
--- a/src/config.c
+++ b/src/config.c
@@ -1550,13 +1550,16 @@ struct connman_config_entry
**connman_config_get_entries(const char *type)
g_hash_table_iter_init(&iter_file, config_table);
while (g_hash_table_iter_next(&iter_file, &key, &value)) {
struct connman_config *config_file = value;
+ struct connman_config_entry *tmp_entries = entries;
count = g_hash_table_size(config_file->service_table);
entries = g_try_realloc(entries, (i + count + 1) *
sizeof(struct connman_config_entry *));
- if (!entries)
+ if (!entries) {
+ g_free(tmp_entries);
return NULL;
+ }
g_hash_table_iter_init(&iter_config,
config_file->service_table);
@@ -1589,10 +1592,14 @@ struct connman_config_entry
**connman_config_get_entries(const char *type)
}
if (entries) {
+ struct connman_config_entry *tmp_entries = entries;
+
entries = g_try_realloc(entries, (i + 1) *
sizeof(struct connman_config_entry *));
- if (!entries)
+ if (!entries) {
+ g_free(tmp_entries);
return NULL;
+ }
entries[i] = NULL;
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 32
**************************************
