ROS 6.38 serious DHCP server problem

hutsch · Mon Jan 16, 2017 9:16 pm

Hi all!

Just discovered a strange problem with the DHCP server running at RouterOS 6.38.x preventing another Mikrotik Accesspoint and wireless clients from geting an IP address and rendering them inoperable.

Problem:

Wireless clients on an access point (RB433 - no matter if 6.37.x or 6.38) do not get any DHCP address from the router (RB1200@ROS 6.38 or higher) and even not a dhcp client on the AP gets an address. However, the windows clients connected to the router over the same external switch get IPs assigned.
Router continuously reports: "dhcp1 offering lease 192.168.2.252 for [...] without success" for the DHCP client on the AP.
Wireless clients can register to the AP but don't get any IP.

Configuration:

Router RB1200 ---- <eth to office>---- Netgear Switch GS108 ----<eth>---- Accesspoint RB433.
DHCP server running on router (without problems and configuration changes for years now).

Accesspoint:
bridge1 configured with member port wlan1 and eth1,
dhcp client interface set to bridge1
No special filters. Also reset the AP configuration (System/Reset configuration) in case something was misconfigured - same results

Above configuration worked for some years now.

Tests and conclusion so far:

Downgrading to 6.37 and step-by-step upgrading to 6.37.1, 6.37.2, 6.37.3 and at least 6.38 i discovered that until 6.37.3 everything works fine.
I also tried different versions on the access point but the version here doesn't seem to matter.
ROS-6.38.1 on Accesspoint and ROS-6.37.3 on the router is the highest version pair that works with my configuration.

Any clues?

Regards,

Heiko

david123 · Tue Jan 17, 2017 8:45 am

Unfortunately no clues, but I encounter the same issue.
I found that disabling/enabling the dhcp-package or restarting the router can solve it (temporarily)

hutsch · Tue Jan 17, 2017 3:22 pm

Just tested bugfix release 6.37.4 - also working fine without DHCP problems.
@david123: restarting the router did not work for me. DHCP for Accesspoint and its wireless clients (as described in my OP) doesn't work from the start with 6.38.

Splash · Tue Jan 17, 2017 7:24 pm

I have to agree with this problem. Since version 6.38 the DHCP Service stops responding and no new IP addresses are issued/renewed. To resolve the problem, one has to disable and re-enable the DHCP service.

Both 6.38 and 6.38.1 are affected with this problem.

Before Restart: (Mitel Phone)

19:19:22 dhcp,warning DHCP offering lease 172.29.40.60 for 08:00:0F:8F:C0:0E without success

After Restart: (Mitel Phone)

19:19:22 dhcp,info DHCP assigned 172.29.40.60 to 08:00:0F:8F:C0:0E

Has anyone logged this with Mikrotik Support?

luki · Tue Jan 17, 2017 7:40 pm

I also have the same problem session stops on the DHCP offered. The problem is version 6.38 and higher. Version 6.37.4 is ok.

Splash · Tue Jan 17, 2017 8:28 pm

I have logged a support request and included a link to this topic. I hope more confirm this in the mean time.

XaTTa6bl4 · Tue Jan 17, 2017 8:50 pm

I also have the same problem session stops on the DHCP offered. The problem is version 6.38 and higher. Version 6.37.4 is ok.

All the same!

copacetic · Wed Jan 18, 2017 9:20 am

Hi

I have a similar problem, which I was about to post before I came across this thread. Heres the description nonetheless...maybe some of my findings are helpful:

Problem receiving DHCP addresses over a VLAN using latest RouterOS v6.38.1. First of all, here is my setup

RB951G-2HnD ------------- CRS125-24G-1S-2HnD (DHCP Srv) --------- [Internet]
172.20.20.2/24 172.20.20.1/24
172.20.22.2/24 172.20.22.1/24

Network 172.20.20.0/24 is my primary network on an untagged VLAN, coupled with an SSID named "unknown".
Network 172.20.22.0/24 is my guest network tagged with VLAN 2, coupled with an SSID named "guest".
A DHCP Server running on the CRS should serve both VLANs with IP addresses, but there is a problem with DHCP für VLAN2 (guest):
- WiFi Clients connected to the CRS SSID "unknown" receive IPs from 172.20.20.0/24
- WiFi Clients connected to the CRS SSID "guest" receive IPs from 172.20.22.0/24
- WiFi Clients connected to the RB951 SSID "unknown" receive IPs from 172.20.20.0/24
- WiFi Clients connected to the RB951 "guest" SSID do NOT receive IPs from the CRS at all

What I have found is the following:
- dhcp logs on the CRS show that the DHCP request is received and an IP from the correct pool is offered to the client
- packet sniffer on the CRS shows that the DHCP reply/offer is sent out on the correct VLAN to the correct MAC
- however: packet sniffer on RB951 shows DHCP request leaving the router, but no DHCP reply/offer is being received
- The problem occurs both ways, e.g. when I set up DHCP Server for VLAN 2 on the RB951 and connect to the guest SSID on the CRS
- at some point in the past it did work with this configuration. I did not notice it stopping to work.
- The connection between the two Mikrotik devices is over devolo powerline. But I have confirmed the problem when connecting the two devices directly
- I have not configured any L2 security/firewalling e.g. snooping or similar
- When I connect a client to the RB951 on the guest SSID and give the client a static IP in the 172.20.22.0/24 range, the client can connect properly.
So basic VLAN tagging seems to be working i.e. its a DHCP problem.
- I have rebooted the devices several times, but will try manually disable/enable the dhcp service.

As a workaround I have configured a split scope for VLAN2 on the CRS and RB951. I am happy to provide command outputs, but need the direct commands to enter, since I am not that familiar with the CLI. Since I am not home very often, it might take some time for me to reply.

Kind Regards

kielerjung · Wed Jan 18, 2017 9:43 pm

Same here.

Not all clients seem to be affected, only some.

Problem started with 6.38, 6.37.x works fine.

AM1 · Thu Jan 19, 2017 12:29 am

I had a problem with some VOIP hardware and DHCP on 6.38,

I fixed it by having the DHCP Authoritative setting to 'after 2s delay'.

Not sure if this is the same issue you are discussing.

Cheers

Psiho · Thu Jan 19, 2017 12:37 am

I had this problem http://forum.mikrotik.com/viewtopic.php ... 00#p576886. After third upgrade to 6.38 (for troubleshoot) the problem disappear ) Very strange

UPDATE!!!
Today RB951 was shutdowned by wire. After boot up problem occured again. Downgrade to 6.37.4 (bugfix) and all went to normal state. Awesome!

copacetic · Thu Jan 19, 2017 8:48 am

@kielerjung: At some point I had the issue that my Windows 10 client did not receive an IP, while my Android client did. But I cant say on which version that was. Right now on 6.38.1 none of the clients get an IP.

@AM1: the DHCP Authoritative setting 'after 2s delay' was already set in my case, so no luck

AlexeyIlinsky · Fri Jan 20, 2017 8:46 am

Try to add dhcp alert on that interface, maybe someone is running dhcp server too

TheWooder · Fri Jan 20, 2017 10:13 am

Hey,

same problem here. Since upgrading to RouterOS 6.38 the dhcp service runs unstable. It suddenly stops working and i see "dhcp offering lease without success" errors in the logs.

Marcus

luki · Fri Jan 20, 2017 11:03 am

Wireshark tested and writes above user COPACETIC. There is another DHCP server in network lan.

Fri Jan 20, 2017 11:48 am

Version 6.38 had an issue related to STP which was resolved in 6.38.1. Also 6.38 changelog included note which said, that all devices should be upgraded to latest version to implement proper STP functionality in network. Same goes for 6.38.1 We have not seen any actual issues in 6.38.1 version related to software. Usually some devices in network are not upgraded and that is the cause of DHCP problems.

haik01 · Fri Jan 20, 2017 12:28 pm

I had this also regarding the "offering DHCP address" but not receiving or accepting it.

Turned our that one of the people, had a very old printer, and bought a print server. But that print server had by default a DHCP server on board to set it up. But the client did not know this, and could not setup the server. And left it for the weekend.

And I had to figure out why the DHCP did not work correctly.

So check if you have a second (unknown) DHCP server running. Just disconnect all devices (physically) from the 1200, and start to connect one by one. And test it thoroughly before connecting the second port.

copacetic · Fri Jan 20, 2017 12:33 pm

I can confirm that both my devices are running v6.38.1, and that there is no other DHCP Server running in that VLAN. Like I stated, the problem always occurs with clients connected to the miktorik that bridges the DHCP request to the DHCP Server, and not the mikrotik device which actually is the DHCP Server.

luki · Fri Jan 20, 2017 1:39 pm

Maybe it was the conflict STP openwrt a mikrotik ??

RB951G-2HnD ver. 6.38.1 DHCP SERVER
3x port and WiFi AP port access VLAN 20
1x port WAN port access internet connect
1x port via RB260GS port trunk VLAN 10, VLAN 20, VLAN 30
DHCP is working - ethernet port and WiFi

RB260GS ver.1.17
1x port via RB951G-2HnD port trunk VLAN 10, VLAN 20, VLAN 30
1x port access VLAN 30
1x port via RB960PGS port trunk VLAN 10,VLAN 20
DHCP not tested

RB960PGS ver. 6.38.1
1x port via RB260GS port trunk VLAN 10, VLAN 20
1x port access VLAN 10
2x port access VLAN 20
1x port via WR1043ND port access VLAN 20
DHCP not tested

WR1043ND-openwrt by LUCI
1x port via RB960PGS port and WiFi AP port access VLAN 20
DHCP is not working - WiFi, Ethernet port not tested

peper · Fri Jan 20, 2017 11:13 pm

Confirm having issues with DHCP server in 6.38/6.38.1.

Device is CRS125-24G-1S-2HnD.

Problems affected at list one DHCP client.
It is a Virtual Machine with Windows Server 2008 R2.
VM is not able to get address assigned to it in the list of static DHCP leases.
Mikrotik log states:
"dhcp offering lease <ip address> for <MAC address> without success".

This VM is running inside physical Server (also with Windows Server 2008 R2).
Physical server gets address from the same DHCP static list just fine.

milizhang · Sat Jan 21, 2017 5:47 am

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.

arxdust · Sun Jan 22, 2017 5:53 pm

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

luki · Tue Jan 24, 2017 9:20 pm

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.

kondrat · Tue Jan 24, 2017 11:15 pm

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.

2frogs · Wed Jan 25, 2017 2:03 am

Version 6.38 had an issue related to STP which was resolved in 6.38.1. Also 6.38 changelog included note which said, that all devices should be upgraded to latest version to implement proper STP functionality in network. Same goes for 6.38.1 We have not seen any actual issues in 6.38.1 version related to software. Usually some devices in network are not upgraded and that is the cause of DHCP problems.

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.

ngv · Wed Jan 25, 2017 7:40 am

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

kondrat · Wed Jan 25, 2017 10:59 am

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.

Wed Jan 25, 2017 2:52 pm

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 ... 50#p579856
http://mikrotik.com/download

CareySystems · Thu Jan 26, 2017 6:52 am

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.

Splash · Thu Jan 26, 2017 11:11 am

I have logged a support request and included a link to this topic. I hope more confirm this in the mean time.

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.

--
MikroTik.com

luki · Thu Feb 02, 2017 10:11 am

Are you with the problem solved after 6.39rc20 ??

PanhandleIT · Thu Feb 02, 2017 6:31 pm

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.

MobileEMP · Fri Feb 03, 2017 8:23 pm

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!

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.

gargola · Sun Feb 05, 2017 8:49 am

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.

sjennings · Fri Feb 17, 2017 7:52 am

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.

KaZaN · Wed Feb 22, 2017 12:04 am

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.

luki · Fri Feb 24, 2017 11:10 am

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

techmk · Sun Feb 26, 2017 12:46 pm

Hello!
We have similar problem. Mikrotik RB951 stops renewing IP address for some Wired / Wireless clients. Our workaround - backup DHCP scope on Access point.

jcmlanzas · Thu Mar 09, 2017 8:55 am

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.

snap87 · Thu Mar 09, 2017 9:22 am

Yes, I have this problem to. Work only for 6.37.4 version.

jcmlanzas · Thu Mar 09, 2017 4:33 pm

Further checks seem like a every minute:
15:00:09 dhcp,debug,packet dhcp-alert on bridge-vlan6 sending discover with id 351403283 to 255.255.255.255

15:00:09 dhcp,debug,packet secs = 64
15:00:09 dhcp,debug,packet ciaddr = 0.0.0.0
15:00:09 dhcp,debug,packet chaddr = 00:00:00:00:00:00
15:00:09 dhcp,debug,packet Msg-Type = discover
15:00:09 dhcp,debug,packet Client-Id = 01-00-00-00-00-00-00
15:00:09 dhcp,debug,packet Parameter-List = Subnet-Mask,Router,Domain-Server,Domain-Name,NETBIOS-Name-S
erver,Static-Route

Same message on 6.37.4 but the right MACs are shown con chaddr and Client-ID regarding to bridge-vlan6 MAC address.
Curiously on 6.38.4 i could maintain already assigned IP address once lease was assigned (*see bellow).
Moreover, other dhcp-server / bridge for wireless connections apparently works fine. Very weird thing.

* I meant i connected and HP laptop (Win7) via wired interface that didn't assign IP as described on my earlier post. I reloaded the router to 6.37.4 (previously configuration copied to its partition from recent 6.38.4 version);
DHCP lease was assigned and working when i was going to test something more with DHCP , then copy again config between partitions (this time from 6.37.4 to 6.38.4) . When device restarted on 6.38.4 version again, the dhcp server assigned correctly the IP (i'm still using it) so this a quite weird thing.
Anyway, i tried new devices and still the same issue.
Maybe that's the reason why some people could temporally work (until lease expired).
Hope this might help to do deeper test.

copacetic · Fri Mar 10, 2017 8:28 am

Problem was still present on 6.38.4 yesterday. Have not tried 6.38.5 yet,

ScottReed · Fri Mar 10, 2017 6:27 pm

Problem in v6.38.5 also. Upgraded a CCR1036 this morning per Mikrotik support request on another issue entirely. DHCP stopped working after the update.

Seeing "SERVER offering lease x.x.x.x without success" in log.

I disabled RSTP on the bridge interface and the issue appears to be resolved.

jcmlanzas · Sat Mar 11, 2017 6:05 pm

Problem in v6.38.5 also. Upgraded a CCR1036 this morning per Mikrotik support request on another issue entirely. DHCP stopped working after the update.

Seeing "SERVER offering lease x.x.x.x without success" in log.

I disabled RSTP on the bridge interface and the issue appears to be resolved.

I confirm the recovery of DHCP server assignment by the changing of any STP Protocol mode to another (maybe you might want to disable and re-enabled it again), so it seems a feasible workaround for me. But it is worth to mention that this just will work in the meantime the device is not rebooted in which case it has to be applied again.

ScottReed · Mon Mar 13, 2017 7:26 pm

But it is worth to mention that this just will work in the meantime the device is not rebooted in which case it has to be applied again.

This statement is correct. I had to reboot the affected router over the weekend and DHCP subsequently stopped working.

I've setup a 'startup' scheduled script to cycle the bridge interface.

sebus · Mon Mar 13, 2017 11:53 pm

That is a bugger... DHCP is rather useful...

Can you share the script?

sebus

sebus · Thu Mar 16, 2017 12:11 pm

Or are we likely to get the issue patched?

sebus

jcmlanzas · Thu Mar 16, 2017 2:11 pm

It seems to be patched on 6.39rc55

luki · Fri Mar 17, 2017 6:09 pm

Unfortunately, the version 6.39rc55 DHCP is not working properly. It is a pity that the Mikrotik long already solves this problem.

domgl · Mon Mar 20, 2017 12:35 pm

I have one RB951Ui-2HnD v6.27 and one RB450G v6.27, but IPSec hasn't work properly, that why I’ve upgraded them to 6.38.5. Now IPSec work very well, but DHCP server on RB951Ui-2HnD not quite good. PCs which MAC-IP addresses are NOT binding receive IP addressess, but these devices, which MAC-IP are binding NOT.

Restarting DHCP server works for me but is not solution. I seems to stop work properly after weekend (long time after IP releasing. My DHCP server Lease is set up to 5h).

morph · Mon Mar 20, 2017 10:57 pm

Just had this issue appear out of nowhere on 6.38.5.
It was working fine but suddenly it stopped issuing DHCP addresses to clients connected through my WiFi AP.
Disabling STP fixes the issue.

RackKing · Thu Mar 23, 2017 3:30 pm

I am now having the same issue after an upgrade - any update?

mdkberry · Sat Mar 25, 2017 1:04 am

I am having this problem on RB2011 connecting to an AP RB922AUG the AP is not returning the DHCP handshake in some way or cannot get it through.
logs show up on the RB2011 showing error "dhcp_wireless offering lease xxxxx without success"

This started happening right after reboot after upgrade from 6.35.5 on both devices to 6.38.5

I have tried adding in static ip but I still cannot properly reach the AP device to manage it either.

From this thread it is clear the issue has been on going for a few months but can't be universal which is even odder, maybe it is the hardware model numbers effected by the 6.38.x versions in someway. I have logged ticket with support directly but going to downgrade to 6.37.4 and hope that works. My clients come into work on Monday and no DHCP is going to be the end of the world. Cant believe this is not fixed since January! what is going on?

mdkberry · Sat Mar 25, 2017 3:17 am

ok this is my bodge work around (not confirmed whether this works with wireless devices as yet, only worked for the RB922AUG AP device. I wont know until after the weekend if the clients have problems getting new DHCP leases. Old leases seem to be mostly ok, new ones fail. I am hoping this bodge will last until I can downgrade the devices to 6.37.4 or Support come up with a fix)

1. On the main router RB2011 I went into the wireless Bridge and disabled the RSTP , set it to none. (I have no idea what impact this will have on the multiple scope DHCPs or risks of network flooding) I lost browser access and terminal access as the RB2011 hung for about 4 minutes, but luckily the VPN connection stayed up. the RB2011 stayed pingable in that time too.

2. when it came responsive again (without being rebooted) the AP miraculously picked up an IP address from the RB2011 DHCP server. I rebooted the AP and it picked it up again , so I am hopeful that Monday will be ok when everyone gets on the wifi network. Interestingly the RB2011 wireless bridge says rstp is enabled so maybe just freaking it out by trying to disable it, is enough to sort the problem out before the next time it reboots because....

3. I rebooted the RB2011 and once again everything stopped working so I had to repeat the above process.

mdkberry · Sat Mar 25, 2017 1:15 pm

thanks to user Tulluk on Reddit where I also posted this issue, it seem there is a fix for this,

in the bridge settings on the RB2011 set the 'admin MAC' of the wireless bridge0 to be the same as its actual MAC. This results in the DHCP packets having the right source MAC for return from the AP device. no need to change anything else, nor disable the STP. Everything also worked on reboot.

n3120 · Tue Mar 28, 2017 4:00 pm

Hi all,
Today I upgraded my RB450G from 6.37.x to 6.38.5, and I got the same problem: wireless clients are not able to join Wi-Fi.
After reading this post, I tried to set the protocol mode of bridge1 from RSTP to STP, and it works!!!
It's located at Bridge -> bridge1 -> STP -> Protocol Mode
Hope this helps!

cszolee79 · Fri Mar 31, 2017 1:01 pm

Same here.

hEX (RB750Gr3), ROS 6.38.5, Windows clients get DHCP, but UniFi AP and any client connected to AP do not.
Also, connected an RB951G-2HnD, and it gets DHCP IP on ether1, but not on ether2, wtf???

Same RB951G-2HnD with 6.38.5 works, all clients get DHCP (including UniFi AP and mobile clients).
We have a LOT of Tiks all around, all 6.38.5 now (many having UniFi APs), and the problem only happened with this particular hEX.
It was the same with 6.38.3 and the hEX.

pe1chl · Fri Mar 31, 2017 1:54 pm

Read the other posts before complaining!
Workarounds presented are:
- turn off RSTP
- enter an admin-MAC
It may well be that all your other routers had one of these already in place

cszolee79 · Fri Mar 31, 2017 2:17 pm

We read it and then complain as it is our right, and the correct way to report problems so Mikrotik can fix them.
It is a serious bug that never happened in the 6-7 years I've been working with Mikrotik devices (especially considering it only happens on some random routers it seems while others work).

lukasb · Sun Apr 02, 2017 11:58 am

I've encountered this problem also - a lot of users got stuck at DHCP offer and the log says dhcp offering to xxxx without success.

ROS 6.37.5 Bugfix release.

I've run the DHCP Server on physical interface port, not to a bridge interface & not running any kind of STP in my network

reefman · Tue Apr 04, 2017 2:40 pm

RouterBOARD 750G r3
Rollback 6.37.4 (bugfix) did not help

dhcp offering lease

kielerjung · Tue Apr 11, 2017 12:23 pm

I've updated my RB2011 to 6.38.5.

Setting the administrative MAC on the bridge-interfaces helped with this dhcp-problem.

Rey46 · Tue Apr 11, 2017 8:33 pm

I've updated my RB2011 to 6.38.5.

Setting the administrative MAC on the bridge-interfaces helped with this dhcp-problem.

I also upgrade to 6.38.5 and I had this issue, I went to System -> Package List and click "downgrade" selecting nothing.. I'm still on 6.38.5.. Maybe it reinstall the package but at the moment the problem there isn't. Could you explain more regardin the admin-mac? What mac I have to put in case this problem come out again? Thanks

kielerjung · Tue Apr 11, 2017 9:38 pm

See post of mdkberry (viewtopic.php?p=593272#p590626) above:

in the bridge settings on the RB2011 set the 'admin MAC' of the wireless bridge0 to be the same as its actual MAC. This results in the DHCP packets having the right source MAC for return from the AP device. no need to change anything else, nor disable the STP. Everything also worked on reboot.

(Kudos to tulluk on reddit: https://www.reddit.com/r/mikrotik/comme ... e_to_6385/)

Kindis · Wed Apr 12, 2017 9:09 am

I've updated my RB2011 to 6.38.5.

Setting the administrative MAC on the bridge-interfaces helped with this dhcp-problem.
I also upgrade to 6.38.5 and I had this issue, I went to System -> Package List and click "downgrade" selecting nothing.. I'm still on 6.38.5.. Maybe it reinstall the package but at the moment the problem there isn't. Could you explain more regardin the admin-mac? What mac I have to put in case this problem come out again? Thanks

To downgrade you need to download the release you which to "walk back to" and put the files on the router. Then click downgrade.
https://mikrotik.com/download/archive

Rey46 · Thu Apr 13, 2017 6:18 pm

See post of mdkberry (viewtopic.php?p=593272#p590626) above:

in the bridge settings on the RB2011 set the 'admin MAC' of the wireless bridge0 to be the same as its actual MAC. This results in the DHCP packets having the right source MAC for return from the AP device. no need to change anything else, nor disable the STP. Everything also worked on reboot.
(Kudos to tulluk on reddit: https://www.reddit.com/r/mikrotik/comme ... e_to_6385/)

Sorry but I'm italian and I don't understand exactly. I have my modem connected to port #1, port#4 there is connected a switch, from this switch there are connected 4 AP. My wlan1 is disabled. Which mac should i put?

kielerjung · Thu Apr 13, 2017 8:14 pm

On bridge "Internal" put MAC "4C:..." also into the field "Admin. MAC Address".

Please make sure, that your dhcp-service is bound to that bridge (IP->DHCP Server, look at "Interface").

Rey46 · Thu Apr 13, 2017 8:31 pm

On bridge "Internal" put MAC "4C:..." also into the field "Admin. MAC Address".

Done.

Please make sure, that your dhcp-service is bound to that bridge (IP->DHCP Server, look at "Interface").

Yes, hope it works.

Rey46 · Thu Apr 13, 2017 10:41 pm

At the moment I still have this issue in another location.. Anyone could help me?

RB951G-2HnD
Port #1: Pppoe client
Port #2: My-pc
Wlan1: Enabled wifi.

Krisken · Sat Apr 22, 2017 10:02 pm

I have exactly the same error on a RB3011 running ROS 6.37.5? Should be a stable release? Fixing the problem can be done the same way as described?

morph · Sun Apr 30, 2017 11:07 am

And again the same problem with 6.39.

pe1chl · Sun Apr 30, 2017 11:59 am

And again the same problem with 6.39.

What do you mean with "the same problem" as people are discussing different problems here...

morph · Sun Apr 30, 2017 5:26 pm

And again the same problem with 6.39.
What do you mean with "the same problem" as people are discussing different problems here...

DHCP server does not work unless you disable STP.

pe1chl · Sun Apr 30, 2017 5:38 pm

Even when you set a MAC address on the bridge?

michalsz2 · Tue May 09, 2017 4:22 pm

Adding Admin MAC resolved the issue for me, Thank You

mikronsultiK · Mon May 15, 2017 6:37 pm

Hi there

even on a 6.39.1 Installation the issue was occurring.

Solved configuring Admin Mac and disbaling /enabling rstp protocol.

thanks

jKonstantin · Tue Jun 13, 2017 7:50 am

rb750gr3 try this metod, dhcp not work with wifi ap clients.

timonlio · Sat Jun 24, 2017 7:43 am

Got the same issue when I upgrade my RB750Gr2 from 6.37.5 to 6.38.7, the AP hAP AC Lite failed to assign IP address any more.

pe1chl · Sat Jun 24, 2017 11:36 am

Got the same issue when I upgrade my RB750Gr2 from 6.37.5 to 6.38.7, the AP hAP AC Lite failed to assign IP address any more.

In general, or only to one single device that you tested?

wfuzatto · Sat Jul 08, 2017 8:43 pm

I got a similar problem, but using hotspot. The handshake could not be finished in a good time.
MK: CRS125
V: 6.39.2
Ap's: UniFi AC Lite

This problem shows up when the client roam between the AP's.

timonlio · Wed Jul 26, 2017 3:00 pm

Got the same issue when I upgrade my RB750Gr2 from 6.37.5 to 6.38.7, the AP hAP AC Lite failed to assign IP address any more.
In general, or only to one single device that you tested?

I have a hAP AC Lite, and a Linksys EA6500v2 working in AP mode, both device failed to obtain ip from dhcp server, after I upgrade hEX to 6.38.7 and reboot the device.
Finally, disable the STP and enable the STP on bridge1 on hEX works for me.

radekmacek · Tue Jan 30, 2018 9:29 am

Hello, I have the same problem in version 6.40.5. Client device that is responding to DHCP offer is sending message with ciaddr = 0.0.0.0 over and over. 10m lease time and every 10s is device trying to get new IP address. Same device in another port of a switch gets IP alright.

As per changelog for version 6.40 this should have been repaired:
*) dhcpv4-server - fixed lease renew for DHCP clients that sends renewal with "ciaddr = 0.0.0.0";

First started in 6.38.5 -> 6.39.3 -> 6.40.5. Every version has the same problem. I don't want to upgade to 6.41 yet. Propably will try downgrade to 6.37.5 as per post above.

Adding sniffed traffic fyi:

0.0.0.0_src_DHCP_problem.PNG

radekmacek · Wed Jan 31, 2018 2:42 pm

Hello, downgrade to 6.37.5 was not succesfull for me as CCR1036 is not possible to downgrade below 6.38.5. I have put 6.41 instead and problem stil exists.

pe1chl · Wed Jan 31, 2018 5:15 pm

Try setting a longer leasetime. Some devices have bugs and do not want to accept such a short leasetime.
Try 1h or more.

radekmacek · Thu Feb 08, 2018 11:52 am

Hello, found the root cause of the problem. In my case it was caused by dhcp snooping and max number of clients. For some reason maximum number of clients is 16 or 10 for edge-core, depends on the type of switch. Mikrotik is working correctly in my examle above.
Hope this helps someone.

rvilanov · Thu Aug 23, 2018 6:45 pm

This error is still happening on 6.42.7. Sundelly, the gateway stops to answer and all the dhcp users are getting offering lease whithout sucess.

mbarchiesi · Wed Oct 31, 2018 8:52 am

When Mikrotik will repair this issue????? This is not a less-meaning problem! Its huge! Come on guys! Even TP-Link doesn’t have problems like this! We are on 6.4x and you dont do anything yet!

Chupaka · Wed Oct 31, 2018 10:01 am

If you have a problem — what's your ticket number? (C)

Have you written to support@mikrotik.com?

bpwl · Tue Jun 04, 2019 10:24 pm

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.

Hi, is exactly what I see, with a hAP Lite version 6.43.11 or 6.44 and the TP-Link RE450 repeater. No client using the RE450 as wifi entry point gets a DHCP address. 30 seconds assigned offer, and that's it. We know that a pseudo bridge replaces the MAC address of the client by its own MAC address. So yes you will have multiple IP adresses assigned for the same ARP MAC address, but different DHCP MAC addresses. The factory installed RouterOS version on the hAP Lite is 6.42.1 . As far as I understand this is the lowest version I can downgrade to. Is 6.37.4 out of reach? Replacing the RE450 with a wAP, cAP or mAP? And using routed networks and DHCP relay, to be able to manage the user account versus IP address logging from the central DHCP server?

pe1chl · Wed Jun 05, 2019 11:48 am

You cannot run DHCP over a pseudobrigde operated in reverse. (i.e. with the DHCP server at the station side and the DHCP client at the AP side), as you will encounter the problem you describe.
However that is true for all WiFi equipment.
In the "normal" situation of having the DHCP server at the AP side and the client at the station side, it will work OK.
When you encounter problems with DHCP replies resulting in ARP requests you can use "always broadcast" in the DHCP server setting.

bpwl · Wed Jun 05, 2019 2:30 pm

You cannot run DHCP over a pseudobrigde operated in reverse. (i.e. with the DHCP server at the station side and the DHCP client at the AP side), as you will encounter the problem you describe.
However that is true for all WiFi equipment.
In the "normal" situation of having the DHCP server at the AP side and the client at the station side, it will work OK.
When you encounter problems with DHCP replies resulting in ARP requests you can use "always broadcast" in the DHCP server setting.

Hi pe1chi, thanks for the information. I do see these ARP requests in the DHCP offer-bonding transition, as an attempt to get over the offer state.The DHCP server is not run in reverse over the pseudobridge. I tried the "always broadcast" and other combinations with "Authorative" and "add ARP for Leases" in the DHCP server. Even removed "conflict detection" in 6.44 . On the bridge interface changed STP to RSTP and none as mentioned in this forum topic.
I did NOT reboot after every iteration, and that might be my mistake. Even tried DHCP snooping and trusted interfaces. No combination was successfull. I do have a similar problem with the Draytek Vigor router, where they merged the ARP MAC table with the DHCP MAC table in one of the upgrades. Since then, when the client had a static entry in the table, with its own MAC address it could not get an IP address (with the MAC address of the repeater) from behind a repeater. Removing the static entry was necessary to solve it. I see in the ROS 6.45beta that there is a possibility for setting the number of IP addresses for a MAC address. Is there a limit in the 6.44 and earlier releases? The DHCP IP address for the client will be assigned to the repeater MAC address, and the repeater already has a DHCP IP address. The RE450 works fine with the Draytek router DHCP, as do a large set of Engenius, Ruckus and Draytek AP's and repeaters. The idea is to replace the whole set with Mikrotik but then at least the DHCP should work with clients behind a repeater (managed repeater as part of the fixed installation, or unknown repeater as part of the visitors or tenants equipment).

bpwl · Fri Jun 07, 2019 3:08 am

You cannot run DHCP over a pseudobrigde operated in reverse. (i.e. with the DHCP server at the station side and the DHCP client at the AP side), as you will encounter the problem you describe.
However that is true for all WiFi equipment.
In the "normal" situation of having the DHCP server at the AP side and the client at the station side, it will work OK.
When you encounter problems with DHCP replies resulting in ARP requests you can use "always broadcast" in the DHCP server setting.

Have been watching (Wireshark) the wireless traffic on the client side, and again changed the settings in the DHCP server as suggested. But it seems that the Mikrotik DHCP server is NEVER sending the DHCPoffer as a broadcast. At least the client (behind a universal mode repeater like the TP-link RE450) never sees a DHCPoffer from the Mikrotik. When another DHCP server (Draytek 2132ac) is used replacing the Mikrotik then there is no problem with the RE450.

The manual in the wiki states that the "always broadcast" will be actibvated if the DHCP lease fails. But even with a static setting it does not help. Could it be that this ability for DHCPoffer en DHCPack via broadcast broke in release 6.38?

Other forums mention the same problem (UBNT: Mikrotik + Ubiquiti) but assume it is due to the firmware upgrade of the Ubiquiti equipment.

EDIT

Done more tests and a lot of packet sniffing. The Mikrotik indeed goes to broadcast if the unicast fails. Unfortunately broadcast of the DHCPoffer in Mikrotiks DHCP is sending the packet to IP address 255.255.255.255 as expected, but does NOT alter the destination MAC address to ff:ff:ff:ff:ff:ff, but leaves the destination MAC address as the unicast MAC address. This should help clients to accept the packet when there is not yet a usable IP address on the interface. This packet however never reaches the client behind a universal repeater. I tried to alter that MAC address by using the NAT rules for the bridge on which the DHCP server operates .. The rule when triggered just sets the MAC address to ff:ff:ff:ff:ff:ff for packets sent to 255.255.255.255, port 67. That should make it work over an universal repeater.The offer reaches the client now. Still not getting further than "offered", but a usable IP adres for some seconds.

nclmrc · Sat Feb 22, 2020 1:18 pm

Any update on this bug? Now i have 6.46.3.

Ferrograph · Wed Mar 18, 2020 3:27 pm

I dont think this is DHCP persay - it only happens with wireless devices - at least the issue I'm observing.

Try deleting the wireless client from the registration table either in CapsMan or wireless whichever you are running. Most times this restores the wireless client to working state.

It seems to be a problem relating to the wireless client being fully connected - at least where Ive observed this Ive seen that the wireless client is trying to obtain an IP address (thinking its fully connected) so the offer packet isnt getting through for some reason. Most likely you might be seeing the key exchange timeout message in the logs too at various times.

Very annoying problem since I convinced a number of installers to move over to CAPsMAN based wireless systems from Unifi, and its proved to be more troublesome - at least until this is fixed.

bpwl · Wed Mar 18, 2020 6:19 pm

" it only happens with wireless devices - at least the issue I'm observing."

Only in wireless you have level 2.5 bridges., or "pseudo bridges". Bridges where the MAC address of the requester is hidden, because it is replaced with the MAC address of the AP. (unless WDS is used, there is no room for the path and the destination in the packet header). The MAC address is in the DHCP request, but not in the packet header. Therefore for a client behind a pseudo bridge the DHCP server needs to broadcast its offer and its further checks, or the requester will never receive these. As far as I know broadcast is not only using 255.255.255.255 in IPv4 as destination address, but is also using the broadcast MAC address that is forwarded by the bridge to all ports. As the requester otherwise never sees the packet it never acknowledges, and the DHCP server drops the offer after a set timeout. (The lease never gets further than "offered".)

If the "pseudo bridge" uses proxy ARP it could work. If full broadcast is used it works. That's why I see mixed results, I think. Some other DHCP servers always work with pseudo bridges. Some "pseudo bridges" work with some DHCP servers, and not with others (like Mikrotik here).

Who's to blame? The bridge forwarding, the DHCP broadcast packet, the pseudo bridge ???

robpeng · Wed Apr 15, 2020 9:22 pm

Had hit a similar issue like this, it was really wreaking my head. I read somewhere to turn on alerts under DHCP Server > Alerts, once I did that I found another device (Hex S behind my TV) had a dhcp server running, deleted the dhcp config, even disabled the dhcp package, to be safe.

The alert saved me. My devices started connecting first time again

negromax · Wed May 27, 2020 3:05 pm

bpwl, thanks for your research

Unfortunately broadcast of the DHCPoffer in Mikrotiks DHCP is sending the packet to IP address 255.255.255.255 as expected, but does NOT alter the destination MAC address to ff:ff:ff:ff:ff:ff, but leaves the destination MAC address as the unicast MAC address.

I guess this is the exact problem why my OpenWRT + relayd based wireless repeater doesn't work. I have set always-broadcast to "yes" but got

Message		defconf offering lease 192.168.88.254 for 00:EA:4C:6D:11:96 to 54:E6:FC:F2:B8:48 without success

relayd doesn't forward dhcp replies to PC's

rafaelholeva · Mon Aug 31, 2020 7:36 pm

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.
Hi, is exactly what I see, with a hAP Lite version 6.43.11 or 6.44 and the TP-Link RE450 repeater. No client using the RE450 as wifi entry point gets a DHCP address. 30 seconds assigned offer, and that's it. We know that a pseudo bridge replaces the MAC address of the client by its own MAC address. So yes you will have multiple IP adresses assigned for the same ARP MAC address, but different DHCP MAC addresses. The factory installed RouterOS version on the hAP Lite is 6.42.1 . As far as I understand this is the lowest version I can downgrade to. Is 6.37.4 out of reach? Replacing the RE450 with a wAP, cAP or mAP? And using routed networks and DHCP relay, to be able to manage the user account versus IP address logging from the central DHCP server?

n my view, this is an issue that mikrotik refuses to understand, the psedo-mac issue is widespread use in some infrastructures, however DHCPv4 for RouterOs 6.47.3 Stable, still seems to refuse to deal with this means several ip addresses for the same MAC. This occurs mainly in the WIFI layer in router-board type hAP Lite etc.
It seems that mikrotik is not giving as much impostance to an error as serious as this one, which compromises the user's final experience too much, on the other hand no one goes public to report consistently why this happens and what is the standard solution to solve DHCP offer problem for pseudo-mac (Assigning several ip to the same MAC). I hope that mikrotik will take action and come to the public with a definitive solution to this problem, and that it will also manifest itself through a note on why the changes in the DHCPv4 standard. Many users are looking for a solution to this problem and it is useless to assign a mac-admin to the bridge, or disable STP or RSTP, as the problem persists after a few minutes when renewing. Let's wait for a valid explanation from the engineering side via the official note from mikrotik

rafaelholeva · Mon Aug 31, 2020 8:24 pm

bpwl, thanks for your research
Unfortunately broadcast of the DHCPoffer in Mikrotiks DHCP is sending the packet to IP address 255.255.255.255 as expected, but does NOT alter the destination MAC address to ff:ff:ff:ff:ff:ff, but leaves the destination MAC address as the unicast MAC address.
I guess this is the exact problem why my OpenWRT + relayd based wireless repeater doesn't work. I have set always-broadcast to "yes" but got
Code: Select all
Message		defconf offering lease 192.168.88.254 for 00:EA:4C:6D:11:96 to 54:E6:FC:F2:B8:48 without success
relayd doesn't forward dhcp replies to PC's

I have this same problem here with my DD-WRT operating in AP mode (Pseudo-BRIDGE).

reference: viewtopic.php?f=13&t=165423

Juraj22 · Wed Oct 21, 2020 10:16 am

Same in my case, I had to use pseudobridge(connect TP-Link AP with Mikrotik hAP) and devices behind Mikrotik(ethernet ports) has problems with DHCP lease. They cant get IP address form DHCP server..
I really like Mikrotik(great powerful devices for good prices), but this is annoying situation. I think that must be some solution how to fix it or create som hotfix for it on Mikrotik site. I understand problem with MAC addresses, but in other brands is working wifi-bridge quite fine in cases where is impossible to use cable and you need to have same network.

Wed Oct 21, 2020 12:11 pm

Thank you very much for your reports and findings.
In case you have any ongoing issues with current/long-term versions and DHCP, it would be great you can write to support@mikrotik.com, describe your setup and provide with support output file from server (that has dhcp,debug logs enabled).

kriss · Tue Nov 03, 2020 2:07 am

I have the same problem on CCR1072-1G-8S+ fw 6.46.8.
In my case VoIP base can't get DHCP address. Voip base (Granstream DP750 PoE) is connected to Cisco SG350X-48P which is connected to Mikrotik
I have 13 base ant only one can't get address.

dhcp1 offering lease 10.10.x.x for C0:74:AD:xx:xx:xx without success

pe1chl · Wed Nov 04, 2020 3:56 pm

I have a Grandstream GXP2100 and it works fine. Are you sure there is nothing between phone and DHCP that filters or changes MAC? (like a wifi link)

Ferrograph · Fri Nov 06, 2020 4:04 am

Who's to blame? The bridge forwarding, the DHCP broadcast packet, the pseudo bridge ???

Thanks for this clear explanation. Would this apply to standard wireless client setup with say multiple cAP AC, all ports bridged CAPs mode with local forwarding?

likaon · Sat Dec 26, 2020 10:09 pm

Hello,
I'm writing once again because I've got the same problem. RouterOS version 6.48 was to repair problems with Accesspoint and wireless clients from geting an IP address.
My tool is Mikrotik hap AC2 RouterOS version 6.48. and Accesspoint TL-WA854RE oraz asus rp-ac51.

Do I have to write anything new in settings?

Ferrograph · Fri Feb 12, 2021 3:01 pm

Still seeing this in 6.48.1. So annoying.

galaxynet · Thu Mar 11, 2021 8:02 pm

I'm seeing it as well on a nRay 60g with 6.48.1

Hope you guys get it fixed soon!

bpwl · Fri Apr 09, 2021 11:29 am

That DHCP problem over pseudo-bridges seems to be everywhere!???

Still having an almost useless TP-link RE450 v2 "repeater" on my desk , I saw the OpenWRT reference, and implemented it.
(the original firmware needs too much DHCP server manipulation and it selects the wrong channels and bandwidth when doing cross-band repeating)
"repeater" in OpenWRT is not that straightforward, but they have the optional "relayd" package.
And guess what? They also have problems with DHCP. https://openwrt.org/docs/guide-user/net ... figuration

The most common problem is that the client router cannot pass the DHCP message between the main router and the client connected to the client router. Currently it seems to be the hardware/SOC limitation (related to MAC cloning?)

But it's a step forward. The RE450 has 3x3 radio's and now I have a usable AP with good wifi. Repeating as a "home AP" (different subnets) works fine. Need some experiments to see if the "repeater" function (transparant subnet) is usable with an uplink to MT AP and DHCP server.

https://forum.openwrt.org/t/relayd-not- ... s/53607/13

I compared responses (DHCP ACKs) coming via Mikrotik and non-Mikrotik APs.
the only difference is that in the latter the response has a broadcast address in the Ethernet header (works) while in the former it's the MAC address of the WiFi client (doesn't work).

ShaMana999 · Fri Apr 09, 2021 12:28 pm

Greetings good people. It seems I'm having the same or similar issue. I'm very green at this and am learning on the fly for home network needs.

So, my case is that I have a hEX S routerboard paired with a cAP ac for wireless access.

I've set up the cAP to act as a bridge and forward DHCP requests to the hEX, however, it seems the bridge itself doesn't like to obtain an IP for the access point and generates "offering lease without success error". I've tried the recommendations above like disabling STP and manually adding Admin MAC to the bridge in question, and they provide only a temporary fix.

Right after applying settings change the access point obtains IP until the lease expires and the problem appears again. At first glance, regardless of the IP status, wireless clients work as expected.

Any suggestions.

PS: Scratch no wireless troubles. Devices work at 1/8 bandwidth, may not be related, but something I've messed up while setting up the interface.

Who is online