So I went from never seeing this error to seeing it a few times a day.

06:21:18 dhcp,warning DeviceName offering lease 10.1.3.4 for xx:xx:xx:xx:xx:x without success

Model: RouterBOARD 3011UiAS
ROS Version: 6.40
Firmware Version: 3.35

Running a WISP. Seeing this with multiple devices not just the one listed above. Even CPEs are doing this.

Problems seems to have just started a month or two ago.

This is a "wellknown" problem.
You have masked the actual MAC address, show us the first 3 bytes!
When you look that up in one of the published assigned MAC address ranges, you will likely see it is an Apple device.
There appears to be incompatibility between Apple devices and RouterOS DHCP servers.
Of course it is unclear if it is a bug in Apple OS or RouterOS.

This is a "wellknown" problem.
You have masked the actual MAC address, show us the first 3 bytes!
When you look that up in one of the published assigned MAC address ranges, you will likely see it is an Apple device.
There appears to be incompatibility between Apple devices and RouterOS DHCP servers.
Of course it is unclear if it is a bug in Apple OS or RouterOS.

Masked MAC address belongs to a mikrotik CPE (SXT 5 lite).

I have heard many interpretations of this issue... No one seems to know the real answer...

Mikrotik devs: please help!

Sent from my Pixel 2 using Tapatalk

There are 2 known reasons why this can happen:
1. the connection is lost during the DHCP request exchange
2. there is some misunderstanding between the requestor and the DHCP server, this usually involves an Apple device.

So in your case it is the first: your client loses the connection frequently and it happens during the DHCP

I guess I will monitor more closely and get some WireShark captures.

What I find most odd about this is the fact that I never saw this at all until a month or two ago. Now, I see it multiple times a day and it's all with communication between my Mikrotik AP and Mikrotik CPE.

i just found this log today....
my configuration was an groove a52h , set as client receiver(wifi) and router ( device 1 ) , activated the dhcp for ether1 interface and go to swith with some ap for local wifi hotspot( device 2 ),, as my concern,, seem the trouble log came out cause by change paswword on my local wifi ap hotspot ( devices 2), so the user (with handphone or notebook ) cant conected to wifi ap hotspot and being rejected by router,,

I guess I will monitor more closely and get some WireShark captures.

What I find most odd about this is the fact that I never saw this at all until a month or two ago. Now, I see it multiple times a day and it's all with communication between my Mikrotik AP and Mikrotik CPE.

Hi Arcee
Did you ever sort this out?
I have a Mikrotik HAP AC Lite which has I want to use as a wireless repeater (eventually as part of a mesh network with WDS)
It's connected to my router (MT HAP AC) with a good wireless signal (-65dB) but won't pick up an IP address.
Error message on router is "dhcp warning, defconf offering lease 192.168.1.2 for 6C:3B:6B:41:E9:15 without success"
On the AC Lite I've created a bridge and assigned the management interface with the MAC address of the WLAN2 interface.
Thanks

This happens to my costumers when they connect other routers with default configuration and a second DHCP server is active for LAN.
Make sure that there aren't other routers connected via WAN interface and with DHCP server disabled.
For example, TP-Link repeaters have DHCP server "auto", when your DHCP server goes down, TP-Link enable its own server, clients get IP from it and with 3 days timeout.
Solution: destroy repeater or change TTL to 1 so they won't use them

Hi we got 3 different network managed by Mikrotik Routers:

• Network 1: Mikrotik Router RB2011 1L

• Network 2: Mikrotik Router CCR-1016

• Network 3: Mikrotik Router RB750Gr-3

In all of them we got problems with DHCP server and Leased IP, we assign an IP to a device (MAC address), most Linux PC obtain the correct IP, but most Unifi AP, Windows 10, Apple Mac, iPhone, iPads, Android Phones and Tablets do not obtain the designed leased IP, and DHCP server assigns a new one.

All devices are configured to obtain IP dinamically.

We test different RouterOS version, some user says that version 6.37.4 do not have this bug, we tested that version in all devices, and got the same results that I describe in previous paragraph.

We are seriously thinking to replace Mikrotik Routers.

When you want to assign a fixed IP to a device, do not create the entry manually, but first let the device request an IP dynamically,
then open that entry and click "make static" and when you wish you can edit the IP address to the correct value.
This makes sure the MAC and the Client ID are correct in your entry.
When it is done this way, it will work correctly.

Good day

I have just experienced this issue with iPad 2017 as a client in the following topology:

hEX S (CAPsMAN + DHCP + L3 VLAN swithcing) <-> hEX PoE (L2 VLAN swithcing + PoE) <-> wAP ac (CAP local forwarding + several VLANs)

Everything was fine at first time, I played with wireless fine tuning, iPad connected with no problems at 5ghz 5180 20mhz Ceee (rate 866Mbit 2S SGI, managed to get 290-320 Mbit real throughput with CAPsMAN local frowarding)

"Offering lease without success" messages appeared after changing from v.6.43.8 (stable) to v6.42.11 (long term).

"Gray beard" guys advise to use long term, so I tried. Changed firmware on all 3 devices simultaneously, configuration was exactly the same

Moving back to v.6.43.8 (stable) on all 3 devices - problem dissapeared. Issue is repeatable. More interesting is that for iPad to work it is sufficient to keep wAP ac at v.6.43.8 (stable) and hEX S at v6.42.11 (long term)

Did not dig deep into the problem, have to give back equipment to customer. Wild guess: maybe is has something to do with L2 default settings difference, or in bridge VLAN filtering logic difference in stable and long term release

Have same problem, my wife came home with iPads from school to upgrade them today.
1 connects , 5 others not! (iOS 11 all). And according to here it should work

Then to check if "apple issue", i also tried with my android phone to connect to this Wifi network, but it does neither
get an IP address.

I tried to log debug, DHCP, IP, all filters that drop traffic, but nothing (packets, drops) shows up anywhere... even when torching.

Only thing is, in torch I see some IPV6 stuff from time to time but I am not knowledgeable about IPV6.
(IPV6 is not enabled on the router).

Such postings are not very useful, except maybe to relieve you from some stress or frustration.
We all know that there are sometimes issues, but without detailed debugging there is nothing that can be done.

For me the problem is with static addresses and seems to be connected with this option which sends offer even if there is no demand for it.
Converting dynamic address to static makes this option somehow "checked" even DHCP server has it "unchecked" so if you forgot to uncheck then static reservation broadcasts it.

Testing on RB2011 with 6.42.11

This option somehow "checked" even DHCP server has it "unchecked" so if you forgot to uncheck then static reservation broadcasts it.

I'm having this issue with one device in my network. Are you suggesting to check or uncheck it?

Uncheck ...
"Always send replies as broadcasts even if destination IP is known. Will add additional load on L2 network."
DHCP broadcast an offer even if device is just deassigned.

Does not help ... no change .. still receiving warnings

Does not help ... no change .. still receiving warnings

Same for me, issue still remains.

Suspecting that DHCP server mostly warns

A. when device try to renew address when lease is still valid and full DHCP REQUEST-ACK-CONFIRM process is not done
or
B. ROS sees that device is "vanishing" ... I see it in logs when CAPSMAN moves device from one AP or interface to another.

The problem persists. Only 2 computers among 15 are causing the log entry: ... DHCP offering lease without success. Both wire connected. Not Apple. There are other PCs on the net, wireless and wired, no problem with them. Operating system is Windows 7 x64 at almost all of them.

What interesting, the computers receive their IPs but they are not registered with DHCP server. Therefore if the IP is on some list or FW rule etc. - it's not taken into account. Pity that Mikrotik pays no attention to the obvious bug. Looks like version 6.37.5 is the last bug free.

Device: MikroTik RB951G-2HnD
OS version: 6.43.12

Have you tried disabling STP on bridge? And did you report this issue to support?

Have you tried disabling STP on bridge? And did you report this issue to support?

STP is OFF

No, I didn't report it. Googling it I found that there is a surge of complaints since summer 2018, but no answer. I believe it is already reported; besides the issue emerges by itself with the recent upgrades.

having this issue as well. first thought it was caused by my Unifi APs but now it seems to be pointing towards Mikrotik. It is now affecting non Apple devices (so far 2 x windows 10 laptops, one of which is ASUS).
I am running CCR1009, ROS 6.43

any one has a fix yet?

Having this "issue" is normal in a wireless network, probably it stands out on MikroTik only because it is logged by default.
What is important is: are your systems, when they have a stable wireless connection, getting their IP address allocated.

@ pe1chl
thanks for reply. I am looking into it a bit more:

more often than not, before an "offering lease without success" error, Mikrotik repeately deassign and assigne DHCP over and over
this happens to a range of devices. I did consider an wireless connection issue but my question is: this network has never had similar issue before and a bad connection would just drop traffic why the router would decide to deassigne the DHCP it just renewed?

edit: I have already set admin-mac to the bridge where the DHCP is on
the bridge has RSTP on but I have just turned it off. will report back if this helps

I have followed up another device on this network having similar issue. It is also a Nintendo device. Here is my thought:
I have hotspot running so it can connect to wiFi (both devices has -60dBm signal level and low channel utilisation ) but they cannot authenticate on the hotspot portal.
My guess is that even these device is connected to WiFi, got DHCP, but it never get authenticated by the hotspot server.
then after 10m Mikrotik will deassign it's DHCP lease. However, this does not explain the xxx timers of deassign / assign process immediately afterwards. Why do the router repeate this so many timese in the space of few minutes?

I have now changed idle-timeout to 1 hour and kept login-timeout disabled .

PS: disable RSTP has not made any improvement.

same here, and this problem occurs spontaneously on different mikrotik's, v:6.44.1

version 6.44.2
After I change the local forwarding to CAPsMAN forwarding, The problem are solved.
But the CAPsMAN forwarding throughput is very poor.

I'm not happy with this situation. I have CAPSMAN based forwarding running on a CCR with RouterOS 6.44.3, all cAP access points are running Version 6.44.3 aswell. For weeks I see a lot of users complaining about not getting IPv4 addresses. Today I took one user with two clients (iPhone, MacBook Pro 2). Both clients tried to connect to a wAP ac with RouterOS 6.44.3. Rebooting both clients didn´t help at all. I finally downgraded the wAP ac to RouterOS 6.43.16. (The CAPSMAN controller stayed on version 6.44.3) Both clients immediately connected to the wAP ac.The DHCP server itself is running on the CCR.

I once read that RouterOS have to be the same on the CAPSMAN controller and the cAP devices. My assumption is that with the current situation (6.44.3+6.43.16) CAPSMAN controller (6.44.3) is not able to change the wAP's (6.43.16) configuration such that for now the DHCP problems are gone. I do Not have any proof for this. Currently I'm downgrading all access points to 6.43.16. I will see If I have less DHCP errors.

This issue occurs with following configuration:
Router: RB951G-2HnD running RouterOS 6.44.3 configured as Home AP
Bridge: Linksys WET610N
when WET610N Ethernet is directly connected to a device (e.g. Desktop) having a MAC.

The issue goes away when the WET610N Ethernet is unplugged or when connected to an unmanaged switch.

Suspect the WET610N is trying to clone the desktop's MAC address

I hope MT can face this problem squarely.

After I use (Bridge->reply-only & DHCP Server->Add ARP for Leases), the situation has been improved, But the problem still appears randomly(has been reduced a lot).

My Network : (version 6.43.16 or 6.44.3)

internet------ether1---hEX(CAPsMAN+DHCP Server)---bridge(ether4+5)---(DHCP Snooping Enable+Not Trusted+CAPsMAN Forward)---wap ac

Any news? Has the situation improved for you?

I think I got the same issue. Any solution?

Using switches from D-Link and LevelOne causes me this issue. I changed all for Cisco Small Business and works perfect the DHCP.

Regards.

I had this issue and found the following:
- I found a few devices with both a wired and wireless connection active.
- There was also a Layer7 entry which was filtering (forward-drop) Facebook from this office network.
One of the PCs I tested this Facebook block had both connections active.
The router (CRS328) was brought to it's knees! It actually seemed to power-cycle itself, like a faux reboot.

I disabled the firewall rule, and fixed those PCs.
I do have, and prefer to leave enabled, RSTP on the bridge.
Issues persisted until I did a reboot from WinBox.

So far, so good.
All devices, including an iPhone and some DLink webcams, are happy now.

My logs during the issue showed lots of memory issues.
I suspect there is an issue in RouterOS that needs to address DHCP memory purging.
It seems like garbage is collecting in the memory, and jamming up router operation, and unpredictable things,
like faux reboots and failed DHCP, are happening.

I am pretty sure the Facebook filter rule, that I stuck up high on the filter list, is CPU-intensive.
I may re-enable it and see if it overwhelms the router again.
I'll post results at a later time...

Hope this helps!

The Facebook filter rule probably doesn't even work correctly! (and it blocks unrelated sites for others)

But hey, people keep trying it...

I had this same exact issue,
It was resolved quickly by going to Interfaces---->Hotspot Interface----> change ARP to reply-only.
Fixed the issue. All clients are now getting DHCP leases.

The issue is not client mac/manufacture related. I am running 6.45.5. I was experiencing this error with one netgear router client. 50 other clients some with the same model router were working normally. Forcing the client to retry just gave the same "DHCP Offering Lease Without Success" error log entry. The issue disappeared when I changed the dhcp source ip which should not have made any difference. I believe what really fixed this was making a change that restarted the dhcp process on the microtik. I think there is some kind of memory/data corruption bug.

I have this problem with lots of Mikrotik APs like RouterBOARD wAP G-5HacT2HnD and DHCP on routers like RB1100AHx4 and RB4011
AP without bridge gets an IP instantly on ether1.
As soon as a bridge is created, no soup. The DHCP server is stuck on Offered
To fix it I need to set STP Protocol Mode to None on the AP bridge. Instant IP.
Fun fact: some APs work, some don't (same model even). Same cable, same switch in between, same basic settings, all devices in between and ends Mikrotik.
Can't get more basic than NO default config, two wlan interfaces for WiFi, no firewall, one standard bridge and one DHCP client on bridge.
There is something wrong going on for quite some time and of course, Mikrotik just blames anybody but themselves.

STP on access ports can often create issues due to timing: a port with STP has a waittime before it starts passing traffic, and the device on the other end may in the meantime decide that the network is non-operative and start using an APIPA address (169.254.x.x).
When you do not need it, it is often better to avoid STP. Of course STP can have the advantage that it serves as a loop avoidance protocol on access ports, but when you do not require that you can choose to have STP only on links between switches.

Hi,

Having the same problem here. I have sent a support request to MikroTik about it. In my situation, Cambium and Android clients were affected but Ubuntu Linux machines were not. A reboot solved the problem temporarily for now. Looking forward to there reply.

For me the problem is with static addresses and seems to be connected with this option which sends offer even if there is no demand for it.
Converting dynamic address to static makes this option somehow "checked" even DHCP server has it "unchecked" so if you forgot to uncheck then static reservation broadcasts it.

Testing on RB2011 with 6.42.11

I wonder why I am facing it for such a simple change:

So I turned the IP assigned to my iPhone 7 to Static DHCP on Router.
Disabled WiFi & Enabled. It wont connect.
Even removed the WiFi by using Forget Network on iPhone. Still no go.

----------- Finally gave up and Disabled Static IP "Remove" and within seconds the Phone was back on using the previously assigned IP.

Whats with this attachment to previous IP?

Hello, an old topic, but it seems there is always some reason for this problem to occur again somewhere. So, I got it too. The problem appeared in a MikroTik only network with a recently installed CSS106-1G-4P-1S switch, upgraded to the latest available (at the moment of installation) version 2.11 of the SwOS.

So, in my case what happened was that the switch was working in DHCP with fallback mode and the warning messages were all over the log. When switched to DHCP only the entry stayed with "offered", the active IP was listed as corresponding to the offered IP, but the switch could not get the IP. No access therefore. No reboot or anything else helped. So, the culprit appeared to be a missing Src. Address value in the DHCP Server configuration entry in DHCP Server | DHCP. This led to the DHCP server IP being announced as the lowest IP assigned to the interface (bridge) where the DHCP server in question was running. After I enetred the IP of the DHCP network on this interface, the bind happend lightning fast. The DHCP server is running on a sturdy RB1100AH.

So, for some reason the CSS106 did not "like" that kind of misalignment. All other devices, including MT routers, PCs, mobile devices etc. were doing fine for years. So, I should assume this is some kind of strict checking "bug" in the SwOS. This is the place to say that as a MikroTik admin working with RouterOS for many years now, I am pretty disapointed with the SwOS and all the basic limitations it has like very very old school renowned swithes like 3Com, HP etc. But this is only if someone at MikroTik cares.

I still have this problem, A simple PPPoE conection (Default Script) and a 3 or 4 device

I still have this problem, A simple PPPoE conection (Default Script) and a 3 or 4 device

Hi, kapi, please elaborate. Is it your own PPPoE or you are a client of some ISP? Is the DHCP server in your control, since the topic implies it?

Same problem cAP ac Ros 6.46.4 , the bug still there

Solve simple upgrading to v6.47

Hi,

Having the same problem here. I have sent a support request to MikroTik about it. In my situation, Cambium and Android clients were affected but Ubuntu Linux machines were not. A reboot solved the problem temporarily for now. Looking forward to there reply.

Hi again,

Solution to this problem was to upgrade the Cambium firmware - no problems after that with either Cambium or the clients.


Sent from my iPhone using Tapatalk

Hi,

Having the same problem here. I have sent a support request to MikroTik about it. In my situation, Cambium and Android clients were affected but Ubuntu Linux machines were not. A reboot solved the problem temporarily for now. Looking forward to there reply.

Hi again,

Solution to this problem was to upgrade the Cambium firmware - no problems after that with either Cambium or the clients.


Sent from my iPhone using Tapatalk

Facing this attachment to previous IP issue with iPhone 7 not Cambium. Whats the solution for this?

Also some Cisco switches with SmartPort enabled connected to the LAN that the Mikrotik DHCP is on can cause the "without success" issue with some devices.

Hi, any solution for this ? I recently encountered "DHCP offering lease without success" problem. DHCP server is running on vlan and providing IP address to wireless clients (mainly apple devices). I noticed that once the dhcp offering lease without success, the mac address of the device is not in the ARP list.

I find in the vast majority of cases where I see this message, it is because the VLAN is allowed in one direction but not the other. When bridge VLAN filtering is used, if there is a VLAN accidentally missing from the config on one device and ingress filtering is not enabled, it is possible to have VLAN traffic working in one direction only like that. Then the router gets the request (because that direction is working since ingress filtering is not enabled) but cannot reply (because that direction is not).

I’ve been plagued with this problem for a while with a few devices and with some info from this thread I think I’ve resolved by removing always-broadcast=“yes” from my static dhcp assignments after trying everything under the sun including removing STP/RSTP from my bridge with VLANs configured, etc.

It seems that at some point I had the always-broadcast=“yes” checked off as a default or the defaults changed on the discovered DHCP items before I made them static or I turned on this always-broadcast=“yes” at some point.

I thought at first it was Apple specific devices like my Mac book pro, iPad, iPhones, etc but when I encountered this yet again in the last week in my logs I googled and dug deeper and put 2 and 2 together after I decided to do a /export and saw all these always-broadcast=“yes” references and one person mentioning when converting via make-static that these issues showed up I didn’t have this checked off when I looked at the dhcp server setup but when I saw on the static leases I started to correlate

Hope this helps someone that comes across this after the pain I went through to get to this point


Now if Mikrotik could just make a router like the RB4011 that could support SFP GPON and SFP+ GPON at 1Gbps / 2.5Gbps / 5.0Gbps / 10Gbps and 40Gbps (LOL. ) then I would be able to sync at 2.5Gbps or 5Gbps for our Bell Fibe service here in Canada to get full bandwidth since my ISP goes to 1.5Gbps currently and the 1Gbps service regularly goes up to 1.1/1.2Gbps so leaving this on the floor. People are using 1Gbps SFP media converters which they can get approx 940/940 Mbps but some can only get 750-800. Alas my hEX RB750GR3 does seem powerful enough to get above 650-700Mbps either way with download slower because of sync speed apparently so 550-600.

I am hunting for a router to replace the hEX RB750GR3 and the RB4011 would be ideal as it can do up to 75% line speed of 10Gbps SFP with bridging/routing/firewall rules which would be more than I can foresee needing (7.5Gbps connection to home! ) at this time but alas no SFP GPON support and not clear if SFP+ GPON are supported if ISP changes to SFP+ GPON later this year. The CRS3xx series don’t seem powerful enough to route / bridge / filter any more than my hEX RB750GR3 as switches really should do this and I already have some TP Link smart switches that are adequate for this until I upgrade to 10G switches later but can do LAG for now

Alas my work on fixing the “DHCP offering lease without success” issue may go to waste if I can’t get a new router than keep up with multi gigabit internet via SFP/SFP+ GPON at 1/2.5/5/10/40Gbps sync as may have to look at new Ubiquiti solutions just as I was getting used to RouterOS and its flexibility. Alternatively may have to look at pfSense or Linux solutions which I believe RouterOS is based on

Come one Mikrotik looking for a solution especially since RB2011 apparently can see these SFP GPONs just not at 2.5Gbps but rather 1/1.25Gbps

From the Wiki Manual:IP/DHCP Server:

Warning: The always-broadcast parameter will dynamically change. For the initial DHCP discover/offer/request/ack cycle a broadcast MAC address is going to be used, for lease renewal (request and ack) an unicast MAC address will be used. In case the DHCP Server keeps receiving DHCP requests while DHCP offer has been sent, then the always-broadcast parameter will be turned on dynamically until the DHCP lease has been renewed successfully.

Hi my big problem RBD53G-5HacD2HnD (arm) v7.1beta firmware. I have 2 devices Yealink SIP-T19_E2 MAC address firstly 00:15:65:ХХ:ХХ:ХХ DHCP status offered
`but the devices Yealink SIP-T19_E2 MAC address firstly 80:5E:C0:ХХ:ХХ:ХХ status bound
I used default configuration & I'm not understand why you did this buggg????
please change firmware this not funy. I cannot fix this bug.
Please please

I find in the vast majority of cases where I see this message, it is because the VLAN is allowed in one direction but not the other. When bridge VLAN filtering is used, if there is a VLAN accidentally missing from the config on one device and ingress filtering is not enabled, it is possible to have VLAN traffic working in one direction only like that. Then the router gets the request (because that direction is working since ingress filtering is not enabled) but cannot reply (because that direction is not).

I love your answer.
I've been fighting this huge issue with the DHCP, tried everything, nothing worked. Your answer seems to throw some light fixing this problem.
But: I can't remember where, but I remember reading in the wiki that there was a way to "fix" the packet when it comes in without the tagged VLAN, can you remember how to do it?
I'm using an 4 EOC masters (with something like 30 slaves each) system combined with a CCR1036-12G-4S. Have 3 VLANS, 1 for managing, 1 for "customer access to the internet" and 1 more for printers (yeah, a little tricky setup here).
When I connect to one slave it works perfectly, but when I go to another one it "leases an ip for me", I receive it (in the host), but I loose forward capability: I can ping the gateway but nothing more. Some time after, I recover connection, but I loose it when I go again to other slave.

Sorry for my English. Waiting for answers. Thanks.

Sigh, Im still seeing this with 6.48.1.

Ive got a site with 17x cAP AC, CRS328 switches x9 and CCR1009 running the show. All top stuff.

So I was working on some other things while on site and noticed my phone and tablet struggling, phone was saying "Obtaining IP..." forever and client also came to find me saying he was having frequent occurrences where his devices appear to be connected to wifi but nothing works. I checked logs while my devices were having trouble I could see them associating with the wifi successfully but no message from DHCP sever. Another time I would get "Offering lease without success..".

So I decided to try a few things while I had the issue manifesting, Its been suggested as a fix in a few threads on this issue to change the bridge STP protocol mode to none but mixed reports about this as a permanent fix. So on the AP in that area I simply switched the bridge STP protocol mode from RTSP to none. After this both my devices connected quickly and got IP addresses. I switched back to RTSP and toggled the wifi on my devices and they reconnected again without any trouble.

So what does switching the bridge STP protocol mode do that fixes this issues temporarily? I changed nothing else.

This is such a troublesome issue and spoiling many of my sites, frequent calls from clients that the wifi isnt working. How is this not fixed yet?

When wireless interface has no clients connected, it toggles port state to "not running". When first client connects afterwards, interface state toggles to running. This in turn trips xSTP to check for loops and before check finishes, no traffic can pass that bridge port. Time necessary for these checks can be long enough so that wireless client disconnects, scans for APs and tries to connect again. Meanwhile wireless interface is "not running" long enough for bridge to change port state again. And xSTP checks start again. When you manualy disabled wireless on client and enabled it again, client probably reconnected fast enough and wlan interface did not toggle to "not running".

In this case perhaps best solution is to set disable-running-check=yes on wireless interfaces (read up in https://wiki.mikrotik.com/wiki/Manual:I ... e/Wireless).

I fixed it with two of my capacs! Replaced with Tplink EAP245.

@anav went fly-fishing to a pond. As no fish cared to bite, he fixed it by going to fish market instead.

Still a fish, even though it's probably old, rotten and stinks. :D

@mkx Plausible explanation. Does this still apply if I'm using capsman and local forwarding?

@mkx Plausible explanation. Does this still apply if I'm using capsman and local forwarding?

I'd expect it does, but I'm not sure.

Still a fish, even though it's probably old, rotten and stinks. :D

Au contraire, the fish procured was succulent and tasty and most satisfying, so much so I went back for more!
Before I would mess with unknown wifi settings.
IF as you describe, then the MT wifi design is so flawed, why is that functionality ( set disable-running-check=yes on wireless interfaces )
not turned OFF by default and furthermore why has not the wifi guru himself, "bpwl", not recommended this setting (if he has I missed it unfortunately)

why is that functionality ( set disable-running-check=yes on wireless interfaces ) not turned OFF by default and furthermore why has not the wifi guru himself, "bpwl", not recommended this setting (if he has I missed it unfortunately)

It's not turned off probably for the same reason bridge mode is not none by default. Both default settings make no sense in SOHO environment. The disable-running-check=yes is mostly benign by itself (I do remember complaints about it in the past though), but combined with xSTP on bridge it can create problems. I surely hope MT has good reasons to keep defaults on SOHO devices this way.

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).

Site was stable for a few days but I noticed the message again today in the logs even though all APs bridge protocol was set to none. Again I toggled the bridge for the particular AP, this time from none to STP, a few seconds later the device fully connected. So the 'none' setting on the APs bridge isnt a fix.

Any suggestions?

Site was stable for a few days but I noticed the message again today in the logs even though all APs bridge protocol was set to none. Again I toggled the bridge for the particular AP, this time from none to STP, a few seconds later the device fully connected. So the 'none' setting on the APs bridge isnt a fix.

Any suggestions?

Go through all of your switches and check the VLAN trunking configuration carefully for all switches and all ports. Most likely you are missing that VLAN that the wireless clients connect to on one of the ports of one of the switches that the traffic passes over. This will result in one way traffic so your DHCP server will get the request but the response won't get back. Changing STP settings is probably having the side effect of changing which port the traffic is flowing over and it is probably changing it from the improperly configured port to the properly configured one.

I checked all the switches and everything is as it should be. Also I think if there was a vlan missing there would be devices we couldn't reach which is not the case. Plus Im seeing this on sites that have no vLans.

I tried something else today which was to uncheck "Add ARP for leases" in the DHCP server settings, thinking that if the DHCP server adds an arp entry, necessary discovery of the route to the mac isnt happening. I observed that the DHCP lease table briefly shows "bound" for devices having trouble then reverts to "offered". Presumably once bound an entry gets made in the ARP table but apparently not removed when its detected that the device hasnt gotten its IP.

One device that was having trouble immediately got its IP once the entry was removed from the arp table - another clue to whats going on hopefully?

Some more information. Ive been trying all sorts to fix this including setting up RSTP priorities on the x9 Mikrotik 328 switches on this particular site, which didn't make any difference - but at least I now understand RSTP priorities.

What I noticed today was that while a device was having trouble, I connected to the particular AP by winbox to check the debug logging I enabled. As soon as I connected the device that had been having trouble for 20mins was suddenly able to connect. I also noticed timeout messages in the AP log for CAPsMAN communication.

This got me thinking about how the AP's connect to CAPsMAN which is presently by MAC. Perhaps because theres no IP traffic when there are no devices connected the MAC route back to the router running CAPsMAN is expiring. Although this cant be completely true because I am able to see devices associated in the registration table and also able to remove them which occasionally can allow a device to reassociate and get an IP. So its not cut and dry.

So I have switched all the AP's over to connect to CAPsMAN by IP and we will see what happens. The issue is daily so I'll know very soon.

Update. I think I may well have a faulty cAP AC.

After fixing a couple of RJ45 type issues (found 2 APs running at 100M instead of 1G) and being surprised to still be seeing "offering without success" messages, I checked the logs by filtering on MAC address and noticed that the remaining messages were all for the same AP, so Ive swapped it with another from a seldom used area.

There are no other signs of and kind of fault, other than in a system of 15x cAP AC, only one is now exhibiting this issue. I don't have definitive evidence whether or not any of the other things Ive tried have helped but I believe I had seen less messages.

I'll check again in a day or two and report results.

Ran into the same issue when run more than one DHCP client on the linux box:

When you start these clients one at a time, do they get a different IP address and do they get registered in the DNS server with different client IDs?
If not, it is not going to work when you start them together. When MAC address is the only key, you cannot have two clients on the same machine!

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" (viewtopic.php?f=7&t=171800#p840171 ) 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 . (viewtopic.php?f=2&t=116963)

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 .... .

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.

Well, that is not really how it works. A DHCP client sends a DISCOVER message and the DHCP server comes back with an OFFER with an IP address and some other parameters.
It inserts a new IP address in that OFFER and reserves it in the server, it then has state offered.
Now, the client must send a REQUEST for that address and the DHCP server answers with a REPLY and at that point the address is bound to the client.
When the client never makes a REQUEST, the reserved address times out after a short while and becomes available again.

In case of a WiFi link which is not operating in transparent mode, there are issues with this:
1. maybe the OFFER does not reach the client (as bpwl describes), then it does not make the REQUEST and everything fails
2. maybe the client did not include a unique ID in its request (this is optional), in that case the MAC address is used as a key for the client, and when a not-transparent WiFi link is used all MAC addresses are translated to the MAC of the AP (sort of NAT at MAC level) and DHCP cannot work.
That is also described by bpwl.

...
Now, the client must send a REQUEST for that address and the DHCP server answers with a REPLY and at that point the address is bound to the client.
...

Just for correctness sake, the server does not answer with a REPLY message, but with an ACK, aka Acknowledge.

Process is is called DORA, i.e. Discover, Offer, Request, Acknowledge

Yes, that is correct. Also maybe some other clarification: this procedure is actually by design, it is there to allow redundant DHCP servers.
When you have 2 DHCP servers on the same physical network, each with part of the available address space as a pool, the clients will send a DISCOVER and get two different OFFERs, each with a different IP. The client does a REQUEST to one of the servers (normally the first one to reply) and ignores the other OFFER.
So of course those offered addresses should time-out after some time and become available in the pool again.

Sorry , that test was a long time ago. But I see it was the DHCPOffer not reaching the client; viewtopic.php?f=2&t=116963#p734225
I did not build that test setup again, as using a different DHCP server was already a workaround, and since then all repeaters were replaced by MT "AP bridge/station bridge" combinations

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.

I found the issue on my site that was plagued with this.Maybe this is the problem for others too. See my post on the other thread...

viewtopic.php?f=2&t=116963#p855159

UPDATE: Sorry this did not fix it. The problem returns about the 4day mark. But added some more info and think Ive identified the underlying cause which I dont have a fix for other than to reset the radio. Read thread above for more details.

viewtopic.php?f=2&t=175068

I don't know what your hardware and software configs are but this took a lot of debugging for me and may be applicable to your respective situations.

Thread been going a long time...

For me, new iPad wouldn't connect with 6.48.3. DHCP server running on bridge. Turned off rstp and this fixed it.

I had very rare occurrences of this problem on our guest WiFi network and I think they were only caused by clients with marginal signal.
However, starting last friday there came more and more logs of this problem, all from Samsung client devices.
On this network the MikroTik DHCP server had the "Always broadcast" setting active, and when I switched that off everything came back to normal.
It looks like there might be a recent Samsung Android update that is incompatible with "Always broadcast".
(I enabled that some time ago because it fixed an issue on another network, but now I think it should not be enabled without need)

Hi,
I am puzzled by this issue for a long time and so far no solution. I have several vlan running on bridge and each vlan has its own dhcp server. Selecting STP protocal mode to "none" on bridge , and uncheck "Always Broadcast" on the dhcp server is not a cure. It still occurred from time to time and it is so annoying !
Curious though ,for such a long time, Mikrotik never explained why it happen and how to fix.

That is because it is not really a MikroTik issue. It is a combination of server, client, and the medium between them.

I believe there are various causes of this issue. All of the research and discoveries I've made about it are on the other thread I linked above.

In my case, it's specifically where the 5G radio crashes, but allows devices to associate but no traffic flows. Additionally the 5G radio transmits junk packets at about 10Mbps. It took a lot of time discovering all this which I won't get back.

Mikrotik starting to believe me, I think, maybe. I've sent them supouts every time it happens and even provided full access to a site plagued by it which to my disappointment they have not taken much advantage of.

Checked the log, this problem still exists, how to solve it, but it seems to have little effect.

Hello,

Maybe my situation can help.
My environment is Mikrotik as router and Unifi AP as AP. First problem appear around 26 May when i upgrade Unifi AP firmware from 4.3.28 to 5.43.36. I tried everything i could and finally decide to downgrade Unifi firmware back to 4.3.28, as my last hope. Surprisingly, everything back to good again. Maybe my experience can help. Cheers.

It can be caused by a configuration error in your Unifi system. E.g. you have enabled multicast/broadcast filtering in Unifi, either directly or because you enabled the auto optimizer, and you did not enter the MAC address of your MikroTik router in the exception list.
(you need to do that, it would add the MAC of the Ubiquiti router automatically but not when operating a mixed-vendor network)

When you update firmware, it may behave differently in this regard.

In my case the problem was caused by UniFi option in WiFi Networks section WiFi Band: Both. I think it is because one SSID is associated simultaneously with 2,4GHz and 5GHz band. In MT logs I noticed that this message only applied devices that support both bands. Problem is solved when WiFi Band is set to 2,4GHz.

"Interesting" thread.
Actually I'm facing the same issue. For me it's really primarily Apple devices which are running into that issue once in a while.

Turned on DHCP debug logging but all I see is
1. discover request from device
2. router sending offer
3. discover request from device
4. router sending 2nd offer
5. another discover request
6. router saying "3 offers in a row => forcing broadcast
7. another two discover/offer streams
8. router saying "5 offers in a row => no response, restarting with unicast

There is no bridge left with STP.
Wifi is strong (both devices have approximately 2 meters of distance).

This situation is annoying and I'm not sure when it started. Could be when I switched my CAPsMAN from central to local forwarding but this is just a guess.

Theres a number of causes but the one Im trying to chase down is where the 5G radio's crash. You can tell by looking for zero TX counters on the 5G radio interface on the AP, but active TX counter on the 2G radio interface. Basically broadcasts aren't making it to the radio, usually you can also sniff the wifi and see the 5G radio stuck transmitting junk packets at a high rate (10Mbps+). Ive tried A LOT of different configurations and firmwares but the problem wont go away.

• Devices can associate but not get an IP
• DHCP server sends replies but they dont make it out the radio
• Radio TX counters at zero (no broadcasts)
• Usually Apple devices affected.
• Toggling the interface in caps man is the only fix until next crash

So... Anyone care to offer some guidance since there are so many possible issues? It doesn't seem to be much more than an annoyance. Many of the possiblities I see above don't apply to my situation but honestly - some of them are over my head...... But that's how we learn, right? lol

We have a CCR 1009 (the newer one) with static externally facing IPs on ether 6 and DHCP on a 3 port bridge ether 2,4,and 5. These feed into a 24 port CSS on the first and last port which are bridged to be able to deliver DHCP for home users as well as statics for those who may require it.

The CSS has 6 ports in use for 5 UBNT sector antennas and a UBNT P2P that is picked up elsewhere, runs into a UBNT edgeswitch and provides for 3 more APs. All equipment beyond the switch is UBNT until the customer router which they own in most cases so they vary.

All was fine until I upgraded. Now I have this issue.

The log shows DHCP customers offering lease 10.X.X.X for 74:4d:XX:XX:XX:XX without success over and over in the log. Every 4 seconds.
The MAC displayed is the MAC of the ether 6 interface and it's being offered that internal IP of 10.x.x.x.

But ether 6 is a LAN port delivering the static IPs to the network......DHCP isn't (shouldn't be) available at all on ether 6!

I considered that a customer's device that should be statically assigned from the static pool is instead requesting a DHCP address. But that doesn't make sense. It is all merged in the switch and as designed, I have no problem putting new devices on and getting DHCP or static IPs. I can't figure out for the life of me why the DHCP server is trying to offer a lease to a port that is not on the bridge that is setup to allow use of static IP addresses.

I started thinking about a possible loop condition since those ports are separate in the router but come together in the switch. So my weak mental image is one of the DHCP port “seeing” the static port on the bridge as a separate device and attempting to give it a DHCP address and the port replying, "SAY WHAT? I'm broadcasting static IPs you fool!" …..At which point it tries again 4 seconds later.

Given that I didn't run into this until the upgrade I'm wondering if anyone has any ideas or at least a "where to go next" to suggest. I try really hard not to reboot this thing unless absolutely necessary because it's an hour away and these customers are very sensitive at the moment due to multiple fiber cuts and power outages that lasted more than 24 hours (our UPSs kept things going then for 6 hours!) and I always worry that something may have been changed incorrectly in the past and not show up until reboot and I'll find everyone angry as I drive out in the middle of the night to fix what I broke that was just a little annoying to me and could have been left alone.

Having customers connect a WiFi device in pseudobridge mode and then have several devices behind it requesting different IPs using DHCP is not really a supported configuration.
You will need to either run it in true bridge mode or have a local DHCP server on the client device that locally issues IPs, and then NATs them to a single IP requested on the WiFi link.

Pseudo bridge multiple DHCP clients may not be fully supported by standards, but it did work for years (until ROS 6.38) ?.

DHCP client sends its MAC address inside the DHCP request, and the DHCP server should use that MAC address that is only reachable via broadcast (unless the pseudobridge would do proxy-arp).
If unicast is used, or if the MAC address of the request packet is used, then it will not work.

Full broadcast requires MAC address ff:ff:ff:ff:ff:ff , and not the unicast MAC address, as ROS does now when doing DHCP broadcast.

I'm sorry if I wasn't more specific. This isn't using pseudobridge. Ubiquiti (UBNT) uses a proprietary TDMA protocol called Airmax which creates a transparent L2 bridge between the router & switch in the cabinet and the customer's routers.

Each DHCP customer router's WAN mac is handed an IP from the router DHCP pool on the bridge.

The ARP already shows the entire externally facing block of public static IPs. If I give a customer a static IP for their router they can reach it from outside our network. Otherwise this whole excercise is pointless. lol

For all practical purposes, there is nothing but cat6 cable from the CSS to the CPE......well, except they all converge into a lower number of ports. So more like them all converging into a switch and then into the CSS switch. And what I'm trying to figure out is why the router might be trying to assign a DHCP address to the port that is sertup to deliver static IP addresses.

I'm sorry if I wasn't more specific. This isn't using pseudobridge. Ubiquiti (UBNT) uses a proprietary TDMA protocol called Airmax which creates a transparent L2 bridge between the router & switch in the cabinet and the customer's routers.

I believed that as well until a couple of months ago... then I discovered that it really is NOT transparent, at least not fully transparent for VLANs (like a cable).
But unless you are running VLANs over those links (and have not yet told us, like other things you tell us only later...) this is probably not the reason for your DHCP issue.

Test with a CPE that is really connected via a cable, instead of this "Wifi cable", and see if you can reproduce the issue.

I'm not sure how I would test with a device. The DHCP and static port both cable into the CSS. The CSS cables to several APs and a P2P that combined distribute internet to the entire town.

The problem is that the router is continually trying to give a DHCP address to the mac of the port carrying the static IP addresses. I'm not sure what I could plug into a port that would change this. I may just buy a backup router and copy the config over and then we can test without breaking anyone. I was just hoping someone had run into this as well since it was an upgrade where it began.

What is "static port" in this story ? A port with a static (locally defined) IP address, or something else? A DHCP lease made static ?

What I experienced ....

The DHCP lease will fail when you assign a predefined ("made static") IP address to a DHCP client that already has the SAME IP address defined as local static address.

different strokes for diff folks, but on mine, this appears to be a problem when a network is not available or disconnected. I fixed this issue on mine by temporarily disabling the addresses that belong to the dhcp servers.

What is "static port" in this story ? A port with a static (locally defined) IP address, or something else? A DHCP lease made static ?

What I experienced ....

The DHCP lease will fail when you assign a predefined ("made static") IP address to a DHCP client that already has the SAME IP address defined as local static address.

I'm sorry if I didn't make this clear in the initial post. The router has a port (port 6) configured to provide a /24 (12.x.x.x) of static external IPs to end users if they wish to have a fixed public IP that isn't natted. Primarily businesses. next to that is a standalone service port. (5) Next to that is a 3 port bridge (4,3,2) delivering an internal /22 from the DHCP server using a 10.x range. There is only one port in use on the DHCP bridge at the moment. It goes into port 24 of the CSS. The /24 static pool is on port 6 goes into ports 1 of the css. port isolation is turned on and the ports in use on the switch other than 1 and 24 go into an AP. That allows us to provide both static and DHCP to any customer on the network.

But for some reason the bridge is trying to assign a DHCP lease to the MAC of port 1.

Hi (again),

this thread is quite mixed up with a lot of different things.
My issue seems to be of the kind of "mainly related to Apple devices". (I've seen it once with a Samsung mobile as well but very rarely.)

I'm really wondering how this can be an issue since 2018 w/o anyone (like Mikrotik) digging deeper. Apple devices are not that rare and Mikrotik is used in larger networks worldwide.
So is the DHCP server in RouterOS not really used by professionals so nobody cares? Or what is the reason? Would it help to contact Mikrotik support? Did others do that before? What was the outcome?
For me it seems that restarting the wireless interface fixes a "hanging" Apple device most of the time. Probably just because the device connects to another AP.

Did you already experiment with the bridge protocol, disable-running-check, always broadcast, and lease time settings as discussed above?

Agree, this thread has a lot of different issues that cause "DHCP without success". I might start a entirely new thread for mine which is the 5G radio crash resulting in broadcasts not being forwarded to wireless clients. In My case DHCP server is working as it should and I am running 3 on vlans. Wired clients never have any issues.

By the way I have had a support ticket in since March 2021 and made a new ticket specifically for the 5G radio crash but still zero response from Mikrotik which is shockingly bad support.

Hi (again),

this thread is quite mixed up with a lot of different things.
My issue seems to be of the kind of "mainly related to Apple devices". (I've seen it once with a Samsung mobile as well but very rarely.)

I'm really wondering how this can be an issue since 2018 w/o anyone (like Mikrotik) digging deeper. Apple devices are not that rare and Mikrotik is used in larger networks worldwide.
So is the DHCP server in RouterOS not really used by professionals so nobody cares? Or what is the reason? Would it help to contact Mikrotik support? Did others do that before? What was the outcome?
For me it seems that restarting the wireless interface fixes a "hanging" Apple device most of the time. Probably just because the device connects to another AP.

Same experience here.

Did you already experiment with the bridge protocol, disable-running-check, always broadcast, and lease time settings as discussed above?

I experimented a bit, yes.
- "always broadcast" - only seems relevant for static leases which is not my problem
- *STP is off on my bridges (so disable-running-check should not make a difference?)
- in comment #28 someone stated that when switching from local to capsman forwarding it was not an issue anymore. I did that today to see if my cases are solved (still in case that is the reason something is still broken)

So I need to wait a bit until I see if point 3 fixed it for me.

Well, I solved my mystery on total accident..... I clicked "Allow Dual Stack Queue" and toggled it off and saved it. I was on the phone and wasn't paying attention. I turned it back on as it had been and saved it again......And now it has stopped....No clue why.

So what did you do actually? The option "Allow Dual Stack Queue" was unchecked in your case, you checked it and this solved the problem? Or the option was checked, you unchecked it and this was the solution?

Another successful story.

Same issue with Mikrotik RB951G-2HnD (v6.49) and IPTV box "Movix Pro Voice ZTE" (AKA "ZXV10 B867RE").

A IPTV box is connected through a wire to ether2 on RB951G-2HnD, the port is not a part of bridge, DHCP server binded to ether2.

It didn’t receive IP config from DHCP server 98% times per day, every 10 minutes DHCP server on RB951G-2HnD wrote in log "DHCP offering lease without success", but 2-3 times per day the lease has been renewed successfully. Through wireless connection is all OK and IPTV box got lease without problem.

First try: change a network topology - because RB951G-2HnD was connected to hAP AC² (v6.49), I'm passthru this ether2 via VLAN to hAP AC², but DHCP server on it also began writing "... without success".

Second try: rolling back topology and put a dumb D-Link DES-1008D switch between IPTV box and RB951G-2HnD. Wonderful, it's worked! More than a month all worked nice.

Of course, before I'm try to change a cables (straight through and crossover, 4- and 8-wire), negotiation, advertise, a port on RB951G-2HnD from ether2 to ether3..5 - but still no luck without dumb DES-1008D between client and router. Direct wired connection a IPTV box to hAP AC² also worked.

Physically ethernet interface status on RB951G-2HnD is 100MB/s full duplex (IPTV box have only 100MB/s port), D-Link DES-1008D is a 100MB/s 8-port switch.
It's seems like hardware issue on RB951G-2HnD with 100MB/s clients, but there are no another RB951G-2HnD unit for try to replace it.

Are you sure you have the bridge STP protocol set to "none", not one of the STP variants?

I have 4 Mikrotik devices.
One Router with DHCP Server that acts as CAPsMAN master and 3 others that act just as access points.
All FW versions are 7.1.1. Some days ago ALL Mikrotik Access Points stopped receiving IP addresses from the main device.
Log is full of All other devices on the network get IP addresses without any problems.

So looks like DHCP does not work between Mikrotiks only for me.

So what did you do actually? The option "Allow Dual Stack Queue" was unchecked in your case, you checked it and this solved the problem? Or the option was checked, you unchecked it and this was the solution?

I just now saw this when I had to restore a backup from before when this was a problem. I unchecked it and rechecked it, meaning it was already checked.
Unfortunately I've upgraded the version since then which is really the only difference that I can think of and now it won't go away like that. Scratching my head and wondering why it's trying to assign itself an IP to a port and refusing itself so it keeps trying. Trying the same thing over and over, expecting a different result. I think that makes my router insane.
it's a CCR 1009 bunchanumbersindicatingthe currentversion .

I have the same issue with new Xerox Versalink printers.
Affected models: C7025; B405
MAC: 9C:93:4E:XX:XX:XX

Update:
Problem fixed.
At DHCP Server->Networks->DHCP Options removed all entries (i've used for time zone offset and NTP server)

I'm having this issue with my Windows desktop (Intel I211 NIC), I created a reservation for multiple clients (from total 24), and only this one causes this warning. It may be Ok for several days and then it re-appears.
DHCP server has minimal configuration, RouterOS 7 (was stable, now test branches), RB5009UG+S+. PC is connected directly to the router by UTP6.
It seems it doesn't affect my PC, I haven't had any connection issues, though.

This occurred to me on a clean netinstall of 7.2.3 – The client “rejected” the IP.

It occurred when I changed a static IP lease from one to another. I fixed it on the client by “forgetting” the Wi-Fi AP and re-connecting.

Weird.

Im still seeing this issue even on 7.5.

I previously said it only effects 5G radios but Ive seen it on 2G radios too. I think the reason for this is simply that 5G radios are the busiest where mostly modern devices exist. On one site I created a 2G only network for smart devices. I then started seeing the issue on 2G radios with the usual zero TX counters and client report smart devices offline.

I have also noted a correlation between this happening to radios experiencing a lot of connection attempts from clients with poor signal even though I have access rules for -75db and above. A lot of smart devices do not have smart roaming capability and will simply try to connect to the first access point they see even if there is one with better signal, resulting in unrelenting connection attempts.

Im wondering if this particular cause of DHCP without success, where the radios stop transmitting broadcasts but still allow clients to associate - is caused by a software issue in the Multicast-Helper. This feature sits between broadcast packets and the radio transmit so its perfectly feasible that it crashes and no longer forwards broadcasts. Ive also seen that when it gets in this condition the radio transmits junk packets at a high rate (10Mbps) and examining the packets they appear to be repeats of old broadcasts like a buffer that's not been cleared.

I just wish Mikrotik would acknowledge this problem. It spoils an otherwise good wifi product.

I'm wondering about turning multicast helper off to see if the problem goes away, but it seems like the helper is quite essential?

After 122 days of running my CCR1009, the same problem occurs. Strangely, not all terminals fail to get ip addresses.
The last time it happened was the last time. I made all the tweaks (including replacing the ap) that I thought the problem was gone.

Long terms thread...

I've got the same issue recently. Tried everything above mentioned - nothing worked.

But then I change operation mode in my repeater from WDS to Access Point and magic happened - issue disappeared and everything started working as it supposed to.
Not sure if it will work for others, but it's worth of consideration.

All the best.

DHCP Offering Lease Without Success

most the time is a simptom of a problem in access network, some times not even related to the router

frequently is a simptom of wireless or wired network issues, not a router failure, most the time router is not culprit

dont shoot the messenger...

Confirming the same issue persists in 7.9. Five years since 2018, when it started happening to people.

Similarly to others, changing "something", like assigning Admin MAC to the bridge, or turning off RSTP, or anything else on this thread, does restart wireless interfaces (since they're managed by CAPsMAN), and everything works for a while, until suddenly it will appear again. In my case, many devices just won't connect and fail to obtain an IP address.

This seems to be the reason why there are so many "solutions" to this problem, whereas none of these are actual solutions. They just restart the interface. That's the solution. And the problem is unpredictable instability of wireless that will manifest itself this way, which requires a restart - like Windows computers in 2000's.

I wonder why this is not recognized as a major issue by the vendor, given the number of people who complained about it, and the persistence of the issue.

After sequentially trying all suggestions in this and other threads, I am observing problems still. Symptoms are:

- After any change to DHCP configuration, the problem goes away
- After a few days, absolutely at random time, clients start to fail to obtain DHCP
- Reboot or any other change (positioned as a solution suggestion such as in this thread) will restart something in ROS and things will get to normal - for a few days

Started happening somewhere after one of the recent updates, for me - 7.9.

I'd caught the same issue after upgraded the x86 router from 7.11.2 to 7.13.1.
Nothing had been changed in the ROS config and/or the switches.

We are experiencing the same issue while using bridge-work, bridge-guest, dhcp-work, dhcp-guest for Capsman and 3 APs. It works for about 2-3 days and then we see a lot "DHCP Offering Lease Without Success" in the log. The same result for another site with 2 APs. At the moment we use scheduler and /system reboot once per day.