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 0/5] Avoid to keep service in list if AP is not
found during scan (Jose Blanquicet)
2. Re: Create statistics file and service folder strictly only
after successful connect (Jose Blanquicet)
3. Re: (Jose Blanquicet)
----------------------------------------------------------------------
Message: 1
Date: Wed, 1 Mar 2017 14:51:03 +0000
From: Jose Blanquicet <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan
Message-ID:
<CAFC8iJL7u1soCggq2P=j51xf5v6ahqgby3nef2xdngkr7xf...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Patrik,
On Mon, Feb 27, 2017 at 6:55 AM, Patrik Flykt
<[email protected]> wrote:
> Seems to work much better for the connected case. I used to see
> disconnects followed by reconnects quite a few times a day, they are
> now gone - or then the WiFi network got fixed this year, but is of a
> much lesser probability than ConnMan gettign fixed.
>
> That said, waking up from suspend makes wpa_supplicant disconnect every
> connection attempt after resuming with:
>
> connmand[6925]: plugins/wifi.c:disconnect_callback() result -5 supplicant
> interface 0x557a82af5bd0 wifi 0x557a82aeb840
>
> This goes away if wpa_supplicant is restarted. Some other "feature" of
> wpa_supplicant got exposed as a result?
Sorry for the delay to reply, I was out-of-office. This is my
analysis, I hope I correctly got what you mean.
Well, we do not allow to suspend our devices thus we have never tried
it before and this is indeed another case of reconnection after a
disconnection notified from wpa_s. However, this does not trigger this
path set because AP does not actually "disappear".
In any case, I tried to reproduce your problem and I found that when
the system is suspended, I immediately can see on the AP the
disconnection of such STA. Then, on the STA side, right after wpa_s
wakes up from "System suspend notification", it receives the
deauthenticate event. At this point, wpa_suuplicant is aware of the
actual link state and it correctly notifies disconnection to ConnMan
which starts auto-connect procedure. Now, ConnMan is ready for the
incoming reconnection and the full-chain get updated successfully in
my system.
Therefore, I could not reproduce your problem, I am not sure how
ConnMan fell on disconnect_callback() in this use case. Looking
briefly at the code, you could only fall there if is ConnMan itself
who asks for disconnection and this should not be the case. I have a
question, is this a regression after this patch set or is this
something that already happens in the past?
In addition, as you know, that -5 in your log is the mapping ConnMan
does to wpa_s errors, I think ConnMan should at least print the actual
wpa_s error in order to find it into the logs later for the analysis.
For instance, that would be very useful in cases like this, do you
agree?
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 36c4dd5..0862e45 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -4987,7 +4987,9 @@ static void interface_disconnect_result(const char *error,
SUPPLICANT_DBG("");
if (error) {
+ SUPPLICANT_DBG("error %s");
result = -EIO;
+
if (g_strcmp0("org.freedesktop.DBus.Error.UnknownMethod",
error) == 0)
result = -ECONNABORTED;
Regards,
Jose Blanquicet
------------------------------
Message: 2
Date: Wed, 1 Mar 2017 15:41:54 +0000
From: Jose Blanquicet <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: Daniel Wagner <[email protected]>, [email protected], "MANIEZZO
Marco (MM)" <[email protected]>
Subject: Re: Create statistics file and service folder strictly only
after successful connect
Message-ID:
<cafc8ijli9uz_r1gy9xwbse87zb_qbs0zkcemrx0b3o3os8w...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
On Tue, Feb 28, 2017 at 10:24 AM, Patrik Flykt
<[email protected]> wrote:
> On Tue, 2017-02-28 at 07:38 +0100, Daniel Wagner wrote:
>> Depends on how you see it :) It works exactly as we initially
>> planned it. That is without an external user of the stats API the
>> counters are not updated to keep overhead/power usage at a minimum.
>>
>> Always updating the counters makes perfectly sense for me though you
>> need to take a close look on how to keep the overhead small.
>
> The only problem right now is that stats are not recorded to file on
> service disconnect. It has to do with the fact that the interface is
> the first one to go, then the service is removed. Stats are
> closed/saved only when service goes away, which is too late.
We noticed the issue because we saw too many folders
/var/lib/connman/wifi_* after a test session with only the statistics
file inside. I thought it could be easily resolved but, as always, all
my tests are done only for WiFi technology and sometime I miss
something.
I apologize but I have to let this for another moment or maybe for
someone with more time because I need to pass to other issues with
higher priority.
Thanks for the support!
Regards,
Jose Blanquicet
------------------------------
Message: 3
Date: Wed, 1 Mar 2017 16:52:03 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Antoine Aubert <[email protected]>, [email protected]
Subject: Re:
Message-ID:
<CAFC8iJJvSWMEMb9mbVjxbVvmH4MLAQFcUiS-+=-bb6_2mzh...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Daniel,
On Tue, Feb 28, 2017 at 6:47 AM, Daniel Wagner <[email protected]> wrote:
> I pestered Marcel for a release a bit during ELC last week. He agreed to do
> one. A soon it is done patches will will get applied again. Sorry for the
> inconvenience.
No problem. Thanks for tell us.
Regards,
Jose Blanquicet
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 17, Issue 1
**************************************
