Hello,
We are currently investigating an issue with IPv6 getting disabled during a
sequence when a user switches WIFi networks.
The sequence of events from the client perspective is:
1. The device is connected over WiFi to some NetworkA with both an IPv4
address via DHCP and several IPv6 addresses via autoconf via RA's.
2. The user disconnects from NetworkA and connects to NetworkB
3. The device successfully connects to NetworkB, and obtains an IPv4
address via DHCP, however there is no IPv6 Link-Local address present.
There are no IPv6 routers present on NetworkB so we get Global addresses
are resolved via RA's as well.
>From my look at the code and enabling debugging, this sequence appears to
be happening:
I. Starting at (3), ConnMan gets the connect request and sets up two
IPConfig contexts to track IPv4 and IPv6 states. It consequently enables
IPv6 in the process via enable_ipv6().
II. At some point during the association/connection process, likely a
behavior of the underlying WiFi driver, the state of the wlan0 interface
goes from <UP,RUNNING,LOWER_UP> to <UP> triggering a service_lower_down().
service_lower_down() eventually calls disable_ipv6()
III. Shortly afterwards, the interface returns to the <UP,RUNNING,LOWER_UP>
state. However IPv6 is still disabled.
This is not 100% reproducible, and have confirmed that IPv6 is still set to
"AUTO" through connmanctl.
I've found the following recovers things:
- Restarting only ConnMan
- Disconnecting and reconnecting to NetworkB
- Setting IPv6 to auto again via "connmanctl config NetworkB --ipv6 AUTO"
As a potential fix/workaround, I've made the following change to enable
IPv6 if IPv6 is not idle to service_lower_up():
--- a/connman/src/service.c
+++ b/connman/src/service.c
@@ -6038,6 +6038,9 @@ static void service_lower_up(struct connman_ipconfig
*ipconfig)
DBG("%s lower up", __connman_ipconfig_get_ifname(ipconfig));
+ if (is_idle_state(service,service->state_ipv6) == FALSE)
+ __connman_ipconfig_enable_ipv6(service->ipconfig_ipv6);
+
stats_start(service);
}
We have a relatively old version of ConnMan, 1.11 but I checked this
morning for anything that was obviously a fix for the same bug and didn't
find anything.
Thoughts? I suspect there is a more elegant way of doing this, and would
appreciate any feedback.
--
-- Arjuna
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
