On Fri, Feb 12, 2016 at 3:16 AM, Patrik Flykt
When the default gateway is removed, move the service to state ready
if the respective ipconfig was connected.
Based on a patch by Naveen Singh.
Coming back to the issue, downgrading the state to ready when removing the
gateway does seem the most stable thing to do. This location to do the state
transition was earlier proposed by Naveen Singh. In this variant the ipconfig
state is set to ready only if it is already connected.
It would be better to listen on the default routes added and removed
when setting the state, but this has quite a few implications on testing.
So let's try with this as a much easier working solution.
src/connection.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/connection.c b/src/connection.c
index 6b005e7..5234043 100644
@@ -963,6 +963,11 @@ void __connman_connection_gateway_remove(struct connman_service
+ if (__connman_service_is_connected_state(service, type))
connman mailing list
I understand this fix but it still does not fix the original issue.
The test was to let the DHCP renewal fail. Between the time device
gets a Link local and the device released its IP, the state was left
to online or ready. What we wanted the state to go to configuration
when DHCP lease renewal failed.
I was tracing the code path and this was happening:
1) dhcp_callback in network.c gets called from dhcp state machine
after losing the lease.
2) Since it is a failure case, dhcp_failure gets called
3) From dhcp_failure we call __connman_ipconfig_gateway_remove which
ends up calling __connman_connection_gateway_remove.
Now with your fix that you suggested even though we have cleared IPv4
address we are still making the state as READY which probably is not
the right thing to do. Do you think doing a state machine transition
from dhcp_failure to CONFIGURATION is the right thing to do?
Let me know your thoughts on this.