I have a fairly simple setup where I have the Turris Omnia (@TOS 5.0.1) configured as a “dumb AP” along with another AP to cover a different part of the house. Both, along with my DHCP server, are attached to a managed switch (Cisco SG300). Every time my phone roams/reassociates from the other AP to the TO AP, it will be unable to receive a DHCP lease for a few minutes (stuck in “Obtaining IP address”). I have verified in these scenarios that:
- The DHCP server is seeing the requests and responding.
- The switch port the TO is attached to is seeing both the DHCP requests and replies (by way of port monitoring/mirroring).
- The bridge interface on the TO (br-lan) is seeing only the DHCP requests.
So that means that the DHCP replies are getting lost somewhere between the external switch and the bridge interface on the TO, which pretty much just leaves the TO’s internal switch. My wild guess is that the TO’s internal switch or the associated DSA-backed Linux bridge is doing some MAC learning/filtering and is letting the DHCP request through as it has a broadcast MAC target, but blocking the targeted reply as it thinks that MAC lives elsewhere until its entry times out after a few minutes.
(This is potentially similar to TO in dumb AP mode does not relay DHCP to WLAN clients)