Hi,
My openwrt device is configured as dumb access point where one of its ports carries tagged vlan traffic from a upstream router running dhcp. One of the openwrt device's radio (2.4ghz) is configured with one of the vlans. Pretty standard so far?
My issue is that my IoT devices take many many many tries to connect to this 2.4ghz SSID. Looking at the dhcp logs on the upstream router, I see the dhcp dance is constantly bouncing between discover and offer. I inferred this to mean that somehow the dhcp offer is not reaching the IoT device.
In an attempt to debug, I ssh'd and ran tcpdump in openwrt to see what was going on. However, it seems that running tcpdump completely fixes the issue. I see the dhcp discover, offer, request, and ack all in quick succession, and the IoT device is connected there after.
Without tcpdump, it seems the dhcp dance keeps timing out, but somehow it works once every 10 tries. Anyone have a clue what's going on?
root@OpenWrt:~# ubus call system board
{
"kernel": "6.6.86",
"hostname": "OpenWrt",
"system": "ARMv8 Processor rev 4",
"model": "Linksys MX8500",
"board_name": "linksys,mx8500",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.1",
"revision": "r28597-0425664679",
"target": "qualcommax/ipq807x",
"description": "OpenWrt 24.10.1 r28597-0425664679",
"builddate": "1744562312"
}
}
Let’s see the rest of the config.
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:
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
Thanks for the instruction. Here you go:
root@OpenWrt:~# cat /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 ula_prefix 'fd8e:4467:6d77::/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 'wan'
option igmp_snooping '1'
config device
option name 'lan1'
option macaddr 'redacted'
config device
option name 'lan2'
option macaddr 'redacted4'
config device
option name 'lan3'
option macaddr 'redacted'
config device
option name 'lan4'
option macaddr 'redacted'
config interface 'lan'
option device 'br-lan.10'
option proto 'dhcp'
config device
option name 'wan'
option macaddr 'redacted'
option ipv6 '0'
config bridge-vlan
option device 'br-lan'
option vlan '10'
list ports 'lan1'
list ports 'wan:t'
config bridge-vlan
option device 'br-lan'
option vlan '20'
list ports 'lan2'
list ports 'wan:t'
config interface 'vlan20'
option proto 'none'
option device 'br-lan.20'
config bridge-vlan
option device 'br-lan'
option vlan '30'
list ports 'lan3'
list ports 'lan4'
list ports 'wan:t'
config interface 'vlan30'
option proto 'none'
option device 'br-lan.30'
config interface 'vlan10'
option proto 'none'
option device 'br-lan.10'
root@OpenWrt:~# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc@0/c000000.wifi'
option band '5g'
option channel '64'
option htmode 'HE80'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'vlan20'
option mode 'ap'
option ssid 'Guest'
option encryption 'sae-mixed'
option key 'redacted'
option ocv '0'
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc@0/c000000.wifi+1'
option band '2g'
option channel '6'
option htmode 'HE20'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'vlan30'
option mode 'ap'
option ssid 'IoT'
option encryption 'sae-mixed'
option key 'redacted'
option ieee80211w '0'
option multicast_to_unicast_all '1'
config wifi-device 'radio2'
option type 'mac80211'
option path 'soc@0/20000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option band '6g'
option channel '37'
option htmode 'HE80'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio2'
option device 'radio2'
option network 'vlan10'
option mode 'ap'
option ssid '6G'
option encryption 'sae'
option key 'redacted'
option ocv '0'
root@OpenWrt:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option cachesize '1000'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
option ednspacket_max '1232'
option filter_aaaa '0'
option filter_a '0'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
root@OpenWrt:~# cat /etc/config/firewall
config defaults
option syn_flood '1'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'vlan20'
list network 'vlan30'
list network 'vlan10'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
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'
root@OpenWrt:~#
Remove IGMP snooping:
Delete this (you already have the lan network interface associated with br-lan.10):
Don't use sae-mixed -- it causes problems with some client devices. Instead, select either WPA2 (psk2) or WPA3 (sae). Also, remove the acv line.
Same thing here re sae-mixed but also remove the last 2 lines:
And remove the ocv ;our jryr"
remove the additional networks (vlan20, vlan30, vlan10). The only thing that should be here is lan:
Reboot after those changes and test again.
I made those changes, but the issue still persists. I realize now that I'm having trouble connecting to the Guest network as well, even with my laptop. For some reason my iPhone is able to connect to either Guest or IoT and receive a lease just fine.
Maybe there is an issue with something upstream of your Openwrt ap, or maybe it is actually the laptop that is having issues.
Please test with other devices (in other words, you’ve used your laptop and your phone - test with more client devices) to see if the laptop is the only one that has the issue.
Ok I tried tcpdump again and it doesn't seem to fix it anymore. I see the client sends out 5 dhcp discovers before giving up.
On the upstream router side (opnsense), i see both dhcp discover and dhcp offer, so I guess the problem is somehow the offers not reaching the openwrt router.
What I'm actually doing in these cases is taking a device that was previously connected to a different downstream router (tplink in access point mode) and now trying to connect to the openwrt router. My theory is that the upstream opnsense router is somehow confused and not sending the offer packet to the correct downstream router. Need to look into this more...
I'm guessing the reason it works with my iPhones is because they use randomized MACs...
One thing to consider is moving from HE20 to HT20 on the 2.4 network, just to see if that helps setting down the IoT devices...
Turns out the problem is not limited to 2.4ghz radio. I have another SSID on 5ghz radio and also facing similar problems when I try to connect with a device with a stable MAC address.
The thing that confuses me most is that it will connect after several tries, which leads me to believe some cache expires and now the packet is getting through.
I think it's time to start looking at the upstream.
Is the AP directly connected to the router, or is there a switch in between? If there is a switch, have you made sure that it is configured properly?
And how did you verify that your router is properly configured?
I'll try to describe my set up in more detail.
Upstream is my opnsense router virtualized in my proxmox machine with 3 ports. 1st port connects further upstream to ISP modem. 2nd port goes downstream to a dumb TP-link access point. 3rd port goes downstream to a dumb OpenWRT access point.
I have 3 VLANs 10, 20, and 30 configured in opnsense. I've set it up so the 2nd port is an access port for VLAN 10 (since I can't configure VLANs on this tp-link device), and the 3rd port is a trunk port carrying tagged VLAN traffic for 10, 20 and 30 going to my openwrt device as per my configuration several posts above.
If I take a client that is currently connected to vlan 10 on a ssid broadcasted by the tplink device, and then I try to connect to vlan 20 (or 30) on a ssid broadcasted by the openwrt device, I find that it takes many many tries before it receives a dhcp lease. What is also weird is that this does not happen in reverse, i.e. if a device is currently connected to openwrt ssid and I switch to the tplink ssid, no issues here.
Using tcpdump, I verified that:
- on port 3 (connected to opnsense), I see incoming dhcp discovers and outgoing dhcp offers.
- on the wan port in openwrt, I see discovers but no offers initially. Then suddenly, offer comes and then subsequently the dhcp request and ack.
Things I need to try:
- try connect to ssid on openwrt but with the same VLAN 10.
- Reinstall openwrt.
- Configure pci pass through for port #3 into opnsense.
Sorry but I hope this makes it more clear what I'm dealing with 
Virtualized routers are really hard to get working properly and consistently, especial when working with multiple ethernet ports and VLANs.
I'd recommend backing up your configuration and then running it bare-metal. I will wager that a bare metal installation of OPNSense will fix the problem. Or, conversely, you could use OpenWrt. Really, it doesn't matter, just do bare metal. You may even be able to do this completely non-invasively by using USB stick/SD card "live" boot medium. Simply boot into a bare-metal OS and run off the USB stick... you don't have to disturb your existing installation at all.
Thanks for the link. It is close but not my issue. My udp checksums are ok.
I think I found my issue! It seems that the issue is caused by stale fdb entries. When I try to connect initially, there are two entries.
root@OpenWrt:~# /usr/sbin/bridge fdb show br br-lan | grep "<my-mac-address>"
<my-mac-address> dev lan4 vlan 10 master br-lan
<my-mac-address> dev phy0-ap0 vlan 20 master br-lan
If I do nothing the client will finally get a dhcp lease after ~3 minutes. I'm guessing there's some kind of time out here for fdb entries.
If I run bridge fdb del <my-mac-address> dev lan4 vlan 10 master to remove the stale entry, DHCP DORA completes shortly after.
It is similar to this github issue. The init script in there fixed my issue.
Can any expert confirm my findings?
The OpenWrt switch/AP should be essentially transparent. I am quite certain the problem is upstream.
You can test my hypothesis easily, as I described above, by simply running the router bare-metal. Or, if you happen to have another device like an all-in-one router that can run OpenWrt, you can temporarily put that upstream of your AP (instead of your virtualized router).
How would you explain my workaround? It makes sense that a stale entry would confuse the bridge and cause dhcp response packets to be mis-routed. I also wouldn't expect openwrt to automatically know a fdb entry is stale since that knowledge would have to come from upstream.
I'll try this later, but I would guess that my problem would also be solved if I put my openwrt device on vlan 20 so that it never learns the first fdb entry in the first place.
I'm certain the issue isn't upstream...because I clearly see the dhcp response packets in the right place.
I can't honestly explain it, but I think it is a red-herring.
I've seen enough of these situations to say that it is likely that the problem is actually upstream. As such, I think you should prove that by running the router bare metal (ideally OpenWrt, actually, since we can verify that config) and testing... if the problem still persists, that will prove me wrong and prove you right. And I'm okay with that, because the key thing is that we want to rule out the potential sources of the problem.
I remain reasonably confident that the AP/switch is not the problem because it is nominally transparent and is not running DHCP. It should not interfere with DHCP either. But we do need to have a test with a bare-metal upstream to know one way or the other.
That's fair. I'll leave that experiment for another day I'll accept my workaround as the solution for now. Thank you for your help!