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 (Patrik Flykt)
2. Re: Create statistics file and service folder strictly only
after successful connect (Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Feb 2017 08:55:51 +0200
From: Patrik Flykt <[email protected]>
To: [email protected], [email protected]
Cc: [email protected]
Subject: Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2017-02-20 at 14:14 +0200, Patrik Flykt wrote:
> On Fri, 2017-02-17 at 14:03 +0000, [email protected] wrote:
> > From: Jose Blanquicet <[email protected]>
> >
> > This patch set does not remove any auto-connect/roaming
> > functionality,
> > it aims to avoit keeping service in the list after AP
> > deauthenticate?
> > us and it is not found in the scan.
> >
> > The first three patches revert the patches that add the connectable
> > flag because such implementation prevents ConnMan to remove the
> > service
> > from the services list when it is no longer in range, resulting in
> > a
> > confusion for users because they will continue seeing a service in
> > their
> > list when it is not actually available.
> >
> > Doing so, ConnMan will remove the service as other services and
> > then,
> > once it comes back, wpa_s will notify ConnMan about it through a
> > "BSSAdded" signal which will start auto-connect procedure and state
> > machines would continue correctly. In case wpa_s does not send such
> > signal before notifying we got connected, which should not happen,
> > the
> > last two patches of this set introduce a notification named
> > "network_associated" which should handle this border case. I tested
> > it
> > by simulating ConnMan do not process "BSSAdded" signals and it
> > worked,
> > it means that state machines moved correctly and connection trigger
> > from wpa_s completed successfully.
> >
> > I do not think I could trigger all use cases thus I would
> > appreciate
> > if
> > people could test auto-connect and roaming use cases. Mainly
> > auto-connect when AP is who deauthenticate STA. For instance,
> > Saurav
> > Babu in the scenario he recently mentioned when AP blocks STA's MAC
> > address.
>
> Thanks! Compiled ConnMan with these and the P2P technology patch. So
> far so good, but let me leave this running for a while still...
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?
Cheers,
Patrik
------------------------------
Message: 2
Date: Mon, 27 Feb 2017 09:38:03 +0200
From: Patrik Flykt <[email protected]>
To: Jose Blanquicet <[email protected]>, [email protected]
Subject: Re: Create statistics file and service folder strictly only
after successful connect
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2017-02-24 at 08:12 +0000, Jose Blanquicet wrote:
> Or, maybe better, why ConnMan needs to access the file that early?
> Shouldn't it be done when service goes into CONFIGURATION state or
> READY state for new services? If it does not break any statistics
> feature, I would suggest to completely remove that piece of code from
> service_connect():
>
> -?????????????? if (__connman_stats_service_register(service) == 0) {
> -?????????????????????? __connman_stats_get(service, false,
> -?????????????????????????????????????????????? &service-
> >stats.data);
> -?????????????????????? __connman_stats_get(service, true,
> -?????????????????????????????????????????????? &service-
> >stats_roaming.data);
> -?????????????? }
>
> What do yo think?
ConnMan statistics should count all the bytes sent via that service,
successful or not. Configuration state sounds about right, as then all
the bytes in the messages doing authentication are accounted for as
well. Unfortunately I think ethernet was skipping this state (or then
it was Associating, can't remember right now), but that should be
trivial to fix. We do want to have all bytes counted, as this is
especially important with oFono and cellular.
Unfortunately accounting is a bit broken at the moment. Stopping it
does not properly store the bytes seen and the only way to have ConnMan
account properly is to set up an external application to ask for
statistics. So the main part of the file writing is ok, but the logic
in service.c should be rewritte, it's now about two parts of the stats
code that push each other around. So the interaction should first be
cleared up from a service point of view, add simpler helper functions
capable of starting and stopping stat accounting. It may or may not be
beneficial to have the stats file created/opened and closed separately
from writing statistics values to it.
To fix this one, I'd start by verifying that Configuration is the
proper state to start accounting and all drivers follow this. Stopping
should happen when going back to Idle or Failure. Here the interface
going away triggers the service to stop, so something a bit smarter
needs to be done in order to pick up the last bytes sent. Same thing
happens when ConnMan is terminating, in addition the (idle) timeouts
are (currently) just removed when stopping.
Once that is done and is reliable, we'd need to upgrade to 64 bit stats
values. This is ok to change as the interface is marked experimental...
It would be very nice if you (or someone else) had the time to work on
this. I hacked a bit on this once upon a time, but realized twice that
it needs a bit more time to be solved nicely than I had on both
occasions.
Cheers,
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 26
***************************************
