Kit, liv and bed are espressobin wireless access points with Atheros QCA9888 chips each of which have their wan ports connected to the upstream switch infrastructure. None of the APs (kit,liv or bed) have dnsmasq or firewalls enabled, they are simply bridged with the uplinking ethernet port on each espressobin.
Router 10.0.1.1 (Running DHCP) ---> TP-LINK Switch (SG105E) ---> NETGEARMS510TX | |----> kit (Espressobin Openwrt 18.06.1) |----> liv (Espressobin Openwrt 18.06.1) |----> bed (Espressobin Openwrt 18.06.1)
Wireless clients connecting to any of the access points will obtain a dhcp lease almost immediately if they have not connected to any of the APs recently. If I roam, that is connect to the liv wifi after having been connected to the kti wifi network, DHCP Fails I can see the DHCPDISCOVER travel from the espressobin to the router, and the router sending a DHCPOFFER which travels via unicast through the tp-link, the netgear to the appropriate port on the netgear switch but then it disappears, it never appears on the ap uplink ethernet interface. I am positive that the unicast DHCPOFFER packet is being sent to the appropriate switch port, I have verified it by running wireshark on many switch ports simultaneously. Running tcpdump on each espressobin I do not see the these DHCPOFFER packets. However if I wait some time, say 5 minutes, the offer eventually appears and the wifi client gets an address. The packet also magically begins to appear in tcpdump on the espressobin which is acting as an ap for the wifi client at that particular time. In short, problem is associate with one ap, fine initially, move to another ap, DHCPOFFERS dropped by new ap for 5 minutes then inexplicably able to obtain ip and internet access.
I have also noticed that some arp packets are dropped by the espressobin during this process in the same fashion.
turning on proxy arp on ap ethernet interface-> I realize now this will have no effect because there is only a single subnet.
Completely working around the problem.. turning each ap into a nat firewall and creating a private subnet where the ethernet port perform ip masquerading this works fine, but not at all what I want.
Does anyone have any idea what could be causing this strange behavior?