Why many DHCP requests and disassociations?

Arthur1 · May 26, 2025, 3:26am

Hi. Please see log entries below. I was using my computer the whole time. Why are there many DHCP-related entries? Why is my computer disassociated every half-hour? I thought that disassociations happened mostly on phones to save energy. My computer is a plugged-in desktop computer.

Are these entries normal or something to worry about?

Many thanks for any help.


Sun May 25 20:42:48 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [computer's MAC address]
Sun May 25 20:42:48 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [computer's MAC address] iMac
Sun May 25 20:42:50 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [computer's MAC address]
Sun May 25 20:42:50 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [computer's MAC address] iMac
Sun May 25 20:42:52 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [computer's MAC address]
Sun May 25 20:42:52 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [computer's MAC address] iMac
Sun May 25 20:42:57 2025 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) [computer's MAC address]
Sun May 25 20:42:57 2025 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.100 [computer's MAC address]
Sun May 25 20:42:59 2025 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) [computer's MAC address]
Sun May 25 20:42:59 2025 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.100 [computer's MAC address]
Sun May 25 20:43:00 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [computer's MAC address]
Sun May 25 20:43:00 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [computer's MAC address] iMac
Sun May 25 21:14:57 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED [computer's MAC address]
Sun May 25 21:14:57 2025 daemon.info hostapd: phy1-ap0: STA [computer's MAC address] IEEE 802.11: disassociated
Sun May 25 21:14:58 2025 daemon.info hostapd: phy1-ap0: STA [computer's MAC address] IEEE 802.11: authenticated
Sun May 25 21:14:58 2025 daemon.info hostapd: phy1-ap0: STA [computer's MAC address] IEEE 802.11: associated (aid 1)
Sun May 25 21:14:58 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED [computer's MAC address] auth_alg=open
Sun May 25 21:14:58 2025 daemon.info hostapd: phy1-ap0: STA [computer's MAC address] WPA: pairwise key handshake completed (RSN)
Sun May 25 21:14:58 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED [computer's MAC address]
Sun May 25 21:14:58 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [computer's MAC address]
Sun May 25 21:14:58 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [computer's MAC address] iMac
Sun May 25 21:46:03 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED [computer's MAC address]
Sun May 25 21:46:03 2025 daemon.info hostapd: phy1-ap0: STA [computer's MAC address] IEEE 802.11: disassociated
Sun May 25 21:46:04 2025 daemon.info hostapd: phy1-ap0: STA [computer's MAC address] IEEE 802.11: authenticated
Sun May 25 21:46:04 2025 daemon.info hostapd: phy1-ap0: STA [computer's MAC address] IEEE 802.11: associated (aid 1)
Sun May 25 21:46:04 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED [computer's MAC address] auth_alg=open
Sun May 25 21:46:04 2025 daemon.info hostapd: phy1-ap0: STA [computer's MAC address] WPA: pairwise key handshake completed (RSN)
Sun May 25 21:46:04 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED [computer's MAC address]
Sun May 25 21:46:04 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [computer's MAC address]
Sun May 25 21:46:04 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [computer's MAC address] iMac

reinerotto · May 26, 2025, 5:35am

At first glance, looks like PC-initiated disconnects. Because no reason for disconnects in logs provided.
Thus:

Lease time for IP to be increased ?
Re-keying interval to be increased ?

psherman · May 26, 2025, 6:25am

It's hard to know exactly what might be triggering that, but the best thing to do would be for us to review your configs to see if there are any problems.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

Arthur1 · May 26, 2025, 1:57pm

Many thanks for your quick responses, Augustus and Peter. Here are my configuration settings. Would you please tell me if you see anything odd, whether or not it is related to the DHCP and disassociations?

SYSTEM BOARD

{
	"kernel": "6.6.73",
	"hostname": "Kindness",
	"system": "ARMv8 Processor rev 4",
	"model": "Cudy WR3000S v1",
	"board_name": "cudy,wr3000s-v1",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.0",
		"revision": "r28427-6df0e3d02a",
		"target": "mediatek/filogic",
		"description": "OpenWrt 24.10.0 r28427-6df0e3d02a",
		"builddate": "1738624177"
	}
}

NETWORK

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix [redacted - redaction needed?]
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option delegate '0'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'
	option peerdns '0'
	list dns '9.9.9.9'
	list dns '149.112.112.112'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option norelease '1'
	option peerdns '0'
	list dns '2620:fe::fe'
	list dns '2620:fe::9'

WIRELESS

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/18000000.wifi'
	option band '2g'
	option channel '5'
	option htmode 'HE20'
	option country 'US'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'Kindness'
	option encryption 'psk2'
	option key [redacted]

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/18000000.wifi+1'
	option band '5g'
	option channel '48'
	option htmode 'HE80'
	option country 'US'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'Kindness'
	option encryption 'psk2'
	option key [redacted]

DHCP

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

FIREWALL

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
	option drop_invalid '1'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

reinerotto · May 26, 2025, 2:35pm

My suspicions concern the HE20 and HE80, thus I would set these to basic values, like HT20, just to confirm suspicion.

Do the disassoc occure, only when channel/station(s) busy, or also, when (almost) idle ?
Pls, provide (anon) log messages, when disassocs occure.
When disassoc triggered from AP, then there is a reason for it in log.

Arthur1 · May 26, 2025, 4:48pm

Done.

I was using default values. I cannot find these settings in luci. I did not change them through SSH cli before now. What are the differences among HE20, HE80, and HT20?

I don't know because I don't know when devices were busy and idle, other than when I was using the computer yesterday evening. I'll have to monitor.

Arthur1 · May 26, 2025, 5:00pm

I just learned a little about HT modes. My network is 802.11ax. Aren't HE20 and HE80 better on 802.11ax networks?

After you suggested HT20, I switched both radios to it. But isn't HT20 inappropriate for the 5 MHz radio?

Arthur1 · May 26, 2025, 5:20pm

After learning that HT20 switched my network to 802.11n, I switched back to HE20 and HE80 so I can use 802.11ax.

Or did you really mean that I should use 802.11n for troubleshooting?

brada4 · May 26, 2025, 6:11pm

Your shouting at wrong tree, your client pc should have logs on why it sends dhcp request every 2 seconds.

From DHCP RFC:

DHCP clients are responsible for all message retransmission. The
client MUST adopt a retransmission strategy that incorporates a
randomized exponential backoff algorithm to determine the delay
between retransmissions. The delay between retransmissions SHOULD be
chosen to allow sufficient time for replies from the server to be
delivered based on the characteristics of the internetwork between
the client and the server. For example, in a 10Mb/sec Ethernet
internetwork, the delay before the first retransmission SHOULD be 4
seconds randomized by the value of a uniform random number chosen
from the range -1 to +1. Clients with clocks that provide resolution
granularity of less than one second may choose a non-integer
randomization value. The delay before the next retransmission SHOULD
be 8 seconds randomized by the value of a uniform number chosen from
the range -1 to +1. The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds. The client
MAY provide an indication of retransmission attempts to the user as
an indication of the progress of the configuration process.

Sechorda · May 26, 2025, 6:49pm

What's with you and shouting at trees? Diagnostics and resolutions may come from any layer of abstraction and many different angles... Almost everything in computing is a multi-client or client/server architecture... Hardly any networking communication is in isolation - I just needed to vent because you said the same thing on my post lol.

Arthur1 · May 26, 2025, 7:18pm

brada4, my computer's system log has many disconnection messages that seem to be about connecting to my phone over wi-fi. There is nothing about DHCP. I do not see any correlation between the messages in the computer's log and the messages in the OpenWrt log. The time stamps are not correlated.

(By the way, the saying is about "barking up the wrong tree". )

In any case, I am grateful for any attempt to help. Thanks, brada4!

reinerotto · May 26, 2025, 8:09pm

Yes. Your config looks reasonable. Thus, need to eliminate potential issues, and check, whether problem still exists.
What about the logs from your router ?

Arthur1 · May 26, 2025, 9:43pm

OK. Back to 802.11n.

I shared logs in my first post and said that I would have to monitor for the kind of entries that you asked about. Are you interested in something specific right now?

reinerotto · May 27, 2025, 5:08am

No. Sorry asking, I did not really catch it.
According to the logs provided, it looks like, the disconnects are initiated by the client. But that could be consequence, not reason of a problem.
Now, when using HT20, is connection stable ? ANd which type of client/OS do you have ? Because it is strange, that client does not honor the 12h lifetime of IP assigned.

Arthur1 · May 27, 2025, 4:29pm

The client is a Macintosh running the current macOS, 15.5.

I discovered one problem: I had changed the channels on the router but didn't think to change it on the "dumb" access point. So I changed the channels on the "dumb" AP this morning. Using the principle of "change only one thing at a time", I also reverted to 802.11ax (HE20 and HE80) to see if the change in channels made a difference.

What I have noticed so far is that the DHCP events continue periodically even when the computer is asleep:

Tue May 27 09:50:00 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [redacted MAC]
Tue May 27 09:50:00 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [redacted MAC] iMac
Tue May 27 09:50:00 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [redacted MAC]
Tue May 27 09:50:00 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [redacted MAC] iMac
Tue May 27 10:20:51 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [redacted MAC]
Tue May 27 10:20:51 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [redacted MAC] iMac
Tue May 27 10:20:51 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.100 [redacted MAC]
Tue May 27 10:20:51 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.100 [redacted MAC] iMac

Why are DHCPREQUESTs and DHCPACKs happening while the computer is asleep? Is that normal or does it indicate a problem?

Why are DHCPREQUESTs happening when a lease is still active?

So far, I am not seeing disassociations.

I am also not seeing strange log entries while the computer is awake and in use, which I reported in my original post.

I have now switched back to 802.11n (HT20, HT20) and will monitor.

brada4 · May 27, 2025, 4:52pm

Maybe sort this out with your computers suppliers. dhcp requests are not initiated by OpenWrt in any way.

Arthur1 · May 27, 2025, 5:05pm

Thank you, brada4. I'll investigate more on the computer side.

psherman · May 27, 2025, 5:07pm

This would be entirely expected. When the computer is sleeping, it will periodically wake up to run various processes including network activity (checking for notifications, etc. this actually happens quite frequently but still at very low power (minimizing battery impact) and it still seems like the system is asleep at a human level.

When the system wakes up for any network access, it will attach to the network again and it must verify that the lease is still valid (even though it knows it should be based on the lease duration, there is no guarantee that it is truly attaching to the same network (for example, you use it at Starbucks, then go to another Starbucks - same ssid, different local network).

Bingo · May 27, 2025, 6:03pm

My AppleTV is even more aggressive with DHCP, when it is sleeping

It requests every 12 sec.

May 25 02:02:06 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:02:06 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:02:18 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:02:18 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:02:30 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:02:30 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:02:42 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:02:42 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:02:54 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:02:54 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:03:06 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:03:06 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:03:18 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:03:18 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:03:30 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:03:30 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:03:42 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:03:42 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:03:54 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:03:54 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:04:06 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11
May 25 02:04:06 debian02 dhcpd[29231]: Added reverse map from 11.30.217.10.in-addr.arpa. to atv04.
May 25 02:04:18 debian02 dhcpd[29231]: Added new forward map from atv04. to 10.217.30.11

When it's powered on , it follows the lease/half-lease times.

MY pi-hole suggests it's not just the OS, but also any apps that hasn't been closed, that makes "Callbacks" to the Mothership.

Edit: This is on ATV via Ethernet cable

Arthur1 · May 27, 2025, 6:25pm

I suspected that. I appreciate your confirmation. Thanks, Peter.

Thanks for the information, Bingo. The DHCP events on my sleeping, ethernet-connected Apple TV are hours apart. I don't know what's happening with the forward and reverse maps in your system.