I’m not surprised that our WiFi guru @bpwl did not trip over it, after all this setting has nothing to do with wireless per se. The wireless connection did establish for @OP, it’s wireless client which freaked out because it didn’t get IP address in timely fashion (due to reasons unrelated to wireless).
Indeed I did not relate the “disable-running-check” (http://forum.mikrotik.com/t/wlan-slave-down-when-wlan-master-disconnects-station-bridge/146242/1 ) to this DHCP problem series. It could have an influence however.
Nevertheless after quite some tests with Wireshark as a tool, this weird problem has many other influencing aspects . (http://forum.mikrotik.com/t/ros-6-38-serious-dhcp-server-problem/105259/1)
It’s time consuming, and the number of combinations is large. So I stopped experimenting, my overall consolidation of all experiments and cases in my head is … with pseudo bridge repeaters
1; MT DHCP server does always deliver a DHCP lease to the client. (State=offered). After a short timeout the DHCP sever does a check on the DHCP lease , and that fails (does not go to bound). Then the DHCP lease is withdrawn.
2. That check never reaches the client! So the client does not answer. Even if that check is send to broadcast IP 255.255.255.255, it does not reach the client. (DHCP server Is not using the MAC broadcast address FF:FF:FF…).
3. With pseudo bridge setups, the DHCP lease is correct for the MAC address of the client. Every client behind the pseudo bridge receives a different IP address. That IP address is in the DHCP lease table with the correct MAC address.
4. The IP address is in the ARP table with the MAC address of the pseudo bridge (as it should, and multiple IP addresses for one MAC is quite common)
5. The lease check is (probably, forgot to double check) sent to the MAC address of the client (should be with the MAC address op the pseudo bridge and IP address of the client)
6. The sending bridge plays a role as well. The DHCP check is not sent over the wifi. Is it preferring the ethernet path , due to some (R)STP or MAC table content ??? Don’t understand this part.
7. By using another DHCP server (like from Draytek Vigor) there is NO PROBLEM with the same MT wifi connection to the pseudo bridge (don’t they do that check ??? Or they do it correctly???).
8. Amazingly Draytek developers made a major implementation mistake a few years ago, by replacing the DHCP MAC table and the ARP MAC table, by a single user manageable merged MAC table. Is this a common misunderstanding in Linux?? They are for 99% identical in content, but not always. But it works for DHCP leases if not set as static entry (then it fails!).
9. Some pseudo bridge brand implementations respond well with proxy-arp to the packets with MAC addresses of the client in the destination. Even for MT DHCP server.
10. There are new settings in RouterOS, allowing more IP’s per MAC in the DHCP server. Impact on this problem not tested.
The number of combinations (DHCP server brand, place of that DHCP server (on bridge or upstream), bridge settings (MAC table content, port learn mode, (R)STP settings, version), wireless timing (interface up/down, (R)STP settled and interface state), pseudo bridge implementation and parameters, pseudo bridge settings … etc etc etc) , plus the fact that most of this is timing dependent, make it a very complex thing to analyze.
MT DHCP server on the bridge offers a DHCP lease correctly to every client behind the MT pseudo bridge (and other wifi-repeaters), but the check fails because that check never reaches the client. The reason for this is not found (as it even fails when in the bridge the MAC address NAT is used to change it to MAC broadcast). How can we suppress that check ???
Running DHCP server on Draytek is my common setup … .