Summary

When SLAAC+Stateless DHCP is enabled on a LAN interface, the dhcp6s process (PID 12669) opens two UDP sockets bound to :::547. Only one socket is actively serviced. The other accumulates unread datagrams indefinitely: after 18.5 hours of uptime, the receive queue had grown to 214,272 bytes (~209 KB). DHCPv6 Information Request packets that arrive on the unserviced socket are silently dropped, causing clients to retry. On Apple devices (iOS/macOS/watchOS), failed DHCPv6 responses can cascade into repeated DHCPv4 DHCPREQUEST cycles, inflating the Omada controller event log with spurious "DHCP Server allocated" entries.

This is a distinct issue from the DHCP event log noise caused by Wi-Fi roaming (Non-Stick Roaming, etc.). The socket leak affects clients with stable Wi-Fi associations.

Environment

Component	Detail
Router	ER707-M2 v1.20
Firmware	1.4.1 Build 20260325 Rel.78146
Controller	Omada SDN 5.15.24.19 (Docker — mbentley/omada-controller on Synology DS920+)
APs	EAP772 (US) v2.0 FW 1.2.3, EAP723 (US) v2.0 FW 1.1.3
Switch	SG2210MP v5.0 FW 5.0.12
LAN IPv6 config	SLAAC + Stateless DHCP, prefix delegation from WAN1 (AT&T Fiber / BGW320-500 in IP Passthrough)
LAN IPv4 config	DHCP enabled, pool 192.168.0.100–254, lease time 3000 min
Uptime at observation	0 day, 18 hour, 32 min

Evidence

1. Two UDP sockets on :::547, one with a growing unread buffer

From diagnostic export (netstat output), captured at 18h32m uptime:

udp        0      0 :::547                  :::*
udp   214272      0 :::547                  :::*

The first socket has Recv-Q = 0 (being actively read). The second has Recv-Q = 214272 — approximately 209 KB of unprocessed DHCPv6 packets.

At the observed growth rate, this is approximately 11.5 KB/hour of accumulation. The buffer will grow until it hits the kernel's rmem_max, after which inbound DHCPv6 packets on that socket will be silently dropped at the kernel level.

2. Only one dhcp6s process exists

From the process list:

12669 root  5160 S  /usr/sbin/dhcp6s -c /etc/dhcp6s.conf -P /var/run/dhcp6s.pid inf.1

No other process on the system is bound to UDP 547 — both sockets belong to this single dhcp6s instance. This is consistent with dhcp6s opening one socket for link-local unicast communication and a second for multicast group ff02::1:2membership, but only calling recvfrom() on one of them.

3. DHCPv6 Information Requests immediately follow every DHCPv4 ACK

Syslog shows a tightly coupled v4/v6 pattern — every DHCPv4 lease confirmation is immediately followed by a DHCPv6 Information Request from the same client (identified by matching DUID to MAC):

[16] daemon.notice dnsmasq[6042]: 2064761849 DHCPREQUEST(inf.1) 192.168.0.144 76:b9:4b:7b:b0:5b
[17] daemon.notice dnsmasq[6042]: 2064761849 DHCPACK(inf.1) 192.168.0.144 76:b9:4b:7b:b0:5b iPad
[18] daemon.emerg  dnsmasq[6042]: TP17,12251[6042]: 192.168.0.14476:b9:4b:7b:b0:5b
[19] daemon.debug  dhcp6s[12669]: server6_recv: received information request from fe80::c33:4d5e:358d:a0d%inf.1
[20] daemon.debug  dhcp6s[12669]: dhcp6_get_options: get DHCP option client ID, len 10
[21] daemon.debug  dhcp6s[12669]:   DUID: 00:03:00:01:76:b9:4b:7b:b0:5b
[22] daemon.debug  dhcp6s[12669]: dhcp6_get_options: get DHCP option option request, len 6
[23] daemon.debug  dhcp6s[12669]:   requested option: DNS
[24] daemon.debug  dhcp6s[12669]:   requested option: domain search list
[25] daemon.debug  dhcp6s[12669]:   requested option: opt_103
[26] daemon.debug  dhcp6s[12669]: dhcp6_get_options: get DHCP option elapsed time, len 2
[27] daemon.debug  dhcp6s[12669]:   elapsed time: 0
[28] daemon.debug  dhcp6s[12669]: copy_option: set client ID (len 10)
[29] daemon.debug  dhcp6s[12669]: copy_option: set server ID (len 10)
[30] daemon.debug  dhcp6s[12669]: copy_option: set DNS (len 32)
[31] daemon.debug  dhcp6s[12669]: server6_send: transmit reply to fe80::c33:4d5e:358d:a0d%inf.1

In this trace the request was received and replied to successfully (it hit the serviced socket). But when a client's Information Request lands on the orphaned socket, no reply is generated. The client retries — and on Apple devices, a failed DHCPv6 exchange can trigger a DHCPv4 re-validation (DHCPREQUEST), which in turn triggers another DHCPv6 Information Request, creating a feedback loop.

4. No other process contends for port 547

Full netstat output confirms only dhcp6s uses port 547. The dhcp_probe process (PID 10488) operates on ports 67/68 (DHCPv4 only) and does not interact with DHCPv6:

10488 root  5200 S  /usr/sbin/dhcp_probe --probe_interval 1800 --max_captured 10 --client_port 68 --server_port 67 ...

5. Additional observations from diagnostic export

The daemon.emerg dnsmasq lines (e.g., TP17,12251[6042]: 192.168.0.14476:b9:4b:7b:b0:5b) appear to be TP-Link's internal IPC hook notifying the Omada framework of each DHCPACK — these are not actual emergencies despite the syslog severity. They confirm that every DHCPv4 ACK is surfaced to the controller as an "allocated" event, which explains the noisy Omada event log.

Also observed at high frequency in syslog:

daemon.warn avahi-daemon[10403]: [level=1] No slot available for reflected response cache, will not reflect response packet.

And intermittently:

daemon.err arpreq[14572]: json get obj 'clients' failed

These may be unrelated but suggest other internal IPC pathways are under strain.

Expected Behavior

dhcp6s should read from all sockets it opens, or close sockets it does not intend to service. The receive queue on all bound sockets should remain near zero under normal operation.

Impact

• DHCPv6 clients whose requests land on the orphaned socket receive no response. Since socket selection for incoming multicast UDP is nondeterministic, this affects a probabilistic subset of all DHCPv6 requests.
• Client retries inflate DHCP logs. The Omada controller event log shows dozens of "DHCP Server allocated" entries per client per hour, obscuring legitimate network events.
• Memory consumption grows linearly with uptime. The unread buffer consumes kernel memory (~11.5 KB/hour) until rmem_max is reached.
• Cascading v6 to v4 re-requests on Apple devices. iOS/macOS/watchOS devices that fail to receive a DHCPv6 Information Reply will frequently re-validate their DHCPv4 lease, compounding the issue.

Reproduction Steps

1. ER707-M2 with firmware 1.4.1 (likely also affects 1.4.0 and earlier, untested).
2. Configure a LAN interface with IPv6 type SLAAC + Stateless DHCP, prefix delegation from WAN.
3. Connect multiple clients (Apple devices reproduce most reliably due to aggressive DHCPv6 retry behavior).
4. Wait several hours for the buffer to accumulate.
5. Run diagnostic export: in the netstat section, observe two entries on :::547, one with a growing Recv-Q.

Suggested Fix

Investigate dhcp6s socket initialization. The process likely opens both a link-local unicast socket and a multicast socket (for ff02::1:2) but only includes one file descriptor in its select()/poll() event loop. Both should be polled and serviced.

System Info

System Description  - Omada Multi-Gigabit VPN Gateway
System Name         - ER707-M2
Hardware Version    - ER707-M2 v1.20
Firmware Version    - 1.4.1 Build 20260325 Rel.78146
Running Time        - 0 day - 18 hour - 32 min - 39 sec

Happy to provide the full diagnostic export, additional syslog captures at different uptime intervals, or run targeted tests if that would help isolate the issue. Thanks for looking into this!