Rpis and connman are providing multiple DUIDs to dhcpv6 server

Help and Support
1

Hello,

running full stack as my provider is IPV4 CGNAT + IPV6 so IPV6 is mandatory for remote acces to my network.

Lately my rpi are causing my dnsmasq (dns & dhcpv4 & dhcpv6) server on my router to have no more leases as they are multiplying ipv6 leases with different DUIDs as illustrated below for the case of my pi4 whose ethernet interface MAC address is “dc:a6:32:1d:c9:0f” and the related lines in my dnsmasq.leases file (router running ddwrt)

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

dnsmasq is configured with :

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

and fddd:: is my ULA prefix (I also have a Public prefix and the same multiple leases with it… but for privacy I won’t add it :-))
So connman should be providing a SLAAC address to the server to store in dns table and getting fddd::9 lease from the server.

From what I have read as only the ethernet port is connected there is no reason of seeing these differnets DUIDs for pi4

I searched and googled but cannot find where connman stores the DUID(s) it uses or how it creates it (them) to send it(them) to the dhcpv6 server…

Where/how can I force a unique dhcpv6 DUID for a specified “service” in osmc ?

Thans in advance for any tips

2

I’d check /var/lib/connman but this one might belong on the ConnMan mailing list as it would be a bit beyond my knowledge.

How have you enabled IPv6 on OSMC (we have it off by default)?

3

The DUID is written to the file

/var/lib/connman/ethernet*/settings

and afaI understand
https://git.kernel.org/pub/scm/network/connman/connman.git/

connman-1.41.tar.gz\connman-1.41.tar\connman-1.41\src\dhcpv6.c

the DUID should be read out of the file in method set_duid. So, it’s intended to be stable over time.

But in real the DUID is recreated on every reboot. @sam_nazarko, can you help @dwardor with more details, where he can address his issue to the connman folks?

4

I activated ipv6 with connmanctl config ethernet_dca6321dc90f_cable config --ipv6 auto enable

5 
> cat settings 
[ethernet_dca6321dc90f_cable]
Name=Wired
AutoConnect=true
Modified=2024-04-04T03:48:32Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=192.168.2.9
IPv6.method=auto
IPv6.privacy=enabled
IPv6.DHCP.LastAddress=fddd::9
Nameservers=192.168.2.1;
Domains=mydomain.fr;

No sign of a DUID in there (that file was my first reflex to look at).

6

mmhhh,

root@osmc-pi4:~# ls -al /var/lib/connman/
total 16
drwxr-xr-x  3 root root 4096 Apr  4 08:10 .
drwxr-xr-x 21 root root 4096 Feb 14 07:22 ..
drwx------  2 root root 4096 Apr  4 08:10 ethernet_dca632d63aaa_cable
-rw-------  1 root root  237 Mar 27 08:05 settings
root@osmc-pi4:~# connmanctl config ethernet_dca632d63aaa_cable --ipv6 auto
root@osmc-pi4:~# cat /var/lib/connman/ethernet_dca632d63aaa_cable/settings
[ethernet_dca632d63aaa_cable]
Name=Wired
AutoConnect=true
Modified=2024-04-04T08:10:25Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=10.10.10.184
IPv6.method=auto
IPv6.privacy=disabled
IPv6.DHCP.DUID=000100012da1018adca632d63aaa
root@osmc-pi4:~# dpkg -l |grep -i connm
ii  armv7-connman-osmc                   1.41-2                         armhf        connman for OSMC

I’m on latest/greatest development staging … but the DUID changes with every reboot.

7

What happens if you configure it static?
Does it still generate on each boot?

8

if you configure a static/manual ipv6, you don’t have a DUID since it’s only required for the DHCPv6 servers:

root@osmc-pi4:~# ls /var/lib/connman/ethernet_dca632d63aaa_cable/settings
/var/lib/connman/ethernet_dca632d63aaa_cable/settings
root@osmc-pi4:~# connmanctl config ethernet_dca632d63aaa_cable --ipv6 manual fd00:10:10:10:dea6:32ff:fed6:3aaa 64
root@osmc-pi4:~# cat /var/lib/connman/ethernet_dca632d63aaa_cable/settings
[ethernet_dca632d63aaa_cable]
Name=Wired
AutoConnect=true
Modified=2024-04-04T08:38:29Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=10.10.10.184
IPv6.method=manual
IPv6.privacy=disabled
IPv6.netmask_prefixlen=64
IPv6.local_address=fd00:10:10:10:dea6:32ff:fed6:3aaa
9

hum… I’m also on

> dpkg -l |grep -i connm
ii  armv7-connman-osmc                   1.41-2                         armhf        connman for OSMC

But my settings file does not have IPv6.DHCP.DUID=

What could I be missing here ?

10

Perhaps, this is a result of switching between manual and auto configuration … who knows?
I suggest to remove the config directory and restart the ipv6 configuration, like

rm -R ethernet* && sync && reboot

11

OK So things are getting clearer…

My DUID is not getting stored … so everytime I disconnect/connect the service connmanctl disconnect ethernet_xxx && connmanctl connect ethernet_xxx or restart connman systemctl restart connman (I have a cron job checking connectivity and doing just that) a new DUID is created on new DHCPV6 connection → explains why the lease file fills up during the day

So the underlying issue is: Why is the DUID no getting stored ?

Will try removing the the service as per your suggestion and recreating it from scratch

12

Removing the service and recreating it makes no difference…
Here is an interesting test result though !

>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;

Notice how:

  • the IPV6.DHCP.DUID appears in the 2nd cat settings and then disappears in the 3rd cat settings when IPv6.DHCP.LastAddress= appears (could writing it erase the DUID ? → going to look at the source)
  • you don’t have a IPv6.DHCP.LastAddress= in your settings file a few posts above

any further cat settings return the same thing as the 3rd one.

13

Strange, only idea I have, that this behaviour is dependent from the dhcpv6 answers.
Besides that, on my system I get a new DUID on every boot (or might be disconnect/connect) … it looks also to be wrong.

14

If I deactivate the DHCPv6-server in my environment (router is an AVM Fritz!Box 7590), the DUID line in the settings file also disappears.
So, it is dependent from the communication with the DHCPv6 server.

15

@sam_nazarko would it be possible for you to compile a test connman package modified with this simple patch:

>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 patch src/dhcpv6.c test.patch

This makes connman use a DUID_LL instead of a DUID_LLT dropping the T(time) information so the DUID_LL should always be the same (even if not stored in the keyfile) as suggests src/client.c

int g_dhcpv6_create_duid(GDHCPDuidType duid_type, int index, int type,
			unsigned char **duid, int *duid_len)
{
	time_t duid_time;

	switch (duid_type) {
	case G_DHCPV6_DUID_LLT:
		*duid_len = 2 + 2 + 4 + ETH_ALEN;
		*duid = g_try_malloc(*duid_len);
		if (!*duid)
			return -ENOMEM;

		(*duid)[0] = 0;
		(*duid)[1] = 1;
		__connman_inet_get_interface_mac_address(index, &(*duid)[2 + 2 + 4]);
		(*duid)[2] = 0;
		(*duid)[3] = type;
		duid_time = time(NULL) - DUID_TIME_EPOCH;
		(*duid)[4] = duid_time >> 24;
		(*duid)[5] = duid_time >> 16;
		(*duid)[6] = duid_time >> 8;
		(*duid)[7] = duid_time & 0xff;
		break;
	case G_DHCPV6_DUID_EN:
		return -EINVAL;
	case G_DHCPV6_DUID_LL:
		*duid_len = 2 + 2 + ETH_ALEN;
		*duid = g_try_malloc(*duid_len);
		if (!*duid)
			return -ENOMEM;

		(*duid)[0] = 0;
		(*duid)[1] = 3;
		__connman_inet_get_interface_mac_address(index, &(*duid)[2 + 2]);
		(*duid)[2] = 0;
		(*duid)[3] = type;
		break;
	}

	return 0;
}
1 Like
16

I am happy to do that.

We should also check that the change is valid against top of tree ConnMan (master) and whether such a fix has been implemented already? It’s late here so I won’t do that now.

In the interim, I already made such a change available here:

wget https://collab.osmc.tv/index.php/s/ZeYdZHapKwNmHpS/download/armv7-connman-osmc.deb -O connman.deb
sudo dpkg -i connman.deb
reboot

Cheers,

Sam

17

If you believe the entries in the settings file, this seems to work:

#cat /var/lib/connman/ethernet_900eb31cafdd_cable/settings
[ethernet_900eb31cafdd_cable]
Name=Wired
AutoConnect=true
Modified=2024-04-06T08:22:07Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=10.10.10.182
IPv6.method=auto
IPv6.privacy=disabled
IPv6.DHCP.DUID=00030001900eb31cafdd

root@osmc-vero4kplus:~# connmanctl disconnect ethernet_900eb31cafdd_cable && connmanctl connect ethernet_900eb31cafdd_cable
Disconnected ethernet_900eb31cafdd_cable
Connected ethernet_900eb31cafdd_cable

root@osmc-vero4kplus:~# cat /var/lib/connman/ethernet_900eb31cafdd_cable/settings
[ethernet_900eb31cafdd_cable]
Name=Wired
AutoConnect=true
Modified=2024-04-06T08:22:36Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=10.10.10.182
IPv6.method=auto
IPv6.privacy=disabled
IPv6.DHCP.DUID=00030001900eb31cafdd

I’m still wondering why the connman folks insert timestamp information by default. Are there dhcpv6 systems, which have a problem with getting the same DUID again and again?

18

Thanks @sam_nazarko

just tested the changes and now the same DUID is sent everytime to the server so my problem is short-circuited :slight_smile:

As expected IPv6.DHCP.DUID is still nowhere to be found in settings :frowning_face:

>cat settings
[ethernet_dca6321dc90f_cable]
Name=Wired
AutoConnect=true
Modified=2024-04-06T09:47:29Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=192.168.2.9
IPv6.method=auto
IPv6.privacy=enabled
IPv6.DHCP.LastAddress=fddd::9
Domains=mydomain.fr;

I also just downloaded master and verifed the patch also applies to it

However, it still would be nice to file 2 bug reports for connman’s underlying bugs regarding sending different DUIDs with the default G_DHCPV6_DUID_LLT:

  • for the DUID not being stored (because overwritten ?) in the settings file (my case)
  • stored DUID not being correctly reused and a new one generated and used (JimKnopf case)

→ am not figuring out how to do that grep -i bug * picks up no instruciton for filing/reporting a bug report

19

If needed I am willing to test a connman master package

  • without the test.patch to see if other modification have solved the underlying issue in 1.41
  • with test.patch (if still issues without it)
20

Just had a thought…

I’m doing both DHCPv6 for adress and slaac… it is more than possible connman is saving the settings file twice…

  1. after configuring the dhcpv6 handed address (when the IPv6.DHCP.DUID is present but not the IPv6.DHCP.LastAddress)
  2. after configuring the slaac adress (when the IPv6.DHCP.DUID is not present but the IPv6.DHCP.LastAddress is)

@JimKnopf would you by anychance be doing only dhcpv6 and no slaac ?