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?