On 28.10.2015 11:32, Patrik Flykt wrote:
>> From: Pasi Sjöholm <pasi.sjoh...@jollamobile.com>
>> Due unknown reason sometimes device->scanning is not set to false after
>> wifi scanning (connman 1.30 and wpa_supplicant 2.5).
>> This is probably due callback-function not being called after wifi scan
>> and therefore it needs to have a timer to prevent deadlock.
>> ---
> You probably have evidence that the callback is not called, right?
> Please state that in the commit message.

I don't have logs stored anymore on my disk but I'm rather sure that
wifi.c:scan_callback() is not being called when this happens as all
attemps to scan by connman are blocked by device->scanning being true (I
usually get bored after waiting for couple of hours ;)).

When the deadlock happens and I can manually ask wpa_supplicant to scan
available networks from the commandline. After doing this ConnMan will
survive from the deadlock through NetworkAdded being signaled and
autoconnectable network being available as ConnMan gets connected and
autoscan will be stopped.

The problem is hard to reproduce (no known steps) but it has happened to
me around 4 times within last few weeks.

> What will happen if wpa_supplicant will call the callback after 16
> seconds, i.e. after ConnMan has triggered scan_fail_timeout? Will there
> be any artefacts if this happens?

By quickly looking at the code there shouldn't be any issues but I can't
be 100% sure. In theory one could stop autoscan after scan has been
started and restart it immediately before the scan_callback gets called
to have the same effect and ConnMan must be able to handle it.

Currently the TIMEOUT defined in the dbus.c seems to be 30 secs and
after that the callback-function should be called if no reply has been
received (if I read and understand the code correctly). So having 60
seconds timeout should be ok as there should not be any calls coming
from wpa_supplicant after that.

I will modify the timeout and edit the commit message a bit.

connman mailing list

Reply via email to