I've recently changed out my main router and access point for an OpenWRT capable device and so far I'm pretty happy with the setup.
However, while tinkering with some IoT devices(ESP8266) I noticed that my devices take much longer to receive an IP address than what it used to be when my main router was still the one supplied by my ISP. And I suspect it's DHCP related... When I assign a static IP to my device(ESP), establishing a connection takes about 4 seconds. When I let the DHCP do it's job it takes 17 seconds to connect and receive an IP. I suppose something is creating a delay somewhere but I have no clue what it could be. I noticed that the PC's(wired and wireless) around my network take some time(+10seconds) as well when I try to renew the IP. I'm not aware of any conflicting DHCP server that could be interfering. I did setup a second subnet with it's own DHCP server but disabled this for testing. This made no difference. What could be causing this and what would be a suitable solution?
Create a separate WIFI SSID for IOT devices instead of sharing it with PC and mobile phone. Reduce bandwidth and encryption methods. Run in WIFI5 mode. Can enhance signal coverage and compatibility.
Another way is to manually set the IPs of these IOT devices on the DHCP route, which can obtain IPs faster. This makes it easier to obtain IPs faster without conflict. Secondly, it makes it easier to manage the equipment.
Can we see the /etc/config/dhcp file?
Also let's verify the response times.
opkg update; opkg install tcpdump; tcpdump -i br-lan -vnn udp port 67
Stop it with Ctrl-c
OK, here is the DHCP config of the NanoPI(Main router with 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 '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option localservice '1'
option ednspacket_max '1232'
option port '54'
option noresolv '1'
option logdhcp '1'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '99'
option leasetime '12h'
option dhcpv4 'server'
option ra 'server'
list ra_flags 'managed-config'
list ra_flags 'other-config'
list dhcp_option '3,192.168.0.1'
list dhcp_option '6,192.168.0.1'
list dhcp_option '15,lan'
option dhcpv6 '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'
And here the DHCP config of the Flint2:
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 readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option localservice '1'
option ednspacket_max '1232'
list server '192.168.0.1'
config dhcp 'lan'
option interface 'lan'
option start '240'
option limit '10'
option leasetime '12h'
option dhcpv4 'server'
option dhcpv6 'server'
option ra 'server'
list ra_flags 'managed-config'
list ra_flags 'other-config'
option dns_service '0'
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 'lan_noinet'
option interface 'lan_noinet'
option start '100'
option limit '150'
option leasetime '12h'
The DNS is managed by AdGuard Home installed on the NanoPi, hence port 54 in the NanoPi for the DNS. The "lan_noinet" interface on the Flint2 is disabled for the moment to figure things out with the DHCP. The "lan_noinet" interface is in a different subnet normally and has it's own DHCP server.
The log from TCPdump on the NanoPi:
tcpdump: listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:21:52.313097 IP (tos 0x0, ttl 255, id 1, offset 0, flags [none], proto UDP (17), length 336)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:fe:34:fe:75:fa, length 308, xid 0x788023d8, Flags [none]
Client-Ethernet-Address 18:fe:34:fe:75:fa
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 1500
Parameter-Request (55), length 5:
Subnet-Mask (1), Default-Gateway (3), BR (28), Domain-Name-Server (6)
NTP (42)
Client-ID (61), length 7: ether 18:fe:34:fe:75:fa
Hostname (12), length 10: "ESP-FE75FA"
21:21:55.327201 IP (tos 0xc0, ttl 64, id 26057, offset 0, flags [none], proto UDP (17), length 328)
192.168.0.1.67 > 192.168.0.163.68: BOOTP/DHCP, Reply, length 300, xid 0x788023d8, Flags [none]
Your-IP 192.168.0.163
Server-IP 192.168.0.1
Client-Ethernet-Address 18:fe:34:fe:75:fa
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Server-ID (54), length 4: 192.168.0.1
Lease-Time (51), length 4: 43200
RN (58), length 4: 21600
RB (59), length 4: 37800
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 192.168.0.255
Domain-Name-Server (6), length 4: 192.168.0.1
Default-Gateway (3), length 4: 192.168.0.1
21:21:55.330372 IP (tos 0x0, ttl 255, id 2, offset 0, flags [none], proto UDP (17), length 336)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:fe:34:fe:75:fa, length 308, xid 0x788023d8, Flags [none]
Client-Ethernet-Address 18:fe:34:fe:75:fa
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Request
MSZ (57), length 2: 1500
Requested-IP (50), length 4: 192.168.0.163
Server-ID (54), length 4: 192.168.0.1
Parameter-Request (55), length 5:
Subnet-Mask (1), Default-Gateway (3), BR (28), Domain-Name-Server (6)
NTP (42)
Hostname (12), length 10: "ESP-FE75FA"
Client-ID (61), length 7: ether 18:fe:34:fe:75:fa
21:21:55.338817 IP (tos 0xc0, ttl 64, id 26058, offset 0, flags [none], proto UDP (17), length 328)
192.168.0.1.67 > 192.168.0.163.68: BOOTP/DHCP, Reply, length 300, xid 0x788023d8, Flags [none]
Your-IP 192.168.0.163
Server-IP 192.168.0.1
Client-Ethernet-Address 18:fe:34:fe:75:fa
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Server-ID (54), length 4: 192.168.0.1
Lease-Time (51), length 4: 43200
RN (58), length 4: 21600
RB (59), length 4: 37800
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 192.168.0.255
Domain-Name-Server (6), length 4: 192.168.0.1
Default-Gateway (3), length 4: 192.168.0.1
21:22:25.011446 IP (tos 0x0, ttl 255, id 5, offset 0, flags [none], proto UDP (17), length 336)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:fe:34:fe:75:fa, length 308, xid 0xef2a2da4, Flags [none]
Client-Ethernet-Address 18:fe:34:fe:75:fa
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 1500
Parameter-Request (55), length 5:
Subnet-Mask (1), Default-Gateway (3), BR (28), Domain-Name-Server (6)
NTP (42)
Client-ID (61), length 7: ether 18:fe:34:fe:75:fa
Hostname (12), length 10: "ESP-FE75FA"
21:22:25.016195 IP (tos 0xc0, ttl 64, id 28114, offset 0, flags [none], proto UDP (17), length 328)
192.168.0.1.67 > 192.168.0.163.68: BOOTP/DHCP, Reply, length 300, xid 0xef2a2da4, Flags [none]
Your-IP 192.168.0.163
Server-IP 192.168.0.1
Client-Ethernet-Address 18:fe:34:fe:75:fa
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Server-ID (54), length 4: 192.168.0.1
Lease-Time (51), length 4: 43200
RN (58), length 4: 21600
RB (59), length 4: 37800
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 192.168.0.255
Domain-Name-Server (6), length 4: 192.168.0.1
Default-Gateway (3), length 4: 192.168.0.1
21:22:25.021958 IP (tos 0x0, ttl 255, id 6, offset 0, flags [none], proto UDP (17), length 336)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:fe:34:fe:75:fa, length 308, xid 0xef2a2da4, Flags [none]
Client-Ethernet-Address 18:fe:34:fe:75:fa
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Request
MSZ (57), length 2: 1500
Requested-IP (50), length 4: 192.168.0.163
Server-ID (54), length 4: 192.168.0.1
Parameter-Request (55), length 5:
Subnet-Mask (1), Default-Gateway (3), BR (28), Domain-Name-Server (6)
NTP (42)
Hostname (12), length 10: "ESP-FE75FA"
Client-ID (61), length 7: ether 18:fe:34:fe:75:fa
21:22:25.029726 IP (tos 0xc0, ttl 64, id 28115, offset 0, flags [none], proto UDP (17), length 328)
192.168.0.1.67 > 192.168.0.163.68: BOOTP/DHCP, Reply, length 300, xid 0xef2a2da4, Flags [none]
Your-IP 192.168.0.163
Server-IP 192.168.0.1
Client-Ethernet-Address 18:fe:34:fe:75:fa
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Server-ID (54), length 4: 192.168.0.1
Lease-Time (51), length 4: 43200
RN (58), length 4: 21600
RB (59), length 4: 37800
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 192.168.0.255
Domain-Name-Server (6), length 4: 192.168.0.1
Default-Gateway (3), length 4: 192.168.0.1
8 packets captured
8 packets received by filter
0 packets dropped by kernel
I connected my device 2 times as you can see from the log. The timestamps look normal and quite fast actually... So this means something else is going on?
Are you saying that there's two DHCP servers in your network?
The DHCP is disabled on the Flint 2:
option ignore '1'
The only other DHCP that is normally active is on the now disabled "lan_noinet" interface(On the Flint2) and is operating in a different subnet.
This 3 sec delay between Discover and Offer is kinda expected, as the dhcp server is monitoring for responses from other dhcp servers. You can force it to act like single dhcp server with:
uci add dhcp.lan.force='1'
uci commit dhcp
service dnsmasq restart
Other than that the response times are normal.
OK, it's not the DHCP...
I re-installed my "old" Netgear R7000 Nighthawk in AP mode with original factory firmware and had it join the network(Parallel with the Flint2) with static IP 192.168.0.4
It's configured with DHCP disabled and has it's own Wifi network with different SSID. The response (or connection) time is back the way it was before (3sec only)... So clearly it has something to do with the Flint2... So what could it be?
I tried separating the 2.4Ghz and 5Ghz networks by giving each a different SSID, no change...
I tried changing the Wifi security settings, no change...
I tried legacy mode, no change...
Also... I'm having strange problems with my Bambulab P1P 3D printers since I changed my network and installed the Flint2. They sometimes get disconnected from the Wifi and show IP 0.0.0.0
When I try to re-connect them they don't "see" the network, as in the SSID is invisible. Other devices, like my phone, can see the network just fine although this could be the 5Ghz band, not sure there. Only a restart from the Flint2 solves the problem.
The P1P printers are ESP32 based, so 2.4Ghz only. Could there be something related? Any known incompatibility between the Flint2 hardware and ESP devices?
The option option rapidcommit '1' for your DNSMasq improves response times as well.
So I tried upgrading to 24.10.0 and reverting to Factory defaults. Then I reconfigured to have the wifi online, no change... Still a significant delay getting an IP.
Then I tried reverting to stock firmware, which is basically OpenWRT 21.02
This solved the problem, connecting to Wifi takes about 3 seconds, like it should.
Then I tried re-installing the first possible OpenWRT release for this device, which is 23.05.3
Again the problem re-appeared, 14 seconds to get a connection.
So I guess I'll be falling back to stock firmware unless someone has a clue what could be causing this phenomenon?
Another update...
It seems that it's Wifi security related. When I disable the security completely the connection time is 2.5 seconds, if I enable it +14 seconds.
I don't know why it suddenly worked on the stock firmware because I was not able to replicate it afterwards.
So now I'm back on OpenWRT 24.10.0
I'll try some more security variations to see what works best. In the mean time I got some logs that look "suspicious" while I was running the stock firmware:
Thu Feb 20 01:13:04 2025 kern.debug kernel: [ 702.721563] entrytb_aid_aquire(): found non-occupied aid:18, allocated from:4
Thu Feb 20 01:13:04 2025 kern.warn kernel: [ 702.728718] 7986@C13L2,MacTableInsertEntry() 1577: New Sta:xx:xx:xx:xx:xx:xx
Thu Feb 20 01:13:04 2025 kern.notice kernel: [ 702.737242] 7986@C08L3,ap_cmm_peer_assoc_req_action() 1714: Recv Assoc from STA - xx:xx:xx:xx:xx:xx
Thu Feb 20 01:13:04 2025 kern.notice kernel: [ 702.746523] 7986@C08L3,ap_cmm_peer_assoc_req_action() 2241: ASSOC Send ASSOC response (Status=0)...
Thu Feb 20 01:13:04 2025 kern.notice kernel: [ 702.755598] 7986@C01L3,wifi_sys_conn_act() 1115: wdev idx = 0
Thu Feb 20 01:13:04 2025 kern.notice kernel: [ 702.761595] 7986@C08L3,hw_ctrl_flow_v2_connt_act() 215: wdev_idx=0
Thu Feb 20 01:13:04 2025 kern.notice kernel: [ 702.891477] 7986@C15L3,WPABuildPairMsg1() 5310: <=== send Msg1 of 4-way
Thu Feb 20 01:13:04 2025 kern.notice kernel: [ 702.898128] 7986@C15L3,PeerPairMsg2Action() 6303: ===>Receive msg 2
Thu Feb 20 01:13:04 2025 kern.notice kernel: [ 702.904765] 7986@C15L3,WPABuildPairMsg3() 5595: <=== send Msg3 of 4-way
Thu Feb 20 01:13:04 2025 kern.notice kernel: [ 702.911396] 7986@C15L3,PeerPairMsg4Action() 6734: ===>Receive msg 4
Thu Feb 20 01:13:04 2025 kern.warn kernel: [ 702.922999] 7986@C15L2,PeerPairMsg4Action() 7098: AP SETKEYS DONE(ra0) - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=15 from xx:xx:xx:xx:xx:xx
Thu Feb 20 01:13:04 2025 kern.warn kernel: [ 702.922999]
Thu Feb 20 01:13:18 2025 kern.warn kernel: [ 716.961251] 7986@C08L2,ap_peer_disassoc_action() 3645: ASSOC - 1 receive DIS-ASSOC request
Thu Feb 20 01:13:18 2025 kern.warn kernel: [ 716.969591] 7986@C01L2,wifi_sys_disconn_act() 1002: wdev_idx=0
Thu Feb 20 01:13:18 2025 kern.notice kernel: [ 716.975809] 7986@C08L3,hw_ctrl_flow_v2_disconnt_act() 172: wdev_idx=0
Thu Feb 20 01:13:18 2025 kern.warn kernel: [ 716.982782] 7986@C13L2,MacTableDeleteEntry() 1938: Del Sta:xx:xx:xx:xx:xx:xx
Here the 14 seconds delay is clearly visible. Any ideas?
It looks to me that the client asked to be disconnected.
Yes, this is true. The connection is normally short but the time delay to establish the connection is quite significant I would say if I compare it to connecting with my Netgear R7000. Is there a way I could get more details from the logs? To see what exactly happens?
Disabling the security fixes everything but this is of course not an option. So I assume it has something to do with the way the security is handled in the Flint2?
This is a blind guess, but I had a few issues with wireless not being great, hard to quantify or explain really, but took a punt on removing any mbedtls packages and replacing them with the wolfssl equivalents. My wireless seems to be generally healthier now. I'm not skilled or committed enough to properly test and confirm if mbedtls was the issue, but if you're scratching your head on with your issues maybe worth checking what the stock flint 2 software includes?
Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have
ubus call system board; \
uci export network; uci export wireless
This is the output:
{
"kernel": "6.6.73",
"hostname": "OpenWrt",
"system": "ARMv8 Processor rev 4",
"model": "GL.iNet GL-MT6000",
"board_name": "glinet,gl-mt6000",
"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"
}
}
package 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 'fd7e:29e9:f015::/48'
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'
list ports 'lan5'
option ipv6 '0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.0.2'
option netmask '255.255.255.0'
option ip6assign '60'
option gateway '192.168.0.1'
list dns '192.168.0.1'
config interface 'wan'
option device 'eth1'
option proto 'dhcp'
option disabled '1'
config interface 'wan6'
option device 'eth1'
option proto 'dhcpv6'
option disabled '1'
option reqaddress 'try'
option reqprefix 'auto'
option norelease '1'
package wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc/18000000.wifi'
option band '2g'
option channel 'auto'
option htmode 'HE20'
option country 'BE'
option cell_density '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'BlueHome'
option encryption 'psk2+tkip+ccmp'
option key 'xxxxxxxx'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/18000000.wifi+1'
option band '5g'
option channel 'auto'
option htmode 'HE80'
option cell_density '0'
option country 'BE'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'BlueHome'
option encryption 'psk2+tkip+ccmp'
option key 'xxxxxxxxx'
Is there a way to see the whole detailed wifi connection process? In order to identify what is causing the delay? Since the problem goes away when I disable wifi security I suspect the delay is caused by (one of) the security modules. But how can I see this?
You could try to set fixed channels for your wifi radios. I usually check the best avalable channels with some wifi scanner in android phone. You can also check the channel availability with OpenWrt Channel Analysis.