Same here - 6.38.1 no longer works with my Ubiquiti APs, while 6.37.4 works well. I think this is something that should be taken seriously.
I have the same problem
750gr3 router (dhcp server), dhcp leases have static 192.168.1.5 —> rb951 (1eth master port). In bridge = eth1 + wlan. DHCP client- bridge
after the update (6.38 or 6.38.1) - it works, but after the restart 951, is not getting ip … The logs writes "dhcp, warning defconf offering lease 192.168.1.5 for D4: XX: 6D: XX 60 without success ". The other dhcp servers on the network do not have
Problem 6.38 and 6.38.1
6.37.4 all good
For me the problem is Solved ROS 6.39rc17
wireless - apply broadcast bit to DHCP requests when using station-pseudobridge mode;
THX
UPDATE
After the restart after a few days the problem returned or version and 6.39rc17 and 6.39rc19 is also flawed.
For me v6.39rc17 does not resolve the problem. My access point is rebooting/ isnt geting IP address. Logs:
defconf offering lease 192.168.1.254 for /mac/ without success.
Any chance to have it fixed? My AP is Asus EA-AC87 and router 750Gr3.
v6.39rc17 broke STP on my rb2011UiAS-2HnD, it makes the bridge root port the ether my DVR is on and will not pass traffic. I can remove that port from bridge, disable the ether, or set STP to none to start passing traffic again. I updated from v6.38rc46. The DVR is a Directv Genie (HR44/700) and has a pass-through ether (2 ports) which may actually be the cause. It had been working fine before the upgrade.
Also all 11 of my MT devices lost their admin-mac’s, that had been set for their bridges, when they were updated.
We are seeing this issues with version 6.38.1 as well. I have downgraded one of my test routers to 6.37.3 to see if it resolves.
15:37:55 dhcp,warning dhcp3 offering lease 10.225.119.50 for 74:D0:2B:8C:78:9D without success
15:38:25 dhcp,warning dhcp3 offering lease 10.225.119.50 for 74:D0:2B:8C:78:9D without success
Same issue for me- 6.37.3, 6.38.1, 6.39rc17- all software versions have dhcp issues for me.
Please test 6.39rc19 or later version if possible. We have had another additional fix for specific bridge port configurations.
http://forum.mikrotik.com/viewtopic.php?f=21&t=116357&start=50#p579856
http://mikrotik.com/download
I can confirm the same DHCP server / pass through issue on the CRS125-24G-1S-2HnD-IN running 6.38.1. Our set up uses the CRS as a multi-VLAN switch and multi-SSID access point. The DHCP server is a Cisco RV220W connected through the CRS Eth1. The CRS was not able to receive (bind) any DHCP offers from the RV220W and was not passing them through to clients either. At first we thought this was a VLAN configuration issue, but it only appeared when we upgraded to 6.38.1. Then we found this forum chain and investigated further after 20+ hours of onsite troubleshooting in a campus environment with multiple wireless PTP links, etc.
After upgrading to 6.39 (testing) release, the problem did not exist anymore.
However, there seem to be some strange VLAN behavior with the VLAN setting for the WIFI interfaces. If you set “VLAN Mode” equal to “Use tag” and set the corresponding VLAN ID then the WLANs do not seem to pass any traffic even when bridged to VLAN interfaces that are connected to a physical interface/trunk interface such as Eth1.
For example:
Eth1
→ VLAN_2 (VLAN ID = 2)
→ VLAN_4 (VLAN ID = 4)
WLAN 1 (VLAN Mode = Use Tag, VLAN ID = 2)
WLAN 2 (VLAN Mode = Use Tag, VLAN ID = 4)
Bridge_VLAN2
Ports
VLAN_2
WLAN_1
Bridge_VLAN4
Ports
VLAN_4
WLAN_2
The above config doesn’t pass DHCP from the DHCP server providing addresses to Eth1 on VLANs 2 (192.168.2.x) and 4 (192.168.4.x).
If you remove the bridges and just hope the VLANs “automatically” map between the WLANs and the VLAN interfaces configured on Eth1… no traffic gets passed. Not very surprising, but this leaves me wondering… what is that VLAN Mode and VLAN ID setting in the Wireless menu really for?
The only way this configuration works is if you set VLAN Mode = No Tag for WLAN_1 and WLAN_2, then everything works again. Because the bridges effectively map the wifi traffic to the VLAN interfaces on Eth1.
I could just have a fundamental misunderstanding of how the VLAN mode and VLAN ID work for the WLAN interfaces, but it does seem to break other stuff that it shouldn’t.
Hello,
Sorry for delayed reply. Now we have fixed some bridging bugs from 6.38.x which could cause DHCP related problems and recommend upgrading to the latest v6.39rc.
Best regards,
Janis B.
Are you with the problem solved after 6.39rc20 ??
So, I upgraded several routers last night to 6.38.1. A hEx Lite and a CRS125 both had DHCP issues with Ubiquiti access points (both UAP/UAP-LR’s and UAP-AC’s). I rolled both of them back to 6.37.4 and troubles are gone.
Other locations that did not have issues included CRS125’s (same exact model as the one with problems), RB2011L’s, hEx’s, and an hAP AC Lite. Many of these locations also have Ubiquiti AP’s.
All access points were already updated to their latest firmware.
One thing that I noticed was that Unifi Discovery was reporting the AP IP address as “192.168.2.20?”, putting a question mark for the last digit and it could not reach them to send commands. I didn’t have any issues with any of the wired clients except for the APs.
PanhandleIT, I can confirm that same issue with multiple UniFi AC-Lite access points using an RB3011. I thought I was going crazy for a while. I reset the config and dumped my script on multiple times to no avail. Glad I found this thread because everything is just fine on 6.37.4 (Bugfix).
Thanks everyone!
I was having the same issue with the “offering lease without success” for some customers.
It was happening with a RB1100AHx2, after several reboots and tshoot, they were remaining around 7 customers that couldn’t get ip, all of them with routers TP-Link WR720N.
I Tested versions 6.38.1 and 6.39rc25 both of them having the same DHCP issue.
This is a quick note of my topology:
RB1100 → Thoughswitch → ubnt network (bridged) → CPE (bridged) → Home router (different brands). Yeah, I know, not the best of the topologies, I’m working in the new design to avoid bridges and broadcast.
I had to downgrade to version 6.36.4 and everything is back to normal.
I encountered this same issue. Opened the box with 6.37.1 and it worked. Upgraded to 6.38.1 and my UniFi AC LITE started dropping DHCP offers.
Did a packet trace of the DHCP OFFER 6.37.4 vs 6.38.1 and the 6.38.1 DHCP server sends the OFFER broadcast (mac ff:ff:ff:ff:ff:ff, ip 255.255.255.255, without the broadcast flag set in the flags) where 6.37.4 sends the OFFER unicast to the client that did the DISCOVER.
This is in violation of RFC 2131 4.1:
If the broadcast bit is not set and ‘giaddr’ is zero and
‘ciaddr’ is zero, then the server unicasts DHCPOFFER and DHCPACK
messages to the client’s hardware address and ‘yiaddr’ address.
Same issue for my Unifi APs (and Edimax APs also) and to my wireless clients trying to connect via these APs with my RBs 750Gr3 using 6.38 , 6.38.1 and also in latest RC 6.39rc33 , only 6.37.4 bug fix helps to my RBs to get my DHCP servers back to work.
6.38.3 DHCP is still not working properly.
DEBUG
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet VLAN20 received discover with id 1682309120 from 0.0.0.0
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet secs = 252
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet ciaddr = 0.0.0.0
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet chaddr = 9C:AD:97:52:55:C5
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet Msg-Type = discover
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet Client-Id = 01-9C-AD-97-52-55-C5
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet Host-Name = “BRW9CAD975255C5”
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet Parameter-List = Domain-Server,Router,Subnet-Mask,Domain-Name,Unknown(66),Unknown(67),Unknown(13),NETBIOS-Name-Server,Unknown(2),NTP-Server,Unknown(120),Unknown(125),Host-Name
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet VLAN20 sending offer with id 1682309120 to 192.168.3.28
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet ciaddr = 0.0.0.0
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet yiaddr = 192.168.3.28
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet siaddr = 192.168.3.1
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet chaddr = 9C:AD:97:52:55:C5
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Msg-Type = offer
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Server-Id = 192.168.3.1
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Address-Time = 86400
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Domain-Server = 192.168.3.1,192.168.4.2
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Router = 192.168.3.1
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Subnet-Mask = 255.255.255.0
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet NTP-Server = 192.168.3.1,192.168.4.2
Hello!
We have similar problem. Mikrotik RB951 stops renewing IP address for some Wired / Wireless clients. Our workaround - backup DHCP scope on Access point.
As far i could see, from client side (wireshark), DHCP packet is sent to the broadcast (Msg type: discover ) which Mikrotik device receive and send back a Msg Type: offer. Thing here (and tested several times) is either DHCP packet type (offer) is not sent correctly or is sent as ARP broadcast asking for assigned IP in the offer. In any case client does not receive DHCP packet msg type: offer but ARP broadcast from dhcp-server asking for offered IP instead.
So in that way, client sent again broadcast with discoveries DHCP packets until number of tries it has configured (usually three).
I have the dhcp server listening on a bridge interface so it is possible there are some issue relative to sending broadcast packets via bridge interfaces (on my scenario). Also possible some bug on DHCP server (misconfiguration for new version could be a possible as well) that don’t really send offers packets via dhcp-server listening interface.
Exactly same configuration from both sides (client/server) work as expected on previous version 6.37.4.
Yesterday i updated to 6.38.4 but same results.
Edited: Just to clarify that from Mikrotik device side i ran a packet sniffer and both (packet snifer and wireshark) match on results here exposed.
Yes, I have this problem to. Work only for 6.37.4 version.