On Sun, 2015-04-05 at 14:35 +0300, Slava Monich wrote:
> I think I finally caught one of the scenarios like that. The trick was
> to receive DISCONNECTED event from wpa_supplicant followed by
> ASSOCIATING while network->connecting is set to true.
>
> 1. DISCONNECTED sets device->scanning to true
On 02/04/15 15:15, Tomasz Bursztyka wrote:
>> There are some corner cases that I have been unable to catch so far,
>> which result in connman_service holding a reference to connman_network
>> in connecting/associating state (albeit with driver pointer being NULL)
>> but those are quite rare. That s
Hi Slava,
Ah, That's another bug then!
If we detect that we got disconnected, the wifi plugins will need to
cleanup.
Actually, it cleanups if the user disconnects, but not this way round.
Check interface_state() in wifi_plugins. This will need a separate patch.
Well, it actually kind of works.
Hi,
On Thu, 2015-04-02 at 14:32 +0300, Slava Monich wrote:
> Since I'm not the one who designed this thing, I prefer small fixes
> that don't affect the overall architecture which at times is pretty
> hard to grasp. If you are not happy with this approach, you are quite
> welcome to fix i
On 02/04/15 13:46, Tomasz Bursztyka wrote:
> Hi Slava,
>
It appears that the client is responsible for removing network
configurations it has created, which makes sense to me. In an
environment with unstable wifi reception, connman may end up creating
hundreds of those in just o
Hi Slava,
It appears that the client is responsible for removing network
configurations it has created, which makes sense to me. In an
environment with unstable wifi reception, connman may end up creating
hundreds of those in just one day of normal usage.
Well this is true if it always fail con
On 02/04/15 12:35, Tomasz Bursztyka wrote:
> Hi Slava,
>
>> It appears that the client is responsible for removing network
>> configurations it has created, which makes sense to me. In an
>> environment with unstable wifi reception, connman may end up creating
>> hundreds of those in just one day o
Hi Slava,
It appears that the client is responsible for removing network
configurations it has created, which makes sense to me. In an
environment with unstable wifi reception, connman may end up creating
hundreds of those in just one day of normal usage.
Well this is true if it always fail co
On 02/04/15 09:25, Patrik Flykt wrote:
> @@ -4041,6 +4046,15 @@ static void interface_add_network_result(const char
> *error,
>
> SUPPLICANT_DBG("PATH: %s", path);
>
> + if (interface->network_path && strcmp(interface->network_path, path)) {
> + /* Prevent unused wpa_supp
Hi,
On Tue, 2015-03-24 at 16:03 +0200, Slava Monich wrote:
> Remove previously created network after creating a new one.
> This prevents wpa_supplicant network objects (wpa_cli list_net)
> from piling up.
> ---
> gsupplicant/supplicant.c | 14 ++
> 1 file changed, 14 insertio
Remove previously created network after creating a new one.
This prevents wpa_supplicant network objects (wpa_cli list_net)
from piling up.
---
gsupplicant/supplicant.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index cd9
11 matches
Mail list logo
