OpenWrt allocating IP addresses beyond my DHCP range

Hi everyone,

I am having an issue where my router is allocating IP addresses beyond my DHCP range. I have set the start at 10 and the limit at 40, which should assign IPs between 192.168.1.10 and 192.168.1.50, but my devices (all of them except the ones with static leases) are getting IPs above .100.

How do I fix this issue?

Here is my /etc/config/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 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'
        list dns '1.1.1.1'
        list dns '1.0.0.1'
        list dns '2606:4700:4700::64'
        list dns '2606:4700:4700::6400'

config interface 'wan'
        option proto 'dhcp'
        option peerdns '0'
        list dns '1.1.1.1'
        list dns '1.0.0.1'
        option device 'wan'

config interface 'wan6'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option peerdns '0'
        list dns '2606:4700:4700::64'
        list dns '2606:4700:4700::6400'
        option device 'wan

.118 and .120 are static leases.

We need more info:

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:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/dhcp

Here are the info:

ubus call system board -

{
        "kernel": "5.15.150",
        "hostname": "OpenWrt",
        "system": "MediaTek MT7621 ver:1 eco:3",
        "model": "D-Link DIR-2640 A1",
        "board_name": "dlink,dir-2640-a1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.3",
                "revision": "r23809-234f1a2efa",
                "target": "ramips/mt7621",
                "description": "OpenWrt 23.05.3 r23809-234f1a2efa"
        }
}

cat /etc/config/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'
        option sequential_ip '1'
        option nonegcache '1'
        option allservers '1'
        list address '/'<redacted>.lan/192.168.1.12'
        list address '/'<redacted>.lan/192.168.1.114'
        list address '/.'<redacted>.lan/192.168.1.114'

config dhcp 'lan'
        option interface 'lan'
        option start '10'
        option limit '40'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'relay'
        option ra 'relay'
        option force '1'
        option ndp 'relay'

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'

config dhcp 'wan6'
        option interface 'wan6'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'
        option master '1'

config host
        option ip '192.168.1.118'
        option name 'tapocamerafront'
        list mac ''<redacted>'

config host
        option ip '192.168.1.120'
        option name 'tapocameraoutdoor'
        list mac '<redacted>'

Have you restarted the router since you made the changes? Importantly, the client devices must be forced to renew their lease -- this will only happen when the DHCP lease expires or if the client's connection is bounced (ethernet/wifi disconnected and then reconnected), or if the client device has a "renew DHCP lease" option within it's OS.

My router reboots everyday at 3 AM, Which was about 5.5 Hrs ago.

I can set the DHCP lease to 2 minutes? To see If it renews?

This behavior has been happening for all my devices, IoT, phones, computers - all of them getting ips beyond .100 .

One observation I have made that - If I change my DHCP server settings to make the start to 100, and limit 150. The hostnames of the devices connected to the WiFi shows up.

Why?? This is not recommended.

No. Because you still need to wait for the 12h lease to expire.

Try this:

/etc/init.d/odhcpd restart
logread -e odhcpd

Then, reboot a client device (for example a phone or computer), and check the subsequent IP address. If it's not in the expected range, do the logread command again.

I thought It helps, I won't do it then. Sometimes a simple reboot fixes issues, so I thought why not everyday.

I did restart odhcpd, and forget wifi on my android phone and rebooted the phone and connected to wifi again.

but It's still giving my phone 192.168.1.122 and for a very short duration in the "Wireless" section of openwrt I saw my phone get 192.168.1.11 and then shortly afterwards It was changed to 192.168.1.122 .

Here's the output of logread -e odhcpd -

Tue May 28 07:11:41 2024 daemon.err odhcpd[1784]: Failed to send to 2409:aaaa:f1:bbbb:cccc:dddd:eeee:ffff%wan6@wan (Bad file descriptor)
Tue May 28 07:11:41 2024 daemon.err odhcpd[1784]: Failed to send to 2409:aaaa:f1:bbbb:cccc:dddd:eeee:ffff%wan6@wan (Bad file descriptor)

OpenWrt is generally very stable and shouldn't need reboots very frequently, if at all. If you are having problems that crop up, rebooting is a band-aid, not a proper fix. In that situation, we can help you figure out what is actually wrong and solve it correctly.

Try deleting this:

Then try restarting the following two services and do the reboot of your phone again:

/etc/init.d/dnsmasq restart
/etc/init.d/odhcpd restart

I deleted the config dhcp 'wan6'
then restarted dnsmasq and odhcpd
then forget wifi and rebooted my phone
connected to wifi and got the same ip (192.168.1.123)

I got another phone to do the same, this second phone got 192.168.1.125 .

is it at all possible that you could have another DHCP server on the network?

logread -e udhcpc
logread -e odhcpd

I don't think so, I have my ISP router that OpenWrt is connected to as a client

logread -e udhcpc output -

Tue May 28 07:09:53 2024 daemon.notice netifd: wan (14387): udhcpc: started, v1.36.1       
Tue May 28 07:09:53 2024 daemon.notice netifd: wan (14387): udhcpc: broadcasting discover  
Tue May 28 07:09:57 2024 daemon.notice netifd: wan (14387): udhcpc: broadcasting discover  
Tue May 28 07:10:00 2024 daemon.notice netifd: wan (14387): udhcpc: broadcasting discover  
Tue May 28 07:10:00 2024 daemon.notice netifd: wan (14387): udhcpc: received SIGTERM       
Tue May 28 07:10:00 2024 daemon.notice netifd: wan (14387): udhcpc: entering released state
Tue May 28 07:10:24 2024 daemon.notice netifd: wan (14817): udhcpc: started, v1.36.1
Tue May 28 07:10:24 2024 daemon.notice netifd: wan (14817): udhcpc: broadcasting discover
Tue May 28 07:10:27 2024 daemon.notice netifd: wan (14817): udhcpc: broadcasting discover
Tue May 28 07:10:27 2024 daemon.notice netifd: wan (14817): udhcpc: broadcasting select for 192.168.31.13, server 192.168.31.1
Tue May 28 07:10:27 2024 daemon.notice netifd: wan (14817): udhcpc: lease of 192.168.31.13 obtained from 192.168.31.1, lease time 86400
Tue May 28 07:11:40 2024 daemon.notice netifd: wan (14817): udhcpc: received SIGTERM
Tue May 28 07:11:40 2024 daemon.notice netifd: wan (14817): udhcpc: unicasting a release of 192.168.31.13 to 192.168.31.1
Tue May 28 07:11:40 2024 daemon.notice netifd: wan (14817): udhcpc: sending release
Tue May 28 07:11:40 2024 daemon.notice netifd: wan (14817): udhcpc: entering released state
Tue May 28 07:11:49 2024 daemon.notice netifd: wan (16376): udhcpc: started, v1.36.1
Tue May 28 07:11:49 2024 daemon.notice netifd: wan (16376): udhcpc: broadcasting discover
Tue May 28 07:11:51 2024 daemon.notice netifd: wan (16376): udhcpc: broadcasting discover
Tue May 28 07:11:54 2024 daemon.notice netifd: wan (16376): udhcpc: broadcasting discover
Tue May 28 07:11:56 2024 daemon.notice netifd: wan (16376): udhcpc: received SIGTERM
Tue May 28 07:11:56 2024 daemon.notice netifd: wan (16376): udhcpc: entering released state
Tue May 28 07:12:20 2024 daemon.notice netifd: wan (16841): udhcpc: started, v1.36.1
Tue May 28 07:12:20 2024 daemon.notice netifd: wan (16841): udhcpc: broadcasting discover
Tue May 28 07:12:22 2024 daemon.notice netifd: wan (16841): udhcpc: broadcasting discover
Tue May 28 07:12:26 2024 daemon.notice netifd: wan (16841): udhcpc: broadcasting discover
Tue May 28 07:12:26 2024 daemon.notice netifd: wan (16841): udhcpc: broadcasting select for 192.168.31.13, server 192.168.31.1
Tue May 28 07:12:26 2024 daemon.notice netifd: wan (16841): udhcpc: lease of 192.168.31.13 obtained from 192.168.31.1, lease time 86400

logread -e odhcpd output -

Tue May 28 07:11:41 2024 daemon.err odhcpd[1784]: Failed to send to 2409:aaaa:f1:bbbb:cccc:dddd:eeee:ffff%wan6@wan (Bad file descriptor)
Tue May 28 07:11:41 2024 daemon.err odhcpd[1784]: Failed to send to 2409:aaaa:f1:bbbb:cccc:dddd:eeee:ffff%wan6@wan (Bad file descriptor)
1 Like

Remove the force line, then try restarting dnsmasq and check the output of the log.

I removed force option, restarted the openwrt services and forget wifi -> reboot phones -> try to connect again but same story.

and what does the log show

logread -e udhcpc

It outputs -

Tue May 28 10:12:37 2024 daemon.notice netifd: wan (2976): udhcpc: started, v1.36.1
Tue May 28 10:12:38 2024 daemon.notice netifd: wan (2976): udhcpc: broadcasting discover
Tue May 28 10:12:41 2024 daemon.notice netifd: wan (2976): udhcpc: broadcasting discover
Tue May 28 10:12:41 2024 daemon.notice netifd: wan (2976): udhcpc: broadcasting select for 192.168.31.13, server 192.168.31.1
Tue May 28 10:12:41 2024 daemon.notice netifd: wan (2976): udhcpc: lease of 192.168.31.13 obtained from 192.168.31.1, lease time 86400

I did network capture on port 67 and 68 using Wireshark, and renewed my computer's ip using ipconfig /release and ipconfig /renew and the requests went to 192.168.1.1 .

Thus I think there are no rogue dhcp servers.

Try removing this and then restart the dnsmasq service (again) and test (again).

Oops!

I have found the issue,

I disabled dhcp on openwrt (Ignore interface), and rebooted the router and phones.

I should not be able to get an ip since dhcp is disabled on openwrt.

But I still got an ip, It turns out a TP-LINK router I have connected as a client, Is giving out these .100 > ips. I can confirm this now, that there was no issue with OpenWrt, I also saw the TP-LINK in Wireshark logs (that caught my attention).

The TP-LINK router I connected as a client has conflicting subnet with my OpenWrt router that may be the reason.

But I wonder why did force option in OpenWrt not work.

Thank you @psherman for all the help.

That's why I asked about a rogue DHCP server!
Glad you found it.

When there are multiple DHCP servers on a network, it becomes a race condition and non-deterministic.

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.