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
> 2. ASSOCIATING sets device->scanning to false, which invokes
> remove_unavailable_network(), sets network->driver to NULL and
> eventually calls __connman_service_remove_from_network() for the
> network
> in question.
>
> Now the service is holding reference to the dead network,
> update_from_network() doesn't work because network->connecting is
> true,
> __connman_network_disconnect() doesn't work because network->driver is
> NULL. That's it.
>
> I just sent a patch that should prevent that from happening in two
> places along this course of events - by dropping reference to the dead
> service in __connman_service_remove_from_network() and in
> update_from_network(). Under this particular scenario the latter seems
> to be unnecessary but I'm pretty sure there are more bugs floating
> around so I suggest to keep both checks.
This is way too late/too high in the stack. Please fix this latest in
plugins/wifi.c if gsupplicant cannot handle this.
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
