Odhcpd crash loop when receiving packet

klipz · November 13, 2025, 6:07pm

Build is one or two days old:
OpenWrt SNAPSHOT, r31779-356acef794

In syslog:

Wed Nov 12 22:25:05 2025 daemon.info procd: Instance odhcpd::instance1 s in a crash loop 6 crashes, 1035 seconds since last crash
Thu Nov 13 12:15:35 2025 daemon.info procd: Instance odhcpd::instance1 s in a crash loop 6 crashes, 1256 seconds since last crash

Manually executed:
odhcpd -c /etc/config/ -l 7 -f

So I could catch what was going on:
Received 140 Bytes from fe80::a83c:3eff:feda:9c18%lan@br-lan
Got a DHCPv6-request on lan
Segmentation fault

I can restart odhcpd service, but this happens eventually (in a matter of minutes), after some period of seemingly normal operation. Any ideas? I do note there has been some “churn” in the odhcpd code recently…

Thanks in advance.

systemcrash · November 13, 2025, 6:37pm

@Alphix we got one.

Tricky. Your router goes about 1000-1200 seconds, so there’s something specific, on occasion.

Advice: install tcpdump on the router, and use the sshdump wireshark plugin. Set wireshark “remote interface” to whichever layer 2 device lan is (if using just lan doesn’t capture anything). Then you can correlate the packet, and its content, which triggers it. Packet type and content will help localise the problem.

Are you in relay mode?

dave14305 · November 13, 2025, 6:56pm

You can also install strace and see what the last calls are when it crashes.

strace -f -p $(pidof odhcpd)

klipz · November 13, 2025, 7:20pm

I am not in relay mode, no. Am at work now but will definitely follow all provided troubleshoot steps and update this thread with what I find.

It’s a very annoying problem since odhcpd crashes and does not restart, left me wondering why I had no IPv6 connectivity for a while.

klipz · November 13, 2025, 9:08pm

@dave14305 It did not take long to get the strace results:

Received 74 Bytes from fe80::a83c:3eff:feda:9c18%lan@br-lan
Got a DHCPv6-request on lan
Segmentation fault

writev(2, [{iov_base="Received 74 Bytes from fe80::a83"..., iov_len=59}, {iov_base=NULL, iov_len=0}], 2) = 59
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 2) = 1
writev(2, [{iov_base="Got a DHCPv6-request on lan", iov_len=27}, {iov_base=NULL, iov_len=0}], 2) = 27
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 2) = 1
ioctl(6, SIOCGIFHWADDR, {ifr_name="br-lan", ifr_hwaddr={sa_family=ARPHRD_ETHER, sa_data=66:80:ad:1d:f9:e8}}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x78} ---
+++ killed by SIGSEGV +++

klipz · November 13, 2025, 9:31pm

@systemcrash Perhaps this will be helpful as well?

Received 140 Bytes from fe80::832:94ff:fe4c:42d1%lan@br-lan
Got a DHCPv6-request on lan
Segmentation fault

Entire raw packet contents via cli tcpdump:

16:27:05.203304 0a:32:94:4c:42:d1 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 206: fe80::832:94ff:fe4c:42d1.546 > ff02::1:2.547: dhcp6 renew
        0x0000:  6005 dea4 0094 1101 fe80 0000 0000 0000  `...............
        0x0010:  0832 94ff fe4c 42d1 ff02 0000 0000 0000  .2...LB.........
        0x0020:  0000 0000 0001 0002 0222 0223 0094 54b1  .........".#..T.
        0x0030:  0575 378f 0002 000a 0003 0001 6680 ad1d  .u7.........f...
        0x0040:  f9e8 0003 0044 ca53 095a 0000 0546 0000  .....D.S.Z...F..
        0x0050:  0870 0005 0018 fdfa fd2a 73b7 0010 0000  .p.......*s.....
        0x0060:  0000 0000 0352 0000 0e10 0000 0e10 0005  .....R..........
        0x0070:  0018 2600 4040 b2d5 1d10 0000 0000 0000  ..&.@@..........
        0x0080:  0352 0000 0a8c 0000 0e10 0027 0008 0106  .R.........'....
        0x0090:  676e 7333 766d 0006 000a 0017 0018 0038  gns3vm.........8
        0x00a0:  001f 000e 0001 000e 0002 0000 ab11 afea  ................
        0x00b0:  b88b 06ba 4fc0 0008 0002 0000 41f4 d95f  ....O.......A.._

Edit: Forgot to mention, your username is hilariously appropriate in this scenario.
Edit 2: “we got one.” had me worried for a moment, like I had sprung some sort of trap

dave14305 · November 13, 2025, 9:50pm

Thanks. Is it always the same client triggering the crash (at least so far)? Is there anything different about your lan interface (ip link show dev br-lan; ip addr show dev br-lan)?

It seems the crash comes from here:

github.com/openwrt/odhcpd

src/odhcpd.c

f13d2ceca


      
          }
          
          
          /* Read IPv6 MAC for interface */
          int odhcpd_get_mac(const struct interface *iface, uint8_t mac[6])
          {
          	struct ifreq ifr;
          
          	memset(&ifr, 0, sizeof(ifr));
          	strncpy(ifr.ifr_name, iface->ifname, sizeof(ifr.ifr_name) - 1);
          	if (ioctl(ioctl_sock, SIOCGIFHWADDR, &ifr) < 0)
          		return -1;
          
          	memcpy(mac, ifr.ifr_hwaddr.sa_data, 6);
          	return 0;
          }
          
          int odhcpd_get_flags(const struct interface *iface)
          {
          	struct ifreq ifr;

That's the full range of my contribution. systemcrash and Alphix are directly involved with the recent changes.

klipz · November 13, 2025, 9:54pm

@dave14305 it is not always the same client:

Received 140 Bytes from fe80::a83c:3eff:feda:9c18%lan@br-lan
Got a DHCPv6-request on lan
Segmentation fault

Received 140 Bytes from fe80::832:94ff:fe4c:42d1%lan@br-lan
Got a DHCPv6-request on lan
Segmentation fault

My lan interface is your run-of-the-mill OpenWRT bridged lan setup, using standard configuration options. It’s one port; there is nothing else on the bridge besides some software VLAN interfaces.

dave14305 · November 13, 2025, 10:06pm

I suppose the fault is likely in the memcpy(), but I should just stand down until smarter people return.

klipz · November 13, 2025, 10:08pm

No worries. I really like my OpenWRT router and really want this to work, so any/all input is appreciated.

systemcrash · November 13, 2025, 11:34pm

@klipz ubus call system board

Is it typically those two lan clients?

Weird:

The crash site has code several years old. But the pointer address is non-sensical.

klipz · November 13, 2025, 11:45pm

@systemcrash

It does appear to be those two clients; however I have three or four total downstream DHCPv6 clients obtaining prefixes via delegation, so I suppose it’s probably any of those four really.

{
	"kernel": "6.12.57",
	"hostname": "nanopi-r6c",
	"system": "ARMv8 Processor rev 0",
	"model": "FriendlyElec NanoPi R6C",
	"board_name": "friendlyarm,nanopi-r6c",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"firmware_url": "https://downloads.openwrt.org/",
		"revision": "r31779-356acef794",
		"target": "rockchip/armv8",
		"description": "OpenWrt SNAPSHOT r31779-356acef794",
		"builddate": "1762819609"
	}
}

I’m doing another manual execution now to double check, but I’m almost positive it’s always a dhcpv6 renew packet which is causing this.

dave14305 · November 13, 2025, 11:49pm

I guess the caller has changed though:

github.com/openwrt/odhcpd

src/dhcpv6.c

f13d2ceca


      
          		.serverid_length = 0,
          		.serverid_buf = { 0 },
          	};
          
          	if (config.default_duid_len > 0) {
          		memcpy(dest.serverid_buf, config.default_duid, config.default_duid_len);
          		dest.serverid_length = htons(config.default_duid_len);
          	} else {
          		uint16_t duid_ll_hdr[] = { htons(DUID_TYPE_LL), htons(ARPHRD_ETHER) };
          		memcpy(dest.serverid_buf, duid_ll_hdr, sizeof(duid_ll_hdr));
          		odhcpd_get_mac(iface, &dest.serverid_buf[sizeof(duid_ll_hdr)]);
          		dest.serverid_length = htons(sizeof(duid_ll_hdr) + ETH_ALEN);
          	}
          
          	struct _packed {
          		uint16_t type;
          		uint16_t len;
          		uint8_t buf[DUID_MAX_LEN];
          	} clientid = {
          		.type = htons(DHCPV6_OPT_CLIENTID),
          		.len = 0,

systemcrash · November 13, 2025, 11:55pm

Yes, although that suggests there is a workaround to avoid this, if we can’t figure it out. The caller is still running the old path. We know iface is valid because we just printed its name out. odhcpd is busy fishing out the MAC for the current interface when it crashes with that weird pointer.

@klipz Do all interfaces have MACs?

ip link show br-lan

Is the Pi overclocked?

klipz · November 13, 2025, 11:58pm

@systemcrash yes, it’s a bridge with a single interface:

[root@nanopi-r6c ~]# ip l show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP mode DEFAULT group default qlen 1000
link/ether 66:80:ad:1d:f9:e8 brd ff:ff:ff:ff:ff:ff

[root@nanopi-r6c ~]# ip l show br-lan
13: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 66:80:ad:1d:f9:e8 brd ff:ff:ff:ff:ff:ff

The system is not overclocked.

systemcrash · November 14, 2025, 12:08am

Welp, that matches the server id in the DHCPv6 packet, so this call works to get the MAC when the system hands out the address initially. But this renew packet comes in and boom. Does odhcpd consistently crash at the same spot (repeatedly run strace method)?

klipz · November 14, 2025, 12:09am

Your timing is impeccable, I was watching to confirm things and it just crashed a minute ago. Yes it’s identical behavior at the same place:

Received 140 Bytes from fe80::a83c:3eff:feda:9c18%lan@br-lan
Got a DHCPv6-request on lan
Segmentation fault

19:07:15.207900 aa:e6:b2:89:f9:1e > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 206: fe80::a83c:3eff:feda:9c18.546 > ff02::1:2.547: dhcp6 renew
0x0000: 6004 0c65 0094 1101 fe80 0000 0000 0000 `..e............
0x0010: a83c 3eff feda 9c18 ff02 0000 0000 0000 .<>.............
0x0020: 0000 0000 0001 0002 0222 0223 0094 0572 .........".#...r
0x0030: 0544 c8b9 0002 000a 0003 0001 6680 ad1d .D..........f...
0x0040: f9e8 0003 0044 b065 3dae 0000 0546 0000 .....D.e=....F..
0x0050: 0870 0005 0018 fdfa fd2a 73b7 0010 0000 .p.......*s.....
0x0060: 0000 0000 0352 0000 0e10 0000 0e10 0005 .....R..........
0x0070: 0018 2600 4040 b2d5 1d10 0000 0000 0000 ..&.@@..........
0x0080: 0352 0000 0a8c 0000 0e10 0027 0008 0106 .R.........'....
0x0090: 676e 7333 766d 0006 000a 0017 0018 0038 gns3vm.........8
0x00a0: 001f 000e 0001 000e 0002 0000 ab11 afea ................
0x00b0: b88b 06ba 4fc0 0008 0002 0000 75b1 5230 ....O.......u.R0

I’m US/Eastern TZ so you’ll note that is two minutes ago.

Edit: As you requested, strace output again from yet another segfault:

epoll_pwait(3, [{events=EPOLLIN, data=0xffff940a00f8}], 10, 494, NULL, 8) = 1
recvmsg(16, {msg_name={sa_family=AF_INET6, sin6_port=htons(546), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "fe80::832:94ff:fe4c:42d1", &sin6_addr), sin6_scope_id=if_nametoindex("br-lan")}, msg_namelen=28, msg_iov=[{iov_base="\6f\252\261\0\3\0D\312S\tZ\0\0\5F\0\0\10p\0\5\0\30\375\372\375*s\267\0\20"..., iov_len=8192}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=0x32, cmsg_data="\xff\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x02\x0d\x00\x00\x00"}], msg_controllen=40, msg_flags=0}, MSG_DONTWAIT) = 126
ioctl(6, SIOCGIFHWADDR, {ifr_name="br-lan", ifr_hwaddr={sa_family=ARPHRD_ETHER, sa_data=66:80:ad:1d:f9:e8}}) = 0--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x78} ---
+++ killed by SIGSEGV +++

systemcrash · November 14, 2025, 12:47am

It looks like the ioctl before the mac address copy completes fine.

I figure the memcpy is OK, but the subsequent write to dest.serverid_buf in odhcpd_get_mac might be unaligned, which might explain the SIGSEGV.

I’ll see whether I can cook up a patch.

klipz · November 14, 2025, 12:50am

That sounds excellent. I’m more than willing to test said patch in my environment.

systemcrash · November 14, 2025, 1:10am

What’s your version of odhcpd? I guess it’s odhcpd-ipv6only_2025.11.04~d44af6dd? Do you want a patch you can compile yourself or a ready binary?