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
