Masked MAC address belongs to a mikrotik CPE (SXT 5 lite).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.
Hi ArceeI 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.
Such postings are not very useful, except maybe to relieve you from some stress or frustration.
This option somehow "checked" even DHCP server has it "unchecked" so if you forgot to uncheck then static reservation broadcasts it.
Does not help ... no change .. still receiving warnings
STP is OFFHave you tried disabling STP on bridge? And did you report this issue to support?
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
/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
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
I wonder why I am facing it for such a simple change: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
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?I still have this problem, A simple PPPoE conection (Default Script) and a 3 or 4 device![]()
Hi again,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.
Facing this attachment to previous IP issue with iPhone 7 not Cambium. Whats the solution for this?Hi again,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.
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
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.
I love your answer.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).
@mkx Plausible explanation. Does this still apply if I'm using capsman and local forwarding?
Au contraire, the fish procured was succulent and tasty and most satisfying, so much so I went back for more!Still a fish, even though it's probably old, rotten and stinks. :D
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)
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.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?