DHCP Offering Lease Without Success

Arcee · Mon Jan 29, 2018 1:38 pm

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.

pe1chl · Mon Jan 29, 2018 2:17 pm

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.

Arcee · Mon Jan 29, 2018 3:24 pm

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

pe1chl · Mon Jan 29, 2018 4:00 pm

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

Arcee · Mon Jan 29, 2018 8:13 pm

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.

danav38 · Wed Oct 17, 2018 2:26 pm

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

Bivvy · Fri Nov 30, 2018 8:56 am

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

Redmor · Sat Dec 01, 2018 4:10 pm

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

FErArg · Thu Dec 27, 2018 5:35 pm

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.

pe1chl · Fri Dec 28, 2018 4:00 pm

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.

MaxPavlov · Sun Jan 20, 2019 3:11 pm

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

WeWiNet · Wed Jan 30, 2019 2:05 pm

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

pe1chl · Wed Jan 30, 2019 2:19 pm

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.

Mon Feb 11, 2019 4:31 pm

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

pcunite · Mon Feb 11, 2019 5:22 pm

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?

Mon Feb 11, 2019 5:34 pm

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.

Fri Feb 15, 2019 12:59 pm

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

pcunite · Fri Feb 15, 2019 3:02 pm

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

Same for me, issue still remains.

Fri Feb 15, 2019 3:44 pm

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.

fyfyl · Wed Mar 06, 2019 5:00 pm

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

nescafe2002 · Wed Mar 06, 2019 7:31 pm

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

fyfyl · Thu Mar 07, 2019 12:02 pm

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.

solar77 · Fri Mar 22, 2019 10:50 am

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?

pe1chl · Fri Mar 22, 2019 11:54 am

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.

solar77 · Fri Mar 22, 2019 11:56 am

@ 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?

03:51:09 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:51:09 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:51:12 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:51:12 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:51:14 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:51:14 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:51:16 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:51:16 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:51:18 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:51:18 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:51:19 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:51:20 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:52:06 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:52:06 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:52:09 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:52:09 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:52:11 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
03:52:11 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
03:55:53 dhcp,info dhcp1 deassigned 172.16.8.8 from 58:2F:40:D0:7C:FF 
03:55:53 dhcp,info dhcp1 assigned 172.16.8.8 to 58:2F:40:D0:7C:FF 
04:34:13 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
04:34:13 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
04:34:15 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
04:34:16 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
04:34:17 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
04:34:18 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
04:34:19 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
04:34:19 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
04:34:21 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
04:34:21 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
04:34:23 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
04:34:23 dhcp,info dhcp1 assigned 172.16.8.62 to A4:38:CC:XX:XX:XX 
04:34:25 dhcp,info dhcp1 deassigned 172.16.8.62 from A4:38:CC:XX:XX:XX 
04:34:56 dhcp,warning dhcp1 offering lease 172.16.8.62 for A4:38:CC:XX:XX:XX without success

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

solar77 · Fri Mar 22, 2019 1:55 pm

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.

/ip hotspot profile
set [ find default=yes ] login-by=cookie,http-chap,https name=" "
add hotspot-address=172.16.0.1 login-by=cookie,http-chap,https,http-pap name=hsprof1
/ip hotspot
add disabled=no idle-timeout=10m interface=bridge_local name=hotspot1 profile=hsprof1

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.

encorer · Sat Mar 23, 2019 10:51 pm

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

Mar/18/2019 18:04:56 dhcp,warning dhcp1 offering lease 192.168.50.5 for 60:6D:C7:E5:C9:8B without success
Mar/18/2019 18:05:17 dhcp,warning dhcp1 offering lease 192.168.50.5 for 60:6D:C7:E5:C9:8B without success
Mar/18/2019 18:05:46 dhcp,warning dhcp1 offering lease 192.168.50.12 for 74:C6:3B:51:4C:33 without success

m94646602 · Sun Apr 21, 2019 8:44 pm

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.

anuser · Sun May 19, 2019 10:06 am

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.

beyeriii · Fri May 24, 2019 4:48 am

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

m94646602 · Fri May 24, 2019 9:36 am

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

anuser · Wed Jul 03, 2019 10:16 pm

Any news? Has the situation improved for you?

jeandconte · Sun Sep 29, 2019 10:15 pm

I think I got the same issue. Any solution?

krafg · Mon Sep 30, 2019 3:13 am

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

Regards.

MartinFB · Wed Oct 02, 2019 4:25 am

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!

pe1chl · Wed Oct 02, 2019 1:48 pm

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

But hey, people keep trying it...

DHCP Offering Lease Without Success

DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Re: DHCP Offering Lease Without Success

Who is online