Connman on my rpis sending changing DUIDs to dnsmasq dhcp server thereby progessively eating up all its dhcpv6 leases

Hello,

My raspberry pis running OSMC which use connman 1.41 are displaying a
weird behavior leading to multiple dhcpv6 leases being "consumed" by
the same network service/interface
After discussing this on the osmc forum (same/more information can be
found here : https://discourse.osmc.tv/t/rpis-and-connman-are-providing-multiple-duids-to-dhcpv6-server/97135
it seems soliciting the connman) with the lead osmc developer
sam_nazarko we decided I should push this to this mailing list.

I'll take the example of my pi4

My environment :
* dnsmasq (on my ddwrt router) with the following ipv6 configuration
for slaac (required by android) and dhcpv6 (for my
desktops/laptops/printer/...) and a static lease for the pi4:
  dhcp-hosts=DC:A6:32:1D:C9:0F,pi4,192.168.2.9,[::9],24h
  dhcp-range=::2,::106,constructor:br0,slaac,ra-names,64,24h
* fddd:: is the ULA prefix I'm using on my network (alongside my
public prefix) behavior with both is the same so I'm illustrating with
the ULA prefix.
* pi4 MAC address is dc:a6:32:1d:c9:0f for its interface eth0
* pi4 has a cron job checking its connectivity and restarting connman
(via: systemd restart connman) if the dns server loses track of it

After some time dnsmasq.leases file shows that pi4 has grabbed
multiple dhcpv6 leases (due to multiple DUIDs) from dnsmasq (and at
some point in the day dnsmasq has no more to hand out causing
connection issues to led me to identifying the issue)
> 1712252648 T840812815 fddd::f * 00:01:00:01:2d:a0:51:e8:dc:a6:32:1d:c9:0f
> 1712252533 T840812815 fddd::e2 * 00:01:00:01:2d:a0:51:74:dc:a6:32:1d:c9:0f
> 1712252414 T840812815 fddd::4d * 00:01:00:01:2d:a0:50:fd:dc:a6:32:1d:c9:0f
> 1712252289 T840812815 fddd::c5 * 00:01:00:01:2d:a0:50:80:dc:a6:32:1d:c9:0f
> 1712252169 T840812815 fddd::d9 * 00:01:00:01:2d:a0:50:09:dc:a6:32:1d:c9:0f
> 1712252052 T840812815 fddd::49 * 00:01:00:01:2d:a0:4f:95:dc:a6:32:1d:c9:0f
> 1712251932 T840812815 fddd::85 * 00:01:00:01:2d:a0:4f:1c:dc:a6:32:1d:c9:0f
> 1712251813 T840812815 fddd::3 * 00:01:00:01:2d:a0:4e:a5:dc:a6:32:1d:c9:0f
> 1712251689 T840812815 fddd::78 * 00:01:00:01:2d:a0:4e:28:dc:a6:32:1d:c9:0f
> 1712251568 T840812815 fddd::7a * 00:01:00:01:2d:a0:4d:af:dc:a6:32:1d:c9:0f
> 1712251452 T840812815 fddd::64 * 00:01:00:01:2d:a0:4d:3c:dc:a6:32:1d:c9:0f
> 1712251333 T840812815 fddd::4b * 00:01:00:01:2d:a0:4c:c5:dc:a6:32:1d:c9:0f
> 1712251213 T840812815 fddd::d4 * 00:01:00:01:2d:a0:4c:4c:dc:a6:32:1d:c9:0f
> 1712251094 T840812815 fddd::38 * 00:01:00:01:2d:a0:4b:d6:dc:a6:32:1d:c9:0f
> 1712251032 T840812815 fddd::9 * 00:01:00:01:2d:a0:4b:97:dc:a6:32:1d:c9:0f

After some tests I identified and another user identified some of the
underlying issues:
* When I look at service's settings file it does not contain a
"IPV6.DHCP.DUID=" line (as it should according to src/dhcpv6.c)
>  >cat settings
> [ethernet_dca6321dc90f_cable]
> Name=Wired
> AutoConnect=true
> Modified=2024-04-04T19:44:08Z
> IPv4.method=dhcp
> IPv4.DHCP.LastAddress=192.168.2.9
> IPv6.method=auto
> IPv6.privacy=enabled
> IPv6.DHCP.LastAddress=fddd::f
> Domains=mydomain.fr;

* a simple test with the following command shows an interesting result
: a settings file is written with DUID (upon writing dhcpv6 ipv6
ipconfig ?) and then overwritten (upon writing slaac ipv6 ipconfig ?)
without the DUID
> >connmanctl config ethernet_dca6321dc90f_cable --ipv6 auto enable && cat settings && sleep 1 && cat settings && sleep 1 && cat settings
> [ethernet_dca6321dc90f_cable]
> Name=Wired
> AutoConnect=true
> Modified=2024-04-04T21:02:33Z
> IPv4.method=dhcp
> IPv4.DHCP.LastAddress=192.168.2.9
> IPv6.method=auto
> IPv6.privacy=enabled
> Domains=mydomain.fr;
>
> [ethernet_dca6321dc90f_cable]
> Name=Wired
> AutoConnect=true
> Modified=2024-04-04T21:02:33Z
> IPv4.method=dhcp
> IPv4.DHCP.LastAddress=192.168.2.9
> IPv6.method=auto
> IPv6.privacy=enabled
> Domains=mydomain.fr;
> IPv6.DHCP.DUID=000100012da1b8eddca6321dc90f
>
> [ethernet_dca6321dc90f_cable]
> Name=Wired
> AutoConnect=true
> Modified=2024-04-04T21:02:33Z
> IPv4.method=dhcp
> IPv4.DHCP.LastAddress=192.168.2.9
> IPv6.method=auto
> IPv6.privacy=enabled
> IPv6.DHCP.LastAddress=fddd::6f
> Domains=mydomain.fr;

One could think here the issue is just that the DUID is "overwritten"
to the settings file but alas no
--> Question: why is it being overwritten (but not the "Modified="
line) ? and how to avoid it ?

* Indeed another user (JImKnopf) who uses a frtizbox's dhcpv6 server
(for Router advertisement of prefix for SLAAC + dhcpv6 for DNS or
“DNS, assign IA_PD prefix” or “DNS, assign IA_PD and IA_NA”) has a
DUID in the settings file but notices that it changes on every reboot,
suggesting the issue is that the DUID in the settings file is not
reused (although it seems it should be from src/dhcpv6.c)
--> Question: why is the DUID not being reused but a new one generated
? Bug or underlying reason we don't understand ?

As a workaround for now we applied the following patch to src/dhcpv6.c
to use an G_DHCPV6_DUID_LL (which should always be the same according
to src/client.c instead of the default G_DHCPV6_DUID_LLT)
> >cat test.patch
> --- src/dhcpv6.c 2024-04-05 22:08:13.180517921 +0200
> +++ src/dhcpv6.c 2024-04-05 22:08:35.943982173 +0200
> @@ -225,7 +225,7 @@
>                int ret;
>                int type = __connman_ipconfig_get_type_from_index(index);
>
> -               ret = g_dhcpv6_create_duid(G_DHCPV6_DUID_LLT, index, type,
> +               ret = g_dhcpv6_create_duid(G_DHCPV6_DUID_LL, index, type,
>                                        &duid, &duid_len);
>                if (ret < 0) {
>                        g_key_file_free(keyfile);

Using the workaround patched connman our DUID changes and multiple
leases issues disappear, however this is just a workaround and the
original issues might need to be addressed.
I'm willing to help debug this if necessary.

Thanks in advance for any answers/feedback/help/instructions

Regards

Benjamin

P.S. : Is there a way to have connman disregard SLAAC ? (As part of my
testing I tried 'sysctl net.ipv6.conf.eth0.autoconf=0' as suggested by
the kernel documentation but that led to no ipv6 at all which was not
expected)