1

I'm having problem that sometimes wireless clients doesn't receive IP from the DHCP server. The network map looks like this:

Network Map

All IP are static leases configured in hEX built-in DHCP server. I have the "always broadcast" option turned off, but it seems that it will turn on on its own. All LAN clients receive IP just fine.

The UniFi AP AC Lite is flashed with LEDE Reboot. However, the same problem also occurs to the original UniFi firmware. Sometimes even the UniFi itself doesn't response to DHCP, but if I run DHCP server on my own computer it works just fine. I suspect that Mikrotik's DHCP server is at fault here.

Also, I tried to run dnsmasq DHCP server on the Unifi and there is no DHCP problem.

I enabled port mirroring on the hEX, and ran Wireshark. It seems that the router did offered DHCP, but there are no response.

Wireshark

(please let me know if you need more details on packet capture)

Is there are anything I should check on both Mikrotik and the LEDE UniFi AP AC?

| improve this question | | | | |
3

I've solved the problem following the Mikrotik forum.

  • Disable STP on the bridge
  • Set bridge admin MAC to be the same as bridge's MAC
  • Make sure that DHCP server is listening on the bridge

I'm disappointed that Mikrotik doesn't seems to care to fix this properly, even in the latest 6.39 firmware.

| improve this answer | | | | |
2

I had this problem, appears to be a bug in the latest Mikrotik update, as described here:

There is a bug in the current RC releases which causes DHCP packets to be sent with an invalid source MAC...

You can also force the admin MAC on your bridge interface to be the same as the actual MAC - this seems to work around the issue. Mikrotik support are aware of the problem (and suggested the workaround)" - [tulluk]

. I rolled back to bugfix release and she's all good =D

| improve this answer | | | | |
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – Donald Duck Apr 27 '17 at 11:15
  • edited with source quote – phaseform Apr 29 '17 at 2:56
0

If the issue is with the UniFi AP only, and it happens regardless of the firmware on the UniFi device, it may be the configuration that you have on the UniFi.

If the UniFi AP is set up with multiple, non-bridged interfaces, make sure that the IP addresses assigned to the ports not connected to the hEX network do not have overlapping subnets. If so, it may be that the response from the UniFI's DHCP client's response to the DHCP server is using the wireless interface.

You could also check to see what options the DHCPDISCOVER from the UniFI is requesting - if the MikroTik DHCP server is not fulfilling required options, the UniFi could ignore the DHCPOFFER. This is not as likely since you're seeing this with both the UniFi firmware and the LEDE firmware.

You could post the wireshark details (fully expand the DHCP Protocol portion of the dissector display) for the DHCPDISCOVER and the DHCPOFFER if the problem persists after checking these.

| improve this answer | | | | |
  • The UniFi interfaces are bridged. Here's the DHCPOFFER expanded – willwill Mar 12 '17 at 10:18
  • Thanks for posting the offer! Could you also post the expanded DHCPDISCOVER? Not sure if it is possible to specify which interface on the UniFi requests the IP (with the UniFi factory firmware), but if it is, you'll want it to be the bridge interface that sends out the DHCPDISCOVER. With the LEDE firmware, it's definitely possible to have the DHCPDISCOVER originate from an interface that is not the bridge, so verify that. – Rich Alloway - RogueWave Mar 13 '17 at 14:34
  • Note that the offer didn't come from the UniFi, but from a wireless device. It is captured by configure the Mikrotik to mirror the switch port connected to UniFi to another switch port connected to my PC. Here's the DHCPDISCOVER – willwill Mar 14 '17 at 4:44
  • Since you have LEDE installed on the UniFi, can you perform a tcpdump packet capture on the bridge interface to see if the packets are seen twice? A command like tcpdump -i br0 -p -nn -s0 -w /tmp/capture.pcap, run on LEDE, should capture all packets to/from/through the bridge. This assumes br0 is your bridge interface. Ctrl-C to stop the capture after DHCP has been attempted. I would not filter tcpdump for DHCP-only as that may mask other packets which could tell us more about what is going on. /tmp/capture.pcap can then be copied over to your PC with Wireshark for detailed analysis. – Rich Alloway - RogueWave Mar 14 '17 at 14:09
0

In version 6.43 and 6.44 of RouterOS they now add the correct SRC MAC address, but also changed the DST MAC address for their broadcast DHCP offer. There exists a unicast DHCPoffer with source and destination MAC address but that one will not work for clients behind a wireless universal repeater. (A universal repeaters replaces the clients MAC address by its own. The unicast DHCPoffer never reaches the client.) The DHCPserver uses a broadcast DHCPoffer if requested or as second option. But the Mikrotik broadcast DHCPoffer contains DST IP 255.255.255.255 (OK) , but the specific DST MAC (not OK). Destination MAC should have been ff:ff:ff:ff:ff:ff .

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.