Hi,
On Wed, 2014-09-17 at 15:30 +0200, Richard Röjfors wrote:
Hi,
Currently there is an issue in connman when Connect is issued for a failed
service.
1.
In connect service the incoming DBusMessage is assigned to service-pending.
2.
__connman_service_connect is called which will
call __connman_service_clear_error.
state_ipv4 and state_ipv6 is set to unknown.
In the following call to service_inidicate_state, its found that we
transition to idle from failure, resulting in a call to
__connman_service_disconnect.
3.
In disconnect reply_pending is called which will take the DBusMessage and
reply with an error.
Yes, this is a bug. I'll fix it.
This is new behaviour since the commit:
127d216001076d2b73a352a019f00d49bae30835
I'm not 100% sure what issue the commit fixed. I guess we could go back and
let service_indicate_state only call disconnect in idle if previous state
wasnt disconnected OR failure. But that might roll back the fix of the
commit. We could also avoid to attach the message (step 1.) but a lot of
other error checks would than fail...
The commit fixed ½ of the bug where a retry from the UI would fail after
the second retry attempt. Turns out ipconfig and service state were not
properly cleared, so the service had been left in failure state, which
was the new state proposed by ipconfig. Since a transition to failure
state when already in failure state makes no sense, the code returned
without doing the proper UI passphrase and retry logic.
Cheers,
Patrik
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
