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