ROS 6.38 serious DHCP server problem

hutsch · Mon Jan 16, 2017 9:16 pm

Hi all!

Just discovered a strange problem with the DHCP server running at RouterOS 6.38.x preventing another Mikrotik Accesspoint and wireless clients from geting an IP address and rendering them inoperable.

Problem:

Wireless clients on an access point (RB433 - no matter if 6.37.x or 6.38) do not get any DHCP address from the router (RB1200@ROS 6.38 or higher) and even not a dhcp client on the AP gets an address. However, the windows clients connected to the router over the same external switch get IPs assigned.
Router continuously reports: "dhcp1 offering lease 192.168.2.252 for [...] without success" for the DHCP client on the AP.
Wireless clients can register to the AP but don't get any IP.

Configuration:

Router RB1200 ---- <eth to office>---- Netgear Switch GS108 ----<eth>---- Accesspoint RB433.
DHCP server running on router (without problems and configuration changes for years now).

Accesspoint:
bridge1 configured with member port wlan1 and eth1,
dhcp client interface set to bridge1
No special filters. Also reset the AP configuration (System/Reset configuration) in case something was misconfigured - same results

Above configuration worked for some years now.

Tests and conclusion so far:

Downgrading to 6.37 and step-by-step upgrading to 6.37.1, 6.37.2, 6.37.3 and at least 6.38 i discovered that until 6.37.3 everything works fine.
I also tried different versions on the access point but the version here doesn't seem to matter.
ROS-6.38.1 on Accesspoint and ROS-6.37.3 on the router is the highest version pair that works with my configuration.

Any clues?

Regards,

Heiko

david123 · Tue Jan 17, 2017 8:45 am

Unfortunately no clues, but I encounter the same issue.
I found that disabling/enabling the dhcp-package or restarting the router can solve it (temporarily)

hutsch · Tue Jan 17, 2017 3:22 pm

Just tested bugfix release 6.37.4 - also working fine without DHCP problems.
@david123: restarting the router did not work for me. DHCP for Accesspoint and its wireless clients (as described in my OP) doesn't work from the start with 6.38.

Splash · Tue Jan 17, 2017 7:24 pm

I have to agree with this problem. Since version 6.38 the DHCP Service stops responding and no new IP addresses are issued/renewed. To resolve the problem, one has to disable and re-enable the DHCP service.

Both 6.38 and 6.38.1 are affected with this problem.

Before Restart: (Mitel Phone)

19:19:22 dhcp,warning DHCP offering lease 172.29.40.60 for 08:00:0F:8F:C0:0E without success

After Restart: (Mitel Phone)

19:19:22 dhcp,info DHCP assigned 172.29.40.60 to 08:00:0F:8F:C0:0E

Has anyone logged this with Mikrotik Support?

luki · Tue Jan 17, 2017 7:40 pm

I also have the same problem session stops on the DHCP offered. The problem is version 6.38 and higher. Version 6.37.4 is ok.

Splash · Tue Jan 17, 2017 8:28 pm

I have logged a support request and included a link to this topic. I hope more confirm this in the mean time.

XaTTa6bl4 · Tue Jan 17, 2017 8:50 pm

I also have the same problem session stops on the DHCP offered. The problem is version 6.38 and higher. Version 6.37.4 is ok.

All the same!

copacetic · Wed Jan 18, 2017 9:20 am

Hi

I have a similar problem, which I was about to post before I came across this thread. Heres the description nonetheless...maybe some of my findings are helpful:

Problem receiving DHCP addresses over a VLAN using latest RouterOS v6.38.1. First of all, here is my setup

RB951G-2HnD ------------- CRS125-24G-1S-2HnD (DHCP Srv) --------- [Internet]
172.20.20.2/24 172.20.20.1/24
172.20.22.2/24 172.20.22.1/24

Network 172.20.20.0/24 is my primary network on an untagged VLAN, coupled with an SSID named "unknown".
Network 172.20.22.0/24 is my guest network tagged with VLAN 2, coupled with an SSID named "guest".
A DHCP Server running on the CRS should serve both VLANs with IP addresses, but there is a problem with DHCP für VLAN2 (guest):
- WiFi Clients connected to the CRS SSID "unknown" receive IPs from 172.20.20.0/24
- WiFi Clients connected to the CRS SSID "guest" receive IPs from 172.20.22.0/24
- WiFi Clients connected to the RB951 SSID "unknown" receive IPs from 172.20.20.0/24
- WiFi Clients connected to the RB951 "guest" SSID do NOT receive IPs from the CRS at all

What I have found is the following:
- dhcp logs on the CRS show that the DHCP request is received and an IP from the correct pool is offered to the client
- packet sniffer on the CRS shows that the DHCP reply/offer is sent out on the correct VLAN to the correct MAC
- however: packet sniffer on RB951 shows DHCP request leaving the router, but no DHCP reply/offer is being received
- The problem occurs both ways, e.g. when I set up DHCP Server for VLAN 2 on the RB951 and connect to the guest SSID on the CRS
- at some point in the past it did work with this configuration. I did not notice it stopping to work.
- The connection between the two Mikrotik devices is over devolo powerline. But I have confirmed the problem when connecting the two devices directly
- I have not configured any L2 security/firewalling e.g. snooping or similar
- When I connect a client to the RB951 on the guest SSID and give the client a static IP in the 172.20.22.0/24 range, the client can connect properly.
So basic VLAN tagging seems to be working i.e. its a DHCP problem.
- I have rebooted the devices several times, but will try manually disable/enable the dhcp service.

As a workaround I have configured a split scope for VLAN2 on the CRS and RB951. I am happy to provide command outputs, but need the direct commands to enter, since I am not that familiar with the CLI. Since I am not home very often, it might take some time for me to reply.

Kind Regards

kielerjung · Wed Jan 18, 2017 9:43 pm

Same here.

Not all clients seem to be affected, only some.

Problem started with 6.38, 6.37.x works fine.

AM1 · Thu Jan 19, 2017 12:29 am

I had a problem with some VOIP hardware and DHCP on 6.38,

I fixed it by having the DHCP Authoritative setting to 'after 2s delay'.

Not sure if this is the same issue you are discussing.

Cheers

Psiho · Thu Jan 19, 2017 12:37 am

I had this problem http://forum.mikrotik.com/viewtopic.php ... 00#p576886. After third upgrade to 6.38 (for troubleshoot) the problem disappear ) Very strange

UPDATE!!!
Today RB951 was shutdowned by wire. After boot up problem occured again. Downgrade to 6.37.4 (bugfix) and all went to normal state. Awesome!

copacetic · Thu Jan 19, 2017 8:48 am

@kielerjung: At some point I had the issue that my Windows 10 client did not receive an IP, while my Android client did. But I cant say on which version that was. Right now on 6.38.1 none of the clients get an IP.

@AM1: the DHCP Authoritative setting 'after 2s delay' was already set in my case, so no luck

AlexeyIlinsky · Fri Jan 20, 2017 8:46 am

Try to add dhcp alert on that interface, maybe someone is running dhcp server too

TheWooder · Fri Jan 20, 2017 10:13 am

Hey,

same problem here. Since upgrading to RouterOS 6.38 the dhcp service runs unstable. It suddenly stops working and i see "dhcp offering lease without success" errors in the logs.

Marcus

luki · Fri Jan 20, 2017 11:03 am

Wireshark tested and writes above user COPACETIC. There is another DHCP server in network lan.

Fri Jan 20, 2017 11:48 am

Version 6.38 had an issue related to STP which was resolved in 6.38.1. Also 6.38 changelog included note which said, that all devices should be upgraded to latest version to implement proper STP functionality in network. Same goes for 6.38.1 We have not seen any actual issues in 6.38.1 version related to software. Usually some devices in network are not upgraded and that is the cause of DHCP problems.

haik01 · Fri Jan 20, 2017 12:28 pm

I had this also regarding the "offering DHCP address" but not receiving or accepting it.

Turned our that one of the people, had a very old printer, and bought a print server. But that print server had by default a DHCP server on board to set it up. But the client did not know this, and could not setup the server. And left it for the weekend.

And I had to figure out why the DHCP did not work correctly.

So check if you have a second (unknown) DHCP server running. Just disconnect all devices (physically) from the 1200, and start to connect one by one. And test it thoroughly before connecting the second port.

copacetic · Fri Jan 20, 2017 12:33 pm

I can confirm that both my devices are running v6.38.1, and that there is no other DHCP Server running in that VLAN. Like I stated, the problem always occurs with clients connected to the miktorik that bridges the DHCP request to the DHCP Server, and not the mikrotik device which actually is the DHCP Server.

luki · Fri Jan 20, 2017 1:39 pm

Maybe it was the conflict STP openwrt a mikrotik ??

RB951G-2HnD ver. 6.38.1 DHCP SERVER
3x port and WiFi AP port access VLAN 20
1x port WAN port access internet connect
1x port via RB260GS port trunk VLAN 10, VLAN 20, VLAN 30
DHCP is working - ethernet port and WiFi

RB260GS ver.1.17
1x port via RB951G-2HnD port trunk VLAN 10, VLAN 20, VLAN 30
1x port access VLAN 30
1x port via RB960PGS port trunk VLAN 10,VLAN 20
DHCP not tested

RB960PGS ver. 6.38.1
1x port via RB260GS port trunk VLAN 10, VLAN 20
1x port access VLAN 10
2x port access VLAN 20
1x port via WR1043ND port access VLAN 20
DHCP not tested

WR1043ND-openwrt by LUCI
1x port via RB960PGS port and WiFi AP port access VLAN 20
DHCP is not working - WiFi, Ethernet port not tested

peper · Fri Jan 20, 2017 11:13 pm

Confirm having issues with DHCP server in 6.38/6.38.1.

Device is CRS125-24G-1S-2HnD.

Problems affected at list one DHCP client.
It is a Virtual Machine with Windows Server 2008 R2.
VM is not able to get address assigned to it in the list of static DHCP leases.
Mikrotik log states:
"dhcp offering lease <ip address> for <MAC address> without success".

This VM is running inside physical Server (also with Windows Server 2008 R2).
Physical server gets address from the same DHCP static list just fine.

milizhang · Sat Jan 21, 2017 5:47 am

Same here - 6.38.1 no longer works with my Ubiquiti APs, while 6.37.4 works well. I think this is something that should be taken seriously.

arxdust · Sun Jan 22, 2017 5:53 pm

I have the same problem
750gr3 router (dhcp server), dhcp leases have static 192.168.1.5 ---> rb951 (1eth master port). In bridge = eth1 + wlan. DHCP client- bridge
after the update (6.38 or 6.38.1) - it works, but after the restart 951, is not getting ip ... The logs writes "dhcp, warning defconf offering lease 192.168.1.5 for D4: XX: 6D: XX 60 without success ". The other dhcp servers on the network do not have
Problem 6.38 and 6.38.1
6.37.4 all good

luki · Tue Jan 24, 2017 9:20 pm

For me the problem is Solved ROS 6.39rc17
wireless - apply broadcast bit to DHCP requests when using station-pseudobridge mode;
THX

UPDATE
After the restart after a few days the problem returned or version and 6.39rc17 and 6.39rc19 is also flawed.

kondrat · Tue Jan 24, 2017 11:15 pm

For me v6.39rc17 does not resolve the problem. My access point is rebooting/ isnt geting IP address. Logs:

defconf offering lease 192.168.1.254 for /mac/ without success.

Any chance to have it fixed? My AP is Asus EA-AC87 and router 750Gr3.

2frogs · Wed Jan 25, 2017 2:03 am

Version 6.38 had an issue related to STP which was resolved in 6.38.1. Also 6.38 changelog included note which said, that all devices should be upgraded to latest version to implement proper STP functionality in network. Same goes for 6.38.1 We have not seen any actual issues in 6.38.1 version related to software. Usually some devices in network are not upgraded and that is the cause of DHCP problems.

v6.39rc17 broke STP on my rb2011UiAS-2HnD, it makes the bridge root port the ether my DVR is on and will not pass traffic. I can remove that port from bridge, disable the ether, or set STP to none to start passing traffic again. I updated from v6.38rc46. The DVR is a Directv Genie (HR44/700) and has a pass-through ether (2 ports) which may actually be the cause. It had been working fine before the upgrade.

Also all 11 of my MT devices lost their admin-mac's, that had been set for their bridges, when they were updated.

ngv · Wed Jan 25, 2017 7:40 am

We are seeing this issues with version 6.38.1 as well. I have downgraded one of my test routers to 6.37.3 to see if it resolves.

15:37:55 dhcp,warning dhcp3 offering lease 10.225.119.50 for 74:D0:2B:8C:78:9D without success
15:38:25 dhcp,warning dhcp3 offering lease 10.225.119.50 for 74:D0:2B:8C:78:9D without success

kondrat · Wed Jan 25, 2017 10:59 am

We are seeing this issues with version 6.38.1 as well. I have downgraded one of my test routers to 6.37.3 to see if it resolves.

15:37:55 dhcp,warning dhcp3 offering lease 10.225.119.50 for 74:D0:2B:8C:78:9D without success
15:38:25 dhcp,warning dhcp3 offering lease 10.225.119.50 for 74:D0:2B:8C:78:9D without success

Same issue for me- 6.37.3, 6.38.1, 6.39rc17- all software versions have dhcp issues for me.

Wed Jan 25, 2017 2:52 pm

Please test 6.39rc19 or later version if possible. We have had another additional fix for specific bridge port configurations.
http://forum.mikrotik.com/viewtopic.php ... 50#p579856
http://mikrotik.com/download

CareySystems · Thu Jan 26, 2017 6:52 am

I can confirm the same DHCP server / pass through issue on the CRS125-24G-1S-2HnD-IN running 6.38.1. Our set up uses the CRS as a multi-VLAN switch and multi-SSID access point. The DHCP server is a Cisco RV220W connected through the CRS Eth1. The CRS was not able to receive (bind) any DHCP offers from the RV220W and was not passing them through to clients either. At first we thought this was a VLAN configuration issue, but it only appeared when we upgraded to 6.38.1. Then we found this forum chain and investigated further after 20+ hours of onsite troubleshooting in a campus environment with multiple wireless PTP links, etc.

After upgrading to 6.39 (testing) release, the problem did not exist anymore.

However, there seem to be some strange VLAN behavior with the VLAN setting for the WIFI interfaces. If you set "VLAN Mode" equal to "Use tag" and set the corresponding VLAN ID then the WLANs do not seem to pass any traffic even when bridged to VLAN interfaces that are connected to a physical interface/trunk interface such as Eth1.

For example:

Eth1
-> VLAN_2 (VLAN ID = 2)
-> VLAN_4 (VLAN ID = 4)

WLAN 1 (VLAN Mode = Use Tag, VLAN ID = 2)
WLAN 2 (VLAN Mode = Use Tag, VLAN ID = 4)

Bridge_VLAN2
Ports
VLAN_2
WLAN_1

Bridge_VLAN4
Ports
VLAN_4
WLAN_2

The above config doesn't pass DHCP from the DHCP server providing addresses to Eth1 on VLANs 2 (192.168.2.x) and 4 (192.168.4.x).

If you remove the bridges and just hope the VLANs "automatically" map between the WLANs and the VLAN interfaces configured on Eth1... no traffic gets passed. Not very surprising, but this leaves me wondering... what is that VLAN Mode and VLAN ID setting in the Wireless menu really for?

The only way this configuration works is if you set VLAN Mode = No Tag for WLAN_1 and WLAN_2, then everything works again. Because the bridges effectively map the wifi traffic to the VLAN interfaces on Eth1.

I could just have a fundamental misunderstanding of how the VLAN mode and VLAN ID work for the WLAN interfaces, but it does seem to break other stuff that it shouldn't.

Splash · Thu Jan 26, 2017 11:11 am

I have logged a support request and included a link to this topic. I hope more confirm this in the mean time.

Hello,

Sorry for delayed reply. Now we have fixed some bridging bugs from 6.38.x which could cause DHCP related problems and recommend upgrading to the latest v6.39rc.

Best regards,
Janis B.

--
MikroTik.com

luki · Thu Feb 02, 2017 10:11 am

Are you with the problem solved after 6.39rc20 ??

PanhandleIT · Thu Feb 02, 2017 6:31 pm

So, I upgraded several routers last night to 6.38.1. A hEx Lite and a CRS125 both had DHCP issues with Ubiquiti access points (both UAP/UAP-LR's and UAP-AC's). I rolled both of them back to 6.37.4 and troubles are gone.

Other locations that did not have issues included CRS125's (same exact model as the one with problems), RB2011L's, hEx's, and an hAP AC Lite. Many of these locations also have Ubiquiti AP's.

All access points were already updated to their latest firmware.

One thing that I noticed was that Unifi Discovery was reporting the AP IP address as "192.168.2.20?", putting a question mark for the last digit and it could not reach them to send commands. I didn't have any issues with any of the wired clients except for the APs.

MobileEMP · Fri Feb 03, 2017 8:23 pm

PanhandleIT, I can confirm that same issue with multiple UniFi AC-Lite access points using an RB3011. I thought I was going crazy for a while. I reset the config and dumped my script on multiple times to no avail. Glad I found this thread because everything is just fine on 6.37.4 (Bugfix).

Thanks everyone!

So, I upgraded several routers last night to 6.38.1. A hEx Lite and a CRS125 both had DHCP issues with Ubiquiti access points (both UAP/UAP-LR's and UAP-AC's). I rolled both of them back to 6.37.4 and troubles are gone.

Other locations that did not have issues included CRS125's (same exact model as the one with problems), RB2011L's, hEx's, and an hAP AC Lite. Many of these locations also have Ubiquiti AP's.

All access points were already updated to their latest firmware.

One thing that I noticed was that Unifi Discovery was reporting the AP IP address as "192.168.2.20?", putting a question mark for the last digit and it could not reach them to send commands. I didn't have any issues with any of the wired clients except for the APs.

gargola · Sun Feb 05, 2017 8:49 am

I was having the same issue with the "offering lease without success" for some customers.

It was happening with a RB1100AHx2, after several reboots and tshoot, they were remaining around 7 customers that couldn't get ip, all of them with routers TP-Link WR720N.

I Tested versions 6.38.1 and 6.39rc25 both of them having the same DHCP issue.

This is a quick note of my topology:

RB1100 -> Thoughswitch -> ubnt network (bridged) -> CPE (bridged) -> Home router (different brands). Yeah, I know, not the best of the topologies, I'm working in the new design to avoid bridges and broadcast.

I had to downgrade to version 6.36.4 and everything is back to normal.

sjennings · Fri Feb 17, 2017 7:52 am

I encountered this same issue. Opened the box with 6.37.1 and it worked. Upgraded to 6.38.1 and my UniFi AC LITE started dropping DHCP offers.

Did a packet trace of the DHCP OFFER 6.37.4 vs 6.38.1 and the 6.38.1 DHCP server sends the OFFER broadcast (mac ff:ff:ff:ff:ff:ff, ip 255.255.255.255, without the broadcast flag set in the flags) where 6.37.4 sends the OFFER unicast to the client that did the DISCOVER.

This is in violation of RFC 2131 4.1:

If the broadcast bit is not set and 'giaddr' is zero and
'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
messages to the client's hardware address and 'yiaddr' address.

KaZaN · Wed Feb 22, 2017 12:04 am

Same issue for my Unifi APs (and Edimax APs also) and to my wireless clients trying to connect via these APs with my RBs 750Gr3 using 6.38 , 6.38.1 and also in latest RC 6.39rc33 , only 6.37.4 bug fix helps to my RBs to get my DHCP servers back to work.

luki · Fri Feb 24, 2017 11:10 am

6.38.3 DHCP is still not working properly.
DEBUG

Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet VLAN20 received discover with id 1682309120 from 0.0.0.0
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet secs = 252
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet ciaddr = 0.0.0.0
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet chaddr = 9C:AD:97:52:55:C5
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet Msg-Type = discover
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet Client-Id = 01-9C-AD-97-52-55-C5
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet Host-Name = "BRW9CAD975255C5"
Feb 24 10:06:58 192.168.3.1 dhcp,debug,packet Parameter-List = Domain-Server,Router,Subnet-Mask,Domain-Name,Unknown(66),Unknown(67),Unknown(13),NETBIOS-Name-Server,Unknown(2),NTP-Server,Unknown(120),Unknown(125),Host-Name
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet VLAN20 sending offer with id 1682309120 to 192.168.3.28
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet ciaddr = 0.0.0.0
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet yiaddr = 192.168.3.28
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet siaddr = 192.168.3.1
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet chaddr = 9C:AD:97:52:55:C5
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Msg-Type = offer
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Server-Id = 192.168.3.1
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Address-Time = 86400
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Domain-Server = 192.168.3.1,192.168.4.2
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Router = 192.168.3.1
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet Subnet-Mask = 255.255.255.0
Feb 24 10:06:59 192.168.3.1 dhcp,debug,packet NTP-Server = 192.168.3.1,192.168.4.2

techmk · Sun Feb 26, 2017 12:46 pm

Hello!
We have similar problem. Mikrotik RB951 stops renewing IP address for some Wired / Wireless clients. Our workaround - backup DHCP scope on Access point.

jcmlanzas · Thu Mar 09, 2017 8:55 am

As far i could see, from client side (wireshark), DHCP packet is sent to the broadcast (Msg type: discover ) which Mikrotik device receive and send back a Msg Type: offer. Thing here (and tested several times) is either DHCP packet type (offer) is not sent correctly or is sent as ARP broadcast asking for assigned IP in the offer. In any case client does not receive DHCP packet msg type: offer but ARP broadcast from dhcp-server asking for offered IP instead.
So in that way, client sent again broadcast with discoveries DHCP packets until number of tries it has configured (usually three).
I have the dhcp server listening on a bridge interface so it is possible there are some issue relative to sending broadcast packets via bridge interfaces (on my scenario). Also possible some bug on DHCP server (misconfiguration for new version could be a possible as well) that don't really send offers packets via dhcp-server listening interface.
Exactly same configuration from both sides (client/server) work as expected on previous version 6.37.4.
Yesterday i updated to 6.38.4 but same results.
Edited: Just to clarify that from Mikrotik device side i ran a packet sniffer and both (packet snifer and wireshark) match on results here exposed.

snap87 · Thu Mar 09, 2017 9:22 am

Yes, I have this problem to. Work only for 6.37.4 version.

jcmlanzas · Thu Mar 09, 2017 4:33 pm

Further checks seem like a every minute:
15:00:09 dhcp,debug,packet dhcp-alert on bridge-vlan6 sending discover with id 351403283 to 255.255.255.255

15:00:09 dhcp,debug,packet secs = 64
15:00:09 dhcp,debug,packet ciaddr = 0.0.0.0
15:00:09 dhcp,debug,packet chaddr = 00:00:00:00:00:00
15:00:09 dhcp,debug,packet Msg-Type = discover
15:00:09 dhcp,debug,packet Client-Id = 01-00-00-00-00-00-00
15:00:09 dhcp,debug,packet Parameter-List = Subnet-Mask,Router,Domain-Server,Domain-Name,NETBIOS-Name-S
erver,Static-Route

Same message on 6.37.4 but the right MACs are shown con chaddr and Client-ID regarding to bridge-vlan6 MAC address.
Curiously on 6.38.4 i could maintain already assigned IP address once lease was assigned (*see bellow).
Moreover, other dhcp-server / bridge for wireless connections apparently works fine. Very weird thing.

* I meant i connected and HP laptop (Win7) via wired interface that didn't assign IP as described on my earlier post. I reloaded the router to 6.37.4 (previously configuration copied to its partition from recent 6.38.4 version);
DHCP lease was assigned and working when i was going to test something more with DHCP , then copy again config between partitions (this time from 6.37.4 to 6.38.4) . When device restarted on 6.38.4 version again, the dhcp server assigned correctly the IP (i'm still using it) so this a quite weird thing.
Anyway, i tried new devices and still the same issue.
Maybe that's the reason why some people could temporally work (until lease expired).
Hope this might help to do deeper test.

copacetic · Fri Mar 10, 2017 8:28 am

Problem was still present on 6.38.4 yesterday. Have not tried 6.38.5 yet,

ScottReed · Fri Mar 10, 2017 6:27 pm

Problem in v6.38.5 also. Upgraded a CCR1036 this morning per Mikrotik support request on another issue entirely. DHCP stopped working after the update.

Seeing "SERVER offering lease x.x.x.x without success" in log.

I disabled RSTP on the bridge interface and the issue appears to be resolved.

jcmlanzas · Sat Mar 11, 2017 6:05 pm

Problem in v6.38.5 also. Upgraded a CCR1036 this morning per Mikrotik support request on another issue entirely. DHCP stopped working after the update.

Seeing "SERVER offering lease x.x.x.x without success" in log.

I disabled RSTP on the bridge interface and the issue appears to be resolved.

I confirm the recovery of DHCP server assignment by the changing of any STP Protocol mode to another (maybe you might want to disable and re-enabled it again), so it seems a feasible workaround for me. But it is worth to mention that this just will work in the meantime the device is not rebooted in which case it has to be applied again.

ScottReed · Mon Mar 13, 2017 7:26 pm

But it is worth to mention that this just will work in the meantime the device is not rebooted in which case it has to be applied again.

This statement is correct. I had to reboot the affected router over the weekend and DHCP subsequently stopped working.

I've setup a 'startup' scheduled script to cycle the bridge interface.

sebus · Mon Mar 13, 2017 11:53 pm

That is a bugger... DHCP is rather useful...

Can you share the script?

sebus

sebus · Thu Mar 16, 2017 12:11 pm

Or are we likely to get the issue patched?

sebus

jcmlanzas · Thu Mar 16, 2017 2:11 pm

It seems to be patched on 6.39rc55

luki · Fri Mar 17, 2017 6:09 pm

Unfortunately, the version 6.39rc55 DHCP is not working properly. It is a pity that the Mikrotik long already solves this problem.

domgl · Mon Mar 20, 2017 12:35 pm

I have one RB951Ui-2HnD v6.27 and one RB450G v6.27, but IPSec hasn't work properly, that why I’ve upgraded them to 6.38.5. Now IPSec work very well, but DHCP server on RB951Ui-2HnD not quite good. PCs which MAC-IP addresses are NOT binding receive IP addressess, but these devices, which MAC-IP are binding NOT.

Restarting DHCP server works for me but is not solution. I seems to stop work properly after weekend (long time after IP releasing. My DHCP server Lease is set up to 5h).

morph · Mon Mar 20, 2017 10:57 pm

Just had this issue appear out of nowhere on 6.38.5.
It was working fine but suddenly it stopped issuing DHCP addresses to clients connected through my WiFi AP.
Disabling STP fixes the issue.

RackKing · Thu Mar 23, 2017 3:30 pm

I am now having the same issue after an upgrade - any update?

mdkberry · Sat Mar 25, 2017 1:04 am

I am having this problem on RB2011 connecting to an AP RB922AUG the AP is not returning the DHCP handshake in some way or cannot get it through.
logs show up on the RB2011 showing error "dhcp_wireless offering lease xxxxx without success"

This started happening right after reboot after upgrade from 6.35.5 on both devices to 6.38.5

I have tried adding in static ip but I still cannot properly reach the AP device to manage it either.

From this thread it is clear the issue has been on going for a few months but can't be universal which is even odder, maybe it is the hardware model numbers effected by the 6.38.x versions in someway. I have logged ticket with support directly but going to downgrade to 6.37.4 and hope that works. My clients come into work on Monday and no DHCP is going to be the end of the world. Cant believe this is not fixed since January! what is going on?

mdkberry · Sat Mar 25, 2017 3:17 am

ok this is my bodge work around (not confirmed whether this works with wireless devices as yet, only worked for the RB922AUG AP device. I wont know until after the weekend if the clients have problems getting new DHCP leases. Old leases seem to be mostly ok, new ones fail. I am hoping this bodge will last until I can downgrade the devices to 6.37.4 or Support come up with a fix)

1. On the main router RB2011 I went into the wireless Bridge and disabled the RSTP , set it to none. (I have no idea what impact this will have on the multiple scope DHCPs or risks of network flooding) I lost browser access and terminal access as the RB2011 hung for about 4 minutes, but luckily the VPN connection stayed up. the RB2011 stayed pingable in that time too.

2. when it came responsive again (without being rebooted) the AP miraculously picked up an IP address from the RB2011 DHCP server. I rebooted the AP and it picked it up again , so I am hopeful that Monday will be ok when everyone gets on the wifi network. Interestingly the RB2011 wireless bridge says rstp is enabled so maybe just freaking it out by trying to disable it, is enough to sort the problem out before the next time it reboots because....

3. I rebooted the RB2011 and once again everything stopped working so I had to repeat the above process.

mdkberry · Sat Mar 25, 2017 1:15 pm

thanks to user Tulluk on Reddit where I also posted this issue, it seem there is a fix for this,

in the bridge settings on the RB2011 set the 'admin MAC' of the wireless bridge0 to be the same as its actual MAC. This results in the DHCP packets having the right source MAC for return from the AP device. no need to change anything else, nor disable the STP. Everything also worked on reboot.

n3120 · Tue Mar 28, 2017 4:00 pm

Hi all,
Today I upgraded my RB450G from 6.37.x to 6.38.5, and I got the same problem: wireless clients are not able to join Wi-Fi.
After reading this post, I tried to set the protocol mode of bridge1 from RSTP to STP, and it works!!!
It's located at Bridge -> bridge1 -> STP -> Protocol Mode
Hope this helps!

cszolee79 · Fri Mar 31, 2017 1:01 pm

Same here.

hEX (RB750Gr3), ROS 6.38.5, Windows clients get DHCP, but UniFi AP and any client connected to AP do not.
Also, connected an RB951G-2HnD, and it gets DHCP IP on ether1, but not on ether2, wtf???

Same RB951G-2HnD with 6.38.5 works, all clients get DHCP (including UniFi AP and mobile clients).
We have a LOT of Tiks all around, all 6.38.5 now (many having UniFi APs), and the problem only happened with this particular hEX.
It was the same with 6.38.3 and the hEX.

pe1chl · Fri Mar 31, 2017 1:54 pm

Read the other posts before complaining!
Workarounds presented are:
- turn off RSTP
- enter an admin-MAC
It may well be that all your other routers had one of these already in place

cszolee79 · Fri Mar 31, 2017 2:17 pm

We read it and then complain as it is our right, and the correct way to report problems so Mikrotik can fix them.
It is a serious bug that never happened in the 6-7 years I've been working with Mikrotik devices (especially considering it only happens on some random routers it seems while others work).

lukasb · Sun Apr 02, 2017 11:58 am

I've encountered this problem also - a lot of users got stuck at DHCP offer and the log says dhcp offering to xxxx without success.

ROS 6.37.5 Bugfix release.

I've run the DHCP Server on physical interface port, not to a bridge interface & not running any kind of STP in my network

reefman · Tue Apr 04, 2017 2:40 pm

RouterBOARD 750G r3
Rollback 6.37.4 (bugfix) did not help

dhcp offering lease

kielerjung · Tue Apr 11, 2017 12:23 pm

I've updated my RB2011 to 6.38.5.

Setting the administrative MAC on the bridge-interfaces helped with this dhcp-problem.

Rey46 · Tue Apr 11, 2017 8:33 pm

I've updated my RB2011 to 6.38.5.

Setting the administrative MAC on the bridge-interfaces helped with this dhcp-problem.

I also upgrade to 6.38.5 and I had this issue, I went to System -> Package List and click "downgrade" selecting nothing.. I'm still on 6.38.5.. Maybe it reinstall the package but at the moment the problem there isn't. Could you explain more regardin the admin-mac? What mac I have to put in case this problem come out again? Thanks

kielerjung · Tue Apr 11, 2017 9:38 pm

See post of mdkberry (viewtopic.php?p=593272#p590626) above:

in the bridge settings on the RB2011 set the 'admin MAC' of the wireless bridge0 to be the same as its actual MAC. This results in the DHCP packets having the right source MAC for return from the AP device. no need to change anything else, nor disable the STP. Everything also worked on reboot.

(Kudos to tulluk on reddit: https://www.reddit.com/r/mikrotik/comme ... e_to_6385/)

Kindis · Wed Apr 12, 2017 9:09 am

I've updated my RB2011 to 6.38.5.

Setting the administrative MAC on the bridge-interfaces helped with this dhcp-problem.
I also upgrade to 6.38.5 and I had this issue, I went to System -> Package List and click "downgrade" selecting nothing.. I'm still on 6.38.5.. Maybe it reinstall the package but at the moment the problem there isn't. Could you explain more regardin the admin-mac? What mac I have to put in case this problem come out again? Thanks

To downgrade you need to download the release you which to "walk back to" and put the files on the router. Then click downgrade.
https://mikrotik.com/download/archive

Rey46 · Thu Apr 13, 2017 6:18 pm

See post of mdkberry (viewtopic.php?p=593272#p590626) above:

in the bridge settings on the RB2011 set the 'admin MAC' of the wireless bridge0 to be the same as its actual MAC. This results in the DHCP packets having the right source MAC for return from the AP device. no need to change anything else, nor disable the STP. Everything also worked on reboot.
(Kudos to tulluk on reddit: https://www.reddit.com/r/mikrotik/comme ... e_to_6385/)

Sorry but I'm italian and I don't understand exactly. I have my modem connected to port #1, port#4 there is connected a switch, from this switch there are connected 4 AP. My wlan1 is disabled. Which mac should i put?

kielerjung · Thu Apr 13, 2017 8:14 pm

On bridge "Internal" put MAC "4C:..." also into the field "Admin. MAC Address".

Please make sure, that your dhcp-service is bound to that bridge (IP->DHCP Server, look at "Interface").

Rey46 · Thu Apr 13, 2017 8:31 pm

On bridge "Internal" put MAC "4C:..." also into the field "Admin. MAC Address".

Done.

Please make sure, that your dhcp-service is bound to that bridge (IP->DHCP Server, look at "Interface").

Yes, hope it works.

Rey46 · Thu Apr 13, 2017 10:41 pm

At the moment I still have this issue in another location.. Anyone could help me?

RB951G-2HnD
Port #1: Pppoe client
Port #2: My-pc
Wlan1: Enabled wifi.

Krisken · Sat Apr 22, 2017 10:02 pm

I have exactly the same error on a RB3011 running ROS 6.37.5? Should be a stable release? Fixing the problem can be done the same way as described?

morph · Sun Apr 30, 2017 11:07 am

And again the same problem with 6.39.

pe1chl · Sun Apr 30, 2017 11:59 am

And again the same problem with 6.39.

What do you mean with "the same problem" as people are discussing different problems here...

morph · Sun Apr 30, 2017 5:26 pm

And again the same problem with 6.39.
What do you mean with "the same problem" as people are discussing different problems here...

DHCP server does not work unless you disable STP.

pe1chl · Sun Apr 30, 2017 5:38 pm

Even when you set a MAC address on the bridge?

michalsz2 · Tue May 09, 2017 4:22 pm

Adding Admin MAC resolved the issue for me, Thank You

mikronsultiK · Mon May 15, 2017 6:37 pm

Hi there

even on a 6.39.1 Installation the issue was occurring.

Solved configuring Admin Mac and disbaling /enabling rstp protocol.

thanks

jKonstantin · Tue Jun 13, 2017 7:50 am

rb750gr3 try this metod, dhcp not work with wifi ap clients.

timonlio · Sat Jun 24, 2017 7:43 am

Got the same issue when I upgrade my RB750Gr2 from 6.37.5 to 6.38.7, the AP hAP AC Lite failed to assign IP address any more.

pe1chl · Sat Jun 24, 2017 11:36 am

Got the same issue when I upgrade my RB750Gr2 from 6.37.5 to 6.38.7, the AP hAP AC Lite failed to assign IP address any more.

In general, or only to one single device that you tested?

wfuzatto · Sat Jul 08, 2017 8:43 pm

I got a similar problem, but using hotspot. The handshake could not be finished in a good time.
MK: CRS125
V: 6.39.2
Ap's: UniFi AC Lite

This problem shows up when the client roam between the AP's.

timonlio · Wed Jul 26, 2017 3:00 pm

Got the same issue when I upgrade my RB750Gr2 from 6.37.5 to 6.38.7, the AP hAP AC Lite failed to assign IP address any more.
In general, or only to one single device that you tested?

I have a hAP AC Lite, and a Linksys EA6500v2 working in AP mode, both device failed to obtain ip from dhcp server, after I upgrade hEX to 6.38.7 and reboot the device.
Finally, disable the STP and enable the STP on bridge1 on hEX works for me.

radekmacek · Tue Jan 30, 2018 9:29 am

Hello, I have the same problem in version 6.40.5. Client device that is responding to DHCP offer is sending message with ciaddr = 0.0.0.0 over and over. 10m lease time and every 10s is device trying to get new IP address. Same device in another port of a switch gets IP alright.

As per changelog for version 6.40 this should have been repaired:
*) dhcpv4-server - fixed lease renew for DHCP clients that sends renewal with "ciaddr = 0.0.0.0";

First started in 6.38.5 -> 6.39.3 -> 6.40.5. Every version has the same problem. I don't want to upgade to 6.41 yet. Propably will try downgrade to 6.37.5 as per post above.

Adding sniffed traffic fyi:

0.0.0.0_src_DHCP_problem.PNG

radekmacek · Wed Jan 31, 2018 2:42 pm

Hello, downgrade to 6.37.5 was not succesfull for me as CCR1036 is not possible to downgrade below 6.38.5. I have put 6.41 instead and problem stil exists.

pe1chl · Wed Jan 31, 2018 5:15 pm

Try setting a longer leasetime. Some devices have bugs and do not want to accept such a short leasetime.
Try 1h or more.

radekmacek · Thu Feb 08, 2018 11:52 am

Hello, found the root cause of the problem. In my case it was caused by dhcp snooping and max number of clients. For some reason maximum number of clients is 16 or 10 for edge-core, depends on the type of switch. Mikrotik is working correctly in my examle above.
Hope this helps someone.

rvilanov · Thu Aug 23, 2018 6:45 pm

This error is still happening on 6.42.7. Sundelly, the gateway stops to answer and all the dhcp users are getting offering lease whithout sucess.

mbarchiesi · Wed Oct 31, 2018 8:52 am

When Mikrotik will repair this issue????? This is not a less-meaning problem! Its huge! Come on guys! Even TP-Link doesn’t have problems like this! We are on 6.4x and you dont do anything yet!

Chupaka · Wed Oct 31, 2018 10:01 am

If you have a problem — what's your ticket number? (C)

Have you written to support@mikrotik.com?

bpwl · Tue Jun 04, 2019 10:24 pm

As far i could see, from client side (wireshark), DHCP packet is sent to the broadcast (Msg type: discover ) which Mikrotik device receive and send back a Msg Type: offer. Thing here (and tested several times) is either DHCP packet type (offer) is not sent correctly or is sent as ARP broadcast asking for assigned IP in the offer. In any case client does not receive DHCP packet msg type: offer but ARP broadcast from dhcp-server asking for offered IP instead.
So in that way, client sent again broadcast with discoveries DHCP packets until number of tries it has configured (usually three).
I have the dhcp server listening on a bridge interface so it is possible there are some issue relative to sending broadcast packets via bridge interfaces (on my scenario). Also possible some bug on DHCP server (misconfiguration for new version could be a possible as well) that don't really send offers packets via dhcp-server listening interface.
Exactly same configuration from both sides (client/server) work as expected on previous version 6.37.4.
Yesterday i updated to 6.38.4 but same results.
Edited: Just to clarify that from Mikrotik device side i ran a packet sniffer and both (packet snifer and wireshark) match on results here exposed.

Hi, is exactly what I see, with a hAP Lite version 6.43.11 or 6.44 and the TP-Link RE450 repeater. No client using the RE450 as wifi entry point gets a DHCP address. 30 seconds assigned offer, and that's it. We know that a pseudo bridge replaces the MAC address of the client by its own MAC address. So yes you will have multiple IP adresses assigned for the same ARP MAC address, but different DHCP MAC addresses. The factory installed RouterOS version on the hAP Lite is 6.42.1 . As far as I understand this is the lowest version I can downgrade to. Is 6.37.4 out of reach? Replacing the RE450 with a wAP, cAP or mAP? And using routed networks and DHCP relay, to be able to manage the user account versus IP address logging from the central DHCP server?

pe1chl · Wed Jun 05, 2019 11:48 am

You cannot run DHCP over a pseudobrigde operated in reverse. (i.e. with the DHCP server at the station side and the DHCP client at the AP side), as you will encounter the problem you describe.
However that is true for all WiFi equipment.
In the "normal" situation of having the DHCP server at the AP side and the client at the station side, it will work OK.
When you encounter problems with DHCP replies resulting in ARP requests you can use "always broadcast" in the DHCP server setting.

bpwl · Wed Jun 05, 2019 2:30 pm

You cannot run DHCP over a pseudobrigde operated in reverse. (i.e. with the DHCP server at the station side and the DHCP client at the AP side), as you will encounter the problem you describe.
However that is true for all WiFi equipment.
In the "normal" situation of having the DHCP server at the AP side and the client at the station side, it will work OK.
When you encounter problems with DHCP replies resulting in ARP requests you can use "always broadcast" in the DHCP server setting.

Hi pe1chi, thanks for the information. I do see these ARP requests in the DHCP offer-bonding transition, as an attempt to get over the offer state.The DHCP server is not run in reverse over the pseudobridge. I tried the "always broadcast" and other combinations with "Authorative" and "add ARP for Leases" in the DHCP server. Even removed "conflict detection" in 6.44 . On the bridge interface changed STP to RSTP and none as mentioned in this forum topic.
I did NOT reboot after every iteration, and that might be my mistake. Even tried DHCP snooping and trusted interfaces. No combination was successfull. I do have a similar problem with the Draytek Vigor router, where they merged the ARP MAC table with the DHCP MAC table in one of the upgrades. Since then, when the client had a static entry in the table, with its own MAC address it could not get an IP address (with the MAC address of the repeater) from behind a repeater. Removing the static entry was necessary to solve it. I see in the ROS 6.45beta that there is a possibility for setting the number of IP addresses for a MAC address. Is there a limit in the 6.44 and earlier releases? The DHCP IP address for the client will be assigned to the repeater MAC address, and the repeater already has a DHCP IP address. The RE450 works fine with the Draytek router DHCP, as do a large set of Engenius, Ruckus and Draytek AP's and repeaters. The idea is to replace the whole set with Mikrotik but then at least the DHCP should work with clients behind a repeater (managed repeater as part of the fixed installation, or unknown repeater as part of the visitors or tenants equipment).

bpwl · Fri Jun 07, 2019 3:08 am

You cannot run DHCP over a pseudobrigde operated in reverse. (i.e. with the DHCP server at the station side and the DHCP client at the AP side), as you will encounter the problem you describe.
However that is true for all WiFi equipment.
In the "normal" situation of having the DHCP server at the AP side and the client at the station side, it will work OK.
When you encounter problems with DHCP replies resulting in ARP requests you can use "always broadcast" in the DHCP server setting.

Have been watching (Wireshark) the wireless traffic on the client side, and again changed the settings in the DHCP server as suggested. But it seems that the Mikrotik DHCP server is NEVER sending the DHCPoffer as a broadcast. At least the client (behind a universal mode repeater like the TP-link RE450) never sees a DHCPoffer from the Mikrotik. When another DHCP server (Draytek 2132ac) is used replacing the Mikrotik then there is no problem with the RE450.

The manual in the wiki states that the "always broadcast" will be actibvated if the DHCP lease fails. But even with a static setting it does not help. Could it be that this ability for DHCPoffer en DHCPack via broadcast broke in release 6.38?

Other forums mention the same problem (UBNT: Mikrotik + Ubiquiti) but assume it is due to the firmware upgrade of the Ubiquiti equipment.

EDIT

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.

nclmrc · Sat Feb 22, 2020 1:18 pm

Any update on this bug? Now i have 6.46.3.

Ferrograph · Wed Mar 18, 2020 3:27 pm

I dont think this is DHCP persay - it only happens with wireless devices - at least the issue I'm observing.

Try deleting the wireless client from the registration table either in CapsMan or wireless whichever you are running. Most times this restores the wireless client to working state.

It seems to be a problem relating to the wireless client being fully connected - at least where Ive observed this Ive seen that the wireless client is trying to obtain an IP address (thinking its fully connected) so the offer packet isnt getting through for some reason. Most likely you might be seeing the key exchange timeout message in the logs too at various times.

Very annoying problem since I convinced a number of installers to move over to CAPsMAN based wireless systems from Unifi, and its proved to be more troublesome - at least until this is fixed.

bpwl · Wed Mar 18, 2020 6:19 pm

" it only happens with wireless devices - at least the issue I'm observing."

Only in wireless you have level 2.5 bridges., or "pseudo bridges". Bridges where the MAC address of the requester is hidden, because it is replaced with the MAC address of the AP. (unless WDS is used, there is no room for the path and the destination in the packet header). The MAC address is in the DHCP request, but not in the packet header. Therefore for a client behind a pseudo bridge the DHCP server needs to broadcast its offer and its further checks, or the requester will never receive these. As far as I know broadcast is not only using 255.255.255.255 in IPv4 as destination address, but is also using the broadcast MAC address that is forwarded by the bridge to all ports. As the requester otherwise never sees the packet it never acknowledges, and the DHCP server drops the offer after a set timeout. (The lease never gets further than "offered".)

If the "pseudo bridge" uses proxy ARP it could work. If full broadcast is used it works. That's why I see mixed results, I think. Some other DHCP servers always work with pseudo bridges. Some "pseudo bridges" work with some DHCP servers, and not with others (like Mikrotik here).

Who's to blame? The bridge forwarding, the DHCP broadcast packet, the pseudo bridge ???

robpeng · Wed Apr 15, 2020 9:22 pm

Had hit a similar issue like this, it was really wreaking my head. I read somewhere to turn on alerts under DHCP Server > Alerts, once I did that I found another device (Hex S behind my TV) had a dhcp server running, deleted the dhcp config, even disabled the dhcp package, to be safe.

The alert saved me. My devices started connecting first time again

negromax · Wed May 27, 2020 3:05 pm

bpwl, thanks for your research

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.

I guess this is the exact problem why my OpenWRT + relayd based wireless repeater doesn't work. I have set always-broadcast to "yes" but got

Message		defconf offering lease 192.168.88.254 for 00:EA:4C:6D:11:96 to 54:E6:FC:F2:B8:48 without success

relayd doesn't forward dhcp replies to PC's

rafaelholeva · Mon Aug 31, 2020 7:36 pm

As far i could see, from client side (wireshark), DHCP packet is sent to the broadcast (Msg type: discover ) which Mikrotik device receive and send back a Msg Type: offer. Thing here (and tested several times) is either DHCP packet type (offer) is not sent correctly or is sent as ARP broadcast asking for assigned IP in the offer. In any case client does not receive DHCP packet msg type: offer but ARP broadcast from dhcp-server asking for offered IP instead.
So in that way, client sent again broadcast with discoveries DHCP packets until number of tries it has configured (usually three).
I have the dhcp server listening on a bridge interface so it is possible there are some issue relative to sending broadcast packets via bridge interfaces (on my scenario). Also possible some bug on DHCP server (misconfiguration for new version could be a possible as well) that don't really send offers packets via dhcp-server listening interface.
Exactly same configuration from both sides (client/server) work as expected on previous version 6.37.4.
Yesterday i updated to 6.38.4 but same results.
Edited: Just to clarify that from Mikrotik device side i ran a packet sniffer and both (packet snifer and wireshark) match on results here exposed.
Hi, is exactly what I see, with a hAP Lite version 6.43.11 or 6.44 and the TP-Link RE450 repeater. No client using the RE450 as wifi entry point gets a DHCP address. 30 seconds assigned offer, and that's it. We know that a pseudo bridge replaces the MAC address of the client by its own MAC address. So yes you will have multiple IP adresses assigned for the same ARP MAC address, but different DHCP MAC addresses. The factory installed RouterOS version on the hAP Lite is 6.42.1 . As far as I understand this is the lowest version I can downgrade to. Is 6.37.4 out of reach? Replacing the RE450 with a wAP, cAP or mAP? And using routed networks and DHCP relay, to be able to manage the user account versus IP address logging from the central DHCP server?

n my view, this is an issue that mikrotik refuses to understand, the psedo-mac issue is widespread use in some infrastructures, however DHCPv4 for RouterOs 6.47.3 Stable, still seems to refuse to deal with this means several ip addresses for the same MAC. This occurs mainly in the WIFI layer in router-board type hAP Lite etc.
It seems that mikrotik is not giving as much impostance to an error as serious as this one, which compromises the user's final experience too much, on the other hand no one goes public to report consistently why this happens and what is the standard solution to solve DHCP offer problem for pseudo-mac (Assigning several ip to the same MAC). I hope that mikrotik will take action and come to the public with a definitive solution to this problem, and that it will also manifest itself through a note on why the changes in the DHCPv4 standard. Many users are looking for a solution to this problem and it is useless to assign a mac-admin to the bridge, or disable STP or RSTP, as the problem persists after a few minutes when renewing. Let's wait for a valid explanation from the engineering side via the official note from mikrotik

rafaelholeva · Mon Aug 31, 2020 8:24 pm

bpwl, thanks for your research
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.
I guess this is the exact problem why my OpenWRT + relayd based wireless repeater doesn't work. I have set always-broadcast to "yes" but got
Code: Select all
Message		defconf offering lease 192.168.88.254 for 00:EA:4C:6D:11:96 to 54:E6:FC:F2:B8:48 without success
relayd doesn't forward dhcp replies to PC's

I have this same problem here with my DD-WRT operating in AP mode (Pseudo-BRIDGE).

reference: viewtopic.php?f=13&t=165423

Juraj22 · Wed Oct 21, 2020 10:16 am

Same in my case, I had to use pseudobridge(connect TP-Link AP with Mikrotik hAP) and devices behind Mikrotik(ethernet ports) has problems with DHCP lease. They cant get IP address form DHCP server..
I really like Mikrotik(great powerful devices for good prices), but this is annoying situation. I think that must be some solution how to fix it or create som hotfix for it on Mikrotik site. I understand problem with MAC addresses, but in other brands is working wifi-bridge quite fine in cases where is impossible to use cable and you need to have same network.

Wed Oct 21, 2020 12:11 pm

Thank you very much for your reports and findings.
In case you have any ongoing issues with current/long-term versions and DHCP, it would be great you can write to support@mikrotik.com, describe your setup and provide with support output file from server (that has dhcp,debug logs enabled).

kriss · Tue Nov 03, 2020 2:07 am

I have the same problem on CCR1072-1G-8S+ fw 6.46.8.
In my case VoIP base can't get DHCP address. Voip base (Granstream DP750 PoE) is connected to Cisco SG350X-48P which is connected to Mikrotik
I have 13 base ant only one can't get address.

dhcp1 offering lease 10.10.x.x for C0:74:AD:xx:xx:xx without success

pe1chl · Wed Nov 04, 2020 3:56 pm

I have a Grandstream GXP2100 and it works fine. Are you sure there is nothing between phone and DHCP that filters or changes MAC? (like a wifi link)

Ferrograph · Fri Nov 06, 2020 4:04 am

Who's to blame? The bridge forwarding, the DHCP broadcast packet, the pseudo bridge ???

Thanks for this clear explanation. Would this apply to standard wireless client setup with say multiple cAP AC, all ports bridged CAPs mode with local forwarding?

likaon · Sat Dec 26, 2020 10:09 pm

Hello,
I'm writing once again because I've got the same problem. RouterOS version 6.48 was to repair problems with Accesspoint and wireless clients from geting an IP address.
My tool is Mikrotik hap AC2 RouterOS version 6.48. and Accesspoint TL-WA854RE oraz asus rp-ac51.

Do I have to write anything new in settings?

Ferrograph · Fri Feb 12, 2021 3:01 pm

Still seeing this in 6.48.1. So annoying.

galaxynet · Thu Mar 11, 2021 8:02 pm

I'm seeing it as well on a nRay 60g with 6.48.1

Hope you guys get it fixed soon!

bpwl · Fri Apr 09, 2021 11:29 am

That DHCP problem over pseudo-bridges seems to be everywhere!???

Still having an almost useless TP-link RE450 v2 "repeater" on my desk , I saw the OpenWRT reference, and implemented it.
(the original firmware needs too much DHCP server manipulation and it selects the wrong channels and bandwidth when doing cross-band repeating)
"repeater" in OpenWRT is not that straightforward, but they have the optional "relayd" package.
And guess what? They also have problems with DHCP. https://openwrt.org/docs/guide-user/net ... figuration

The most common problem is that the client router cannot pass the DHCP message between the main router and the client connected to the client router. Currently it seems to be the hardware/SOC limitation (related to MAC cloning?)

But it's a step forward. The RE450 has 3x3 radio's and now I have a usable AP with good wifi. Repeating as a "home AP" (different subnets) works fine. Need some experiments to see if the "repeater" function (transparant subnet) is usable with an uplink to MT AP and DHCP server.

https://forum.openwrt.org/t/relayd-not- ... s/53607/13

I compared responses (DHCP ACKs) coming via Mikrotik and non-Mikrotik APs.
the only difference is that in the latter the response has a broadcast address in the Ethernet header (works) while in the former it's the MAC address of the WiFi client (doesn't work).

ShaMana999 · Fri Apr 09, 2021 12:28 pm

Greetings good people. It seems I'm having the same or similar issue. I'm very green at this and am learning on the fly for home network needs.

So, my case is that I have a hEX S routerboard paired with a cAP ac for wireless access.

I've set up the cAP to act as a bridge and forward DHCP requests to the hEX, however, it seems the bridge itself doesn't like to obtain an IP for the access point and generates "offering lease without success error". I've tried the recommendations above like disabling STP and manually adding Admin MAC to the bridge in question, and they provide only a temporary fix.

Right after applying settings change the access point obtains IP until the lease expires and the problem appears again. At first glance, regardless of the IP status, wireless clients work as expected.

Any suggestions.

PS: Scratch no wireless troubles. Devices work at 1/8 bandwidth, may not be related, but something I've messed up while setting up the interface.

PPS: Scratch DHCP problems too. It seems some autoconfig sneaked somehow and prevented the server from leasing that specific adess.

m94646602 · Sun Apr 18, 2021 3:23 pm

v6.48.2, CAPsMAN still get DHCP offering lease without success !!!!

I have given up ROS as a DHCP SERVER and now use ASUS.

Ferrograph · Wed Apr 28, 2021 2:04 pm

Ok, so Ive been working this issue on the one site I have that has it and I seem to have found the issue - at least this is what the problem was in my case, there are numerous things that can cause this.

Before though I'm Just going to tell about something I tried in addition to what Ive posted above. This didn't fix the issue but its worthy to note and could be causing you trouble and it was good practise to run this test and fix as needed.

I suspected I had some sort of packet drop issue causing this so I tested this using bandwidth test to each access point with UDP, 1400 packet size and 400M in both directions (you might have to lower this on slower Tiks, but I had CCR1009) I found a group of cAP's that were showing high number of dropped packets while others showed none for the same test. Turned out they were all on the same switch and running the same test to the switch showed the same packet drops. Turned out I had 4 faulty fibre modules (S+85DLC03D) in the chain through 3 switches on that leg, so by swapping with spares I was able to get rid of the dropped packets - but to my dismay the DHCP issue still WAS NOT fixed, still saw those dreaded messages coming in the logs.

So I really started to compare in detail configuration on sites where this isn't an issue including a holiday cottage site that has 50 or so devices connecting daily across 16 access points, and only see this message a handful of times and examination of the logs shows its devices connecting and then going out of range quickly. I found very little difference since I generally copy known good configurations basic setup with scripts. Interesting to note also was that RSTP was enabled on the AP's bridge but evidently not causing any issues contrary to a lot of reports.

However I did find that in CAPsMAN->Security-> group-encryption was not set on the security profile. So I set this to aes-ccm same as encryption. Applied it and watched all the AP's come back online. And the problem was gone!

I kept checking every hour and no more messages. Now even days later there been no significant amounts of that message and the few that are present are associated with devices joining and going out of range quickly. Also the customer, who has been very patient, has stopped texting me! Hurray!

So check your security config that you have group-encryption set to aes-ccm.

Update: NOT FIXED, although a reduction in frequency. The next thing I have changed is to set the group-key-update to 1hr instead of empty. Will report back...

brg3466 · Tue May 04, 2021 8:48 am

@Ferrograph Did you finally find a fix ? I am running 6.48.2 but still see it from time to time.

Ferrograph · Tue May 04, 2021 2:00 pm

@brg3466 Just waiting to see what setting the group-key-update=01:00:00 gets me. Im being sure to change only one thing each time. The problem often has a time element. Sometimes just by resetting the wifi it goes away for a bit then returns with a vengeance. It is indeed a perplexing problem.

Its been a day and a half-ish since I made the change, so far so good. But I wont count my radios until we reach the 4 day point.

Ferrograph · Sat May 08, 2021 4:15 am

Ok this issue is still driving me nuts. With the group-key-update=01:00:00 I got 4 days of very little problems. After that Im seeing the DHCP message on one access point after another. But I noticed something odd this time.

Looking through the logs I can see which AP+radio is causing the DHCP failure. When I go view the interfaces on that AP I can see that the errant radio is not passing any broadcast traffic. You can see this quite clearly because if you look at the interfaces table, under normal conditions, even with no clients connected, the 2G and 5G interfaces show TX packets which are broadcasts. Under the failed condition the counters stay at zero. See screen shots:

AP interfaces no broadcasts.png

AP Ok.png

Is anyone able to verify they are seeing the same conditions?

Resetting the interface in CAPsMAN fixes the issue (for another 4 days?)

Ferrograph · Wed May 19, 2021 1:26 pm

Still at it. More info...

Ive discovered that when the 5G/ac radios gets in this weird state it is generating 10Mbps of phantom Qos packets. I'm seeing this on all 5G radios that get in this state. Resetting the interface in capsman clears the issue. You can see the high usage if you do a wireless-snoop.

Interestingly the source mac shown on any of the radios in this state is an iOS device from the network, but even when that device is out of the property these phantom packets are still being generated. Devices can still associate with the radio in this state but packets (like DHCP offers) are not being send back to associated devices and hence the DHCP message in the logs. Ive sent sniffs to MT support but as always they are reluctant to acknowledge any issue.

This would explain why the client has been reporting that the wifi is sometimes slow no doubt due to the 10Mbps of junk affecting adjacent areas. I might need to move some channels around to at least alleviate that effect.

I would say possibly a virus on the device with the mac address of the phantom packets, but its iOS, making it highly unlikely. The plot thickens.

Any thoughts?

Ferrograph · Wed May 26, 2021 2:40 pm

I upgraded all APs to v6.49beta46 because there were several entries for wireless fixes in the release notes. After 4 days the problem is back as with previous versions. So no dice.

Its been several days since I sent wireless captures to MT support with no reply or even an acknowledgement of receipt on the the ticket.

toxicfusion · Wed Jun 23, 2021 9:41 pm

I upgraded all APs to v6.49beta46 because there were several entries for wireless fixes in the release notes. After 4 days the problem is back as with previous versions. So no dice.

Its been several days since I sent wireless captures to MT support with no reply or even an acknowledgement of receipt on the the ticket.

Any update on this?

Please try running routerOS 6.47.10 -- lots of fixes, very stable. I've had great success with it and feel comfortable with this release. Otherwise, I stuck to 6.45.9....

Also -- regarding DHCP offered WITHOUT success. I've seen this issue for following reasons:

A) Issue lies with your interface BRIDGE configuration. Are you using vlans? be sure to check your bridge configuration and vlan assignment / pvid settings..
B) Device is out of range to AP or you have weird access-list.
C) Check your CAPsMAN configuration as well as Security settings.

Yes, want to use aes-ccm, group-key update of 01:00:00, also be sure to disable PMKID

brg3466 · Sun Jun 27, 2021 1:08 am

[/quote]
Also -- regarding DHCP offered WITHOUT success. I've seen this issue for following reasons:

A) Issue lies with your interface BRIDGE configuration. Are you using vlans? be sure to check your bridge configuration and vlan assignment / pvid settings..
B) Device is out of range to AP or you have weird access-list.
C) Check your CAPsMAN configuration as well as Security settings.

Yes, want to use aes-ccm, group-key update of 01:00:00, also be sure to disable PMKID
[/quote]

Could you be specific about the vlan bridge settings ?
I have vlans on the bridge and already set "protocol-mode=none", but from time to time , still have the issue. Is there anything else I have to be aware of in the bridge configuration ?

Thank you !

Ferrograph · Sun Jun 27, 2021 4:33 am

No fix yet. And Im very disappointed with Mikrotik, as Ive sent them and lot of data and info on this issue even given them remote access to the site and they have done nothing,

To be clear this is now purely a 5G WiFi radio issue. Everything else thats wired or on 2G Wifi works without issue. Ive currently got CAPsMAN toggling the interfaces overnight to keep them working. Otherwise after 4 days the 5G radios start to crash.

I will however try rolling the AP's back to 6.47.10 because Ive not tried that yet.

Elektrik · Thu Aug 05, 2021 11:01 pm

Same problem here with 6.48.3.
DDWRT Client Bridge results in 'offered' DHCP lease, and the offer repeats every 30 seconds not assigning the IP.

InTheSprawl · Tue Sep 28, 2021 9:55 pm

I'm still learning a lot about networking and have never taken any classes or lessons-- just picked-up a little here and there over the years, so I tend to follow videos or written instructions when it comes to things with which I am less familiar. I've been seeing the DHCP "offered lease without success" issue repeatedly over the past couple of months at two different locations ever since implementing CAPsMAN. I followed the videos for CAPsMAN set-up (pretty dead-simple), and it was all working for the first day, then without any configuration changes, I started getting this DHCP failure issue. The failure to bond the IP offers occurs mainly with the Mikrotik CAPs. I'm running RB4011's and HAP-2's. Every time I think I've solved the issue, but then after a few hours or days, it suddenly reappears resulting in client devices that can't connect to the network. It's maddening. I've experimented with a ton of different settings, set-ups and tried many of the suggestions in these forums... what seems to be working for me, at least for now, is to just create static IP ARP entries for my CAPs outside the DHCP Pool (x.x.x.2 thru x.x.x.10 for CAPs and then a DHCP Pool of x.x.x.11 thru x.x.x.254.) I also set the corresponding Static IP on each CAP. DHCP offers then pass and bond with all other devices, their DHCP reservations are respected, and the issue thus seems solved. Is there a problem doing things this way?

Ferrograph · Wed Sep 29, 2021 12:27 am

@InTheSprawl - Welcome to the rabbit hole of "DHCP without success". Various thing can cause this. I'm only going to talk about the issue Ive seen that can cause this message in the logs, which Ive spent months chasing down and trying all kinds of configurations..

Check the APs 5G wireless interface for zero TX counters. If you see its at zero permanently then the 5G radio has crashed and no longer forwards broadcast traffic, although bizarrely still allows devices to associate. You'll likely see the the 2G tx counters are running ok. In this case the only way to restore the 5G radio operation is to toggle the interface in capsman.

Sometimes the systems can go for up to 4 days without issues and then suddenly this message. The number of times Ive thought I'd fixed it with config changes and then message from clients that wifi in certain areas not working. Ugh!

No fix as yet and Mikrotik wont even acknowledge it.

Theres other things can cause the DHCP failure like xSTP on bridges - turn it off. Check the DHCP server is on the same interface as the routers IP addr, ideally the bridge. Lots of other things documented here on the two threads associated with it. I really hope its not the 5G radio crash issue for you.

karlisi · Wed Sep 29, 2021 9:07 am

Network problems can cause this error too. I had bad network cable between AP and switch, time to time there was this DHCP error for clients on this AP.

erlinden · Wed Sep 29, 2021 9:20 am

Would really like to have a look at your configuration (/export hide-sensitive file=anythingyoulike), @InTheSprawl.

InTheSprawl · Fri Oct 01, 2021 9:08 am

Would really like to have a look at your configuration (/export hide-sensitive file=anythingyoulike), @InTheSprawl.

This seems to be working for me. I haven't seen the "DHCP offered without success" in days at this point.--But I can't really say I thoroughly understand everything I am doing. (RouterOS has a ton of toggles, easily half of which I have no idea as to what they do.)

Static ARP entries for any CAPs. On each CAP, enter the corresponding static IP that was entered in ARP on router. CAP IPs should be outside of DHCP Pool. Let me know if you see any problems, security issues, etc. Here is a somewhat sanitized config output from a small network with a single CAP and a wireless bridge:

# sep/30/2021 21:49:12 by RouterOS 6.48.4
# software id = D1JC-XXXX
#
# model = RB4011iGS+5HacQ2HnD
# serial number = A28209XXXXXX
/interface bridge
add admin-mac=B8:69:F4:XX:XX:XX auto-mac=no comment=defconf name=bridge \
    priority=0x10
/interface wireless
# managed by CAPsMAN
# channel: 5640/20-eeCe/ac/DP(24dBm)+5775/80(27dBm), SSID: nowires, CAPsMAN forwarding
set [ find default-name=wlan1 ] band=5ghz-n/ac channel-width=20/40/80mhz-XXXX \
    distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=\
    "nowires-5G" station-roaming=enabled wireless-protocol=802.11 \
    wps-mode=disabled
# managed by CAPsMAN
# channel: 2412/20-Ce/gn(27dBm), SSID: nowires, CAPsMAN forwarding
set [ find default-name=wlan2 ] band=2ghz-g/n channel-width=20/40mhz-XX \
    distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=\
    "nowires" station-roaming=enabled wireless-protocol=802.11
/interface ethernet
set [ find default-name=ether1 ] loop-protect=on mac-address=\
    B8:69:F4:X0:X0:X0 rx-flow-control=auto tx-flow-control=auto
set [ find default-name=ether2 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
set [ find default-name=ether3 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
set [ find default-name=ether4 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
set [ find default-name=ether5 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
set [ find default-name=ether6 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
set [ find default-name=ether7 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
set [ find default-name=ether8 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
set [ find default-name=ether9 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
set [ find default-name=ether10 ] loop-protect=on poe-out=off \
    rx-flow-control=auto tx-flow-control=auto
set [ find default-name=sfp-sfpplus1 ] loop-protect=on rx-flow-control=auto \
    tx-flow-control=auto
/caps-man datapath
add arp=reply-only bridge=bridge name=datapath1
/caps-man security
add authentication-types=wpa-psk,wpa2-psk disable-pmkid=yes encryption=\
    aes-ccm group-encryption=aes-ccm group-key-update=1h name=security1
/caps-man configuration
add channel.band=2ghz-onlyn country="united states" datapath=datapath1 \
    datapath.arp=reply-only datapath.bridge=bridge installation=indoor mode=\
    ap name=2GHz-N security=security1 ssid="nowires"
add channel.band=5ghz-n/ac country="united states" datapath=datapath1 \
    datapath.arp=reply-only datapath.bridge=bridge installation=indoor mode=\
    ap name=5GHz-AC-N security=security1 ssid="nowires"
/caps-man interface
add configuration=5GHz-AC-N datapath=datapath1 disabled=no l2mtu=1600 \
    mac-address=B8:69:F4:0X:0X:0X master-interface=none name=cap5 radio-mac=\
    B8:69:F4:0X:0X:0X radio-name=B869F40X0X0X security=security1
add configuration=2GHz-N datapath=datapath1 disabled=no l2mtu=1600 \
    mac-address=B8:69:F4:11:11:11 master-interface=none name=cap6 radio-mac=\
    B8:69:F4:11:11:11 radio-name=B869F4111111 security=security1
add configuration=5GHz-AC-N datapath=datapath1 disabled=no l2mtu=1600 \
    mac-address=E4:8D:8C:22:22:22 master-interface=none name=cap7 radio-mac=\
    E4:8D:8C:22:22:22 radio-name=E48D8C222222 security=security1
add configuration=2GHz-N datapath=datapath1 disabled=no l2mtu=1600 \
    mac-address=E4:8D:8C:YY:YY:YY master-interface=none name=cap8 radio-mac=\
    E4:8D:8C:YY:YY:YY radio-name=E48D8CYYYYYY security=security1
/interface ethernet switch port
set 0 default-vlan-id=0
set 1 default-vlan-id=0
set 2 default-vlan-id=0
set 3 default-vlan-id=0
set 4 default-vlan-id=0
set 5 default-vlan-id=0
set 6 default-vlan-id=0
set 7 default-vlan-id=0
set 8 default-vlan-id=0
set 9 default-vlan-id=0
set 10 default-vlan-id=0
set 11 default-vlan-id=0
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys \
    supplicant-identity=MikroTik
/ip ipsec peer
# This entry is unreachable
add comment=L2TP name=L2TPpeer passive=yes
# This entry is unreachable
add name=l2tp-in-server passive=yes
/ip ipsec profile
set [ find default=yes ] enc-algorithm=aes-256,3des
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,3des pfs-group=none
/ip kid-control
add fri=0s-23h59m mon=0s-23h59m name=KID sat=0s-23h59m sun=0s-23h59m thu=\
    0s-23h59m tue=0s-23h59m wed=0s-23h59m
add fri=0s-23h59m mon=0s-23h59m name=GUEST sat=0s-23h59m sun=0s-23h59m \
    thu=0s-23h59m tue=0s-23h59m wed=0s-23h59m
/ip pool
add name=vpn ranges=192.168.23.251-192.168.23.254
add name=dhcp ranges=192.168.1.10-192.168.1.250
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=dhcp
/ppp profile
set *FFFFFFFE local-address=192.168.23.1 remote-address=vpn
/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,pas\
    sword,web,sniff,sensitive,api,romon,dude,tikapp"
/caps-man access-list
add allow-signal-out-of-range=10s comment=DEVICE1 disabled=yes \
    mac-address=50:32:37:XX:XX:XX signal-range=-70..120 ssid-regexp="" time=\
    0s-1d,sun,mon,tue,wed,thu,fri,sat
add allow-signal-out-of-range=10s comment="DEVICE2" disabled=yes \
    mac-address=D6:7A:D3:XX:XX:XX signal-range=-70..120 ssid-regexp="" time=\
    0s-1d,sun,mon,tue,wed,thu,fri,sat
add allow-signal-out-of-range=10s comment="DEVICE3" disabled=yes \
    mac-address=F0:18:98:XX:XX:XX signal-range=-120..120 ssid-regexp="" time=\
    0s-1d,sun,mon,tue,wed,thu,fri,sat
/caps-man manager
set ca-certificate=auto certificate=auto enabled=yes upgrade-policy=\
    suggest-same-version
/caps-man provisioning
add action=create-dynamic-enabled hw-supported-modes=gn,g-turbo \
    master-configuration=2GHz-N name-format=prefix-identity name-prefix=CAP
add action=create-dynamic-enabled hw-supported-modes=ac,an,a-turbo \
    master-configuration=5GHz-AC-N name-format=prefix-identity name-prefix=\
    CAP
/certificate settings
set crl-download=yes crl-use=yes
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp-sfpplus1
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
add bridge=bridge disabled=yes interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface detect-internet
set detect-interface-list=all
/interface l2tp-server server
set allow-fast-path=yes authentication=mschap2 default-profile=L2TP-Profile \
    enabled=yes max-mru=1460 max-mtu=1460 use-ipsec=yes
/interface list member
add comment=defconf interface=bridge list=LAN
add interface=ether1 list=WAN
/interface ovpn-server server
set certificate=CAP-E48D8CXXXXXX
/interface sstp-server server
set default-profile=default-encryption
/interface wireless cap
#
set bridge=bridge caps-man-addresses=127.0.0.1 certificate=\
    CAPsMAN-B869F4XXXXXX enabled=yes interfaces=wlan1,wlan2 lock-to-caps-man=\
    yes
/ip address
add address=192.168.1.1/24 comment=defconf interface=ether2 network=\
    192.168.1.0
/ip arp
add address=192.168.1.2 comment=CAP1 interface=bridge mac-address=\
    E4:8D:8C:XX:XX:XX
add address=192.168.1.5 comment=BRIDGEA interface=bridge mac-address=\
    4C:5E:0C:XX:XX:XX
/ip cloud
set ddns-enabled=yes ddns-update-interval=10m
/ip dhcp-client
add disabled=no interface=ether1
/ip dhcp-server lease
add address=192.168.1.112 client-id=DEVICE4 comment="DEVICE4" \
    mac-address=D0:81:7A:XX:XX:XX server=dhcp
add address=192.168.1.28 client-id=1:48:d7:5:XX:XX:XX comment=\
    DEVICE5 mac-address=48:D7:05:XX:XX:XX server=dhcp
add address=192.168.1.108 mac-address=C4:7F:51:XX:XX:XX server=dhcp
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf dns-server=\
    1.1.1.1,1.0.0.1 gateway=192.168.1.1 netmask=24
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,1.0.0.1
/ip dns static
add address=192.168.1.1 comment=defconf name=router.lan
add address=1.1.1.1 name=cloudflare-dns.com
add address=1.0.0.1 name=cloudflare-dns.com
/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="allow IPsec NAT" disabled=yes dst-port=4500 \
    protocol=udp
add action=accept chain=input comment="allow IKE" disabled=yes dst-port=500 protocol=udp
add action=accept chain=input comment="allow l2tp" disabled=yes dst-port=1701 protocol=udp
add action=accept chain=input comment="allow pptp" disabled=yes dst-port=1723 \
    protocol=tcp
add action=accept chain=input comment="allow sstp" disabled=yes dst-port=443 \
    protocol=tcp
add action=accept chain=input comment=Webserver disabled=yes dst-address=\
    192.168.1.42 dst-port=80 log=yes protocol=tcp src-port=80
add action=accept chain=input comment="defconf: accept ICMP" disabled=yes \
    protocol=icmp
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="masq. vpn traffic" src-address=\
    192.168.23.0/24
add action=dst-nat chain=dstnat disabled=yes dst-port=80 in-interface=\
    all-ethernet log=yes protocol=tcp to-addresses=192.168.1.42 to-ports=80
add action=dst-nat chain=dstnat disabled=yes dst-port=443 in-interface=ether1 \
    log=yes protocol=tcp to-addresses=192.168.1.42 to-ports=443
add action=masquerade chain=srcnat out-interface-list=WAN
add action=masquerade chain=srcnat out-interface-list=WAN
/ip ipsec identity
add comment="L2TP IPSEC Encryption" generate-policy=port-override peer=\
    L2TPpeer
add comment=l2tp-in-server generate-policy=port-strict peer=l2tp-in-server \
    remote-id=ignore
/ip kid-control device
add mac-address=58:55:CA:XX:XX:XX name=LAPTOP user=KID
add mac-address=B8:F6:B1:XX:XX:XX name=OS2 user=KID
add mac-address=34:A8:EB:XX:XX:XX name=GUESTOS user=GUEST
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set www-ssl certificate=192.168.1.1 disabled=no port=443
/ip smb
set allow-guests=no
/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=bridge type=internal
/ppp profile
add bridge=bridge change-tcp-mss=yes comment=L2TP dns-server=\
    192.168.1.1,1.1.1.1 local-address=*1 name=L2TP-Profile remote-address=vpn
/ppp secret
add name=vpn profile=default-encryption
add comment=L2TPvpn name=L2TPvpn profile=L2TP-Profile service=l2tp
/system clock
set time-zone-autodetect=no time-zone-name=America/New_York
/system identity
set name=Router
/system leds
add interface=wlan2 leds="wlan2_signal1-led,wlan2_signal2-led,wlan2_signal3-le\
    d,wlan2_signal4-led,wlan2_signal5-led" type=wireless-signal-strength
add interface=wlan2 leds=wlan2_tx-led type=interface-transmit
add interface=wlan2 leds=wlan2_rx-led type=interface-receive
/system ntp client
set enabled=yes primary-ntp=128.138.140.44 secondary-ntp=132.163.96.1 \
    server-dns-names=time.cloudflare.com
/system scheduler
add comment="DDNS timer" interval=15m name="DDNS timer" on-event=\
    "/system script run DDNS" policy=read,write,policy,test start-date=\
    jan/23/2020 start-time=06:00:00
/system script
add comment="DNS" dont-require-permissions=no name=DDNS owner=admin \
    policy=read,write,policy,test source=":global actualIP value=[/ip address \
    get [find where interface=MATRIX] value-name=address];\
    \n:global actualIP value=[:pick \$actualIP -1 [:find \$actualIP \"/\" -1] \
    ];\
    \n:if ([:len [/file find where name=ipstore.txt]] < 1 ) do={\
    \n /file print file=ipstore.txt where name=ipstore.txt;\
    \n /delay delay-time=2;\
    \n /file set ipstore.txt contents=\"0.0.0.0\";\
    \n};\
    \n:global previousIP value=[/file get [find where name=ipstore.txt ] value\
    -name=contents];\
    \n:if (\$previousIP != \$actualIP) do={\
    \n :log info message=(\"Try to Update DYNDNS with actual IP \".\$actualIP\
    .\" -  Previous IP are \".\$previousIP);\
    \n /tool fetch mode=https keep-result=yes dst-path=dyndns-result.txt addr\
    ess=[:resolve www.dyndns.com] port=443 host=www.dyndns.com src-path=(\"/\
    update\?domains=home&token=XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX&ip=\
    \".\$actualIP);\
    \n /delay delay-time=5;\
    \n :global lastChange value=[/file get [find where name=dyndns-result.txt\
    \_] value-name=contents];\
    \n :global previousIP value=\$actualIP;\
    \n /file set ipstore.txt contents=\$actualIP;\
    \n :if (\$lastChange = \"OK\") do={:log warning message=(\"DYNDNS update \
    successfull with IP \".\$actualIP);};\
    \n :if (\$lastChange = \"KO\") do={:log error message=(\"Fail to update DY\
    NDNS with new IP \".\$actualIP);};\
    \n};"
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

InTheSprawl · Wed Oct 06, 2021 4:45 am

So, this config has been working fine for me for several days now, looks like it has finally solved the "DHCP without success" issue. However, can anyone explain why it requires me to set static ARP entries for the APs and won't work with the default DHCP address reservation entries? This seems like a bug to me since the default configuration as explained in online tutorials directly from Mikrotik will not work without error for me. Adding a reserved IP for an AP in the DHCP lease list should not break CAPsMAN, since this is a fairly ordinary thing to do, especially for those using the web admin client (which is the default for many users not on Windows.)

InTheSprawl · Wed Oct 06, 2021 4:53 am

By the way, one last thing... we should change the topic of this thread if possible since the issue isn't limited to ROS 6.38. Maybe retitle it ["DHCP without success" error], which seems to be the common issue here. I was using ROS 6.48.4 and 6.47.10 which both still have this problem if I don't configure things as I outlined. I hope my posts help others out here.

***UPDATE***
Well, this problem has returned. This "solution" didn't last past a few days, unfortunately. Strange... I noticed that the DHCP Server doesn't seem to respect the specified pool that I set, still handing attempting to offer IP addresses in the same subnet, but outside of the range that I specified. i.e. I'll specify dhcp_pool to be 192.168.1.10-192.168.1.254 and it will still offer 192.168.1.1-192.168.1.9 to clients. Is it supposed to do that? I assigned some clients to that lower range using the MAC to Static IP reservation method, but they will sometimes still grab a higher IP address if the client device is set to acquire IP via DHCP. If I make them static on the client side, and in that lower range, then the DHCP Server will still try to offer them an IP address and fail to bind on occassion.

bpwl · Mon Feb 21, 2022 9:23 pm

It looks like we have a new workaround using DHCP relay on the pseudobridge: viewtopic.php?p=914589#p914252

There is another one which mangles the MAC address at the bridge level, inserting the ff:ff:ff:ff:ff:ff broadcast MAC address.: viewtopic.php?t=160180#p842558

EDIT: Just wondering. If not using ff:ff:ff:ff:ff:ff for the DHCPoffer is (part of) our problem with DHCP behind a pseudobridge. Is "Multicast Helper" of the WLAN interface playing a role in this? Multicast helper converts multicasts and broadcasts( ???) into unicasts. Most wiki documentation only discusses 'multicast and wireless'. But in the 'Interworking_Profile' wiki there is that line : "To disable multicast and broadcast frames set multicast-helper=full."

And since when do we have a DHCP option for Multicast helper? It is not documented in the old wiki and not in the newer help wiki https://help.mikrotik.com/docs/display/ ... +Interface

Klembord-2.jpg

It's not in the older ROS versions (6.47.9, 6.48.4, ....) but it is in 6.49.3

EDIT: it is in the change log of 6.49. But no documentation. What is it? When and where to apply?

aleab · Fri Mar 04, 2022 6:25 pm

Hello,
i'm sorry but i think it's related.

i have a trouble with this simple configuration
mikrotik RB750Gr3 as router (reset with default configuration) and AP ubiquiti from years . and all works fine

i would attach a hap lite as "client" because i would connect a ethernet printer to mikrotik and share it over LAN.
i can't connect by wire and wifi signal is strong near printer.

anyway i thinked is very simple but i'm wrong...

i reset hap lite with no keep default configuration.
i create bridge and add 4 ethernet + 1 wlan
set wlan on station pseudobridge
add dhcp client on bridge but can't "bound" (stay in searching...)
on RB750Gr3 i see
..... offering lease ........ without success

strange is i assign an ip on bridge i can ping gateway (RB750Gr3) but gateway can't ping hap lite
same with printer or pc connected to hap lite ethernet ports.

i try all posted here:
assign admin mac address
disable STP / RSTP
change multicast helper to full
but never "bound" ip...

if i connect hap lite (ever station pseudobridge) with my hotspot smartphone bound quickly...
seems trouble is only DHCP server on mikrotik devices...

thank you

bpwl · Fri Mar 04, 2022 7:37 pm

"Station pseudobridge", the pseudobridge mapping is for the client devices (ethernet in your case) only.
The DHCP client on the bridge should not be influenced by the pseudobridge. That part is just still the "station".
If you set WLAN to "station" , does it then get a DHCP lease correctly?
If not, does any other wifi connection to the Ubiquiti get a DHCP lease?
Is the AP Ubiquity using NAT somewhere, or a firewall rule preventing traffic to be initiated from the RB750GR3 ?

aleab · Fri Mar 04, 2022 8:38 pm

thank you for reply.

yes all pc / android / wifi printer can connect directly to ubiquiti and get dhcp from RB750GR3 .
ubiquiti is uap-ac-pro set AP (without NAT, only AP)

i try also in station mode, but i can't get ip from DHCP.
reset hap lite, without create bridge
connect wlan1 with security profile (connection ok)
add dhcp client on wlan1
same issue...
searching...

thank you in advance

bpwl · Fri Mar 04, 2022 8:45 pm

OK. So hAP Lite does not get DHCP lease as station.
(Bizar, one reason I know is when it already has the same static address)

Enable DHCP logging on the RB750gr3 : "/system logging add topics=dhcp"

aleab · Fri Mar 04, 2022 9:14 pm

attach a screen...

10.1.1.7 is dhcp server...

thank you

aleab · Fri Mar 04, 2022 9:30 pm

maybe problem is

5 offers in a row => no response, restarting with unicast

bpwl · Fri Mar 04, 2022 9:34 pm

"Offer" never reaches client (161), so the "discover" is repeated. over and over, and answered with "offer" that however does not reach the client.
To be confirmed wit DHCP logging on hAP Lite.

If confirmed: What stops the "offer" or sends it in the wrong direction?

aleab · Fri Mar 04, 2022 9:40 pm

thank you for reply

here is log on hap lite (wlan station)

bpwl · Sat Mar 05, 2022 1:08 am

No "offer" received from DHCP server.
As you can see the log, you can export this configuration also.

aleab · Thu Mar 10, 2022 5:00 pm

sorry if i not answer quickly...
but i thinked that hap lite was broken, so now i have new hap ac2

same issue...
reset hap ac2, without create bridge
connect wlan1 with security profile in station mode (connection ok)
add dhcp client on wlan1
same issue...
searching...

here export

# jan/02/1970 00:03:53 by RouterOS 6.48.6
# software id = xxxxxxx
#
# model = RBD52G-5HacD2HnD
# serial number = xxxxxxx
/interface wireless
set [ find default-name=wlan2 ] ssid=MikroTik
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys name=\
    mywifi supplicant-identity=""
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX \
    country=italy disabled=no frequency=auto security-profile=mywifi ssid=\
    "MY WIFI" wireless-protocol=802.11
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip dhcp-client
add disabled=no interface=wlan1
/system routerboard settings
set auto-upgrade=yes

thank you

aleab · Fri Mar 11, 2022 7:46 pm

sorry but i'm still trying.
i test on my lab with
map lite (act as DHCP server)
wifi is a provider AP
and
hap lite and hap ac2 in "client mode" and have same issue...

to complete i post export of "DHCP server"

# mar/11/2022 18:33:31 by RouterOS 7.1.3
# software id = xxxxx
#
# model = RBmAPL-2nD
# serial number = xxxxxxxx
/interface bridge
add name=bridge_lan
/interface wireless
set [ find default-name=wlan1 ] ssid=MikroTik
/interface wireguard
add listen-port=49625 mtu=1420 name=wireguard1
/interface list
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=pool_lan ranges=10.1.1.160-10.1.1.249
add name=pool_ovpn ranges=10.158.38.30-10.158.38.254
/ip dhcp-server
add address-pool=pool_lan interface=bridge_lan lease-time=1h name=dhcp_lan
/ppp profile
add bridge=bridge_lan local-address=pool_ovpn name=ovpn_profile \
    remote-address=pool_ovpn use-compression=no use-encryption=required
/interface bridge port
add bridge=bridge_lan interface=ether1
/ipv6 settings
set disable-ipv6=yes
/interface list member
add interface=bridge_lan list=LAN
add interface=wireguard1 list=LAN
/interface ovpn-server server
set auth=sha1 certificate=server cipher=aes256 default-profile=ovpn_profile \
    enabled=yes require-client-certificate=yes
/interface wireguard peers
add allowed-address=10.168.66.2/24 interface=wireguard1 public-key=\
    "xxxx"
/ip address
add address=10.1.1.7/24 interface=bridge_lan network=10.1.1.0
add address=10.168.66.1/24 interface=wireguard1 network=10.168.66.0
/ip cloud
set ddns-enabled=yes ddns-update-interval=5m
/ip dhcp-server alert
add alert-timeout=30m disabled=no interface=bridge_lan on-alert="/tool e-mail \
    send to=\"mail@mail.com\" subject=\"ALERT Unauthorized DHCP Server\" b\
    ody=\"ALERT Server DHCP non autorizzato rilevato in rete \$[/system identi\
    ty get name]\"" valid-server=B6:91:B1:C0:AE:4D
/ip dhcp-server network
add address=10.1.1.0/24 dns-server=10.1.1.7 gateway=10.1.1.1
add address=10.158.38.0/24 dns-server=10.1.1.7 gateway=10.1.1.7 netmask=24
/ip dns
set allow-remote-requests=yes cache-size=512KiB servers=\
    137.74.48.215,94.140.14.14,94.140.15.15,8.8.8.8,1.1.1.1
/ip firewall filter
add action=accept chain=input comment="accept da lan" src-address=10.1.1.0/24
add action=accept chain=input comment="allow port 1194" dst-port=1194 \
    protocol=tcp
add action=accept chain=input comment="allow port wireguard" dst-port=49625 \
    protocol=udp
add action=accept chain=input comment="allow all from openvpn" src-address=\
    10.158.38.0/24
add action=drop chain=input comment="drop 8291 da tutti" disabled=yes \
    dst-port=8291 protocol=tcp
add action=drop chain=input comment=\
    "drop all da NON LAN subnet e state = INVALID e NEW" connection-state=\
    invalid,new src-address=!10.1.1.0/24
/ip firewall nat
add action=masquerade chain=srcnat comment="MASQUERADE OPENVPN" src-address=\
    10.158.38.0/24
add action=masquerade chain=srcnat comment="MASQUERADE WIREGUARD\r\
    \n" src-address=10.168.66.0/24
add action=netmap chain=dstnat dst-address=192.168.150.0/24 to-addresses=\
    10.1.1.0/24
add action=netmap chain=srcnat dst-address=192.168.70.0/24 to-addresses=\
    10.1.1.0/24
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=10.1.1.1 routing-table=main \
    suppress-hw-offload=no
/ip service
set telnet disabled=yes
set ftp disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/ppp secret
add name=client1 profile=ovpn_profile service=ovpn
/system clock
set time-zone-name=Europe/Rome
/system identity
set name=MAP-LITE-MY-OFFICE
/system logging
add disabled=yes topics=dhcp
/system ntp client
set enabled=yes
/system ntp client servers
add address=time.google.com
add address=time.cloudflare.com
/system routerboard settings
set auto-upgrade=yes
/system scheduler
add interval=1d name="Backup And Update" on-event=\
    "/system script run BackupAndUpdate;" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=dec/28/2021 start-time=23:10:00
add interval=1d name=reboot_night on-event="\
    \n:execute {/system reboot;}" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=jan/03/2017 start-time=04:01:00
add disabled=yes interval=1d name=schedule_autoupdate on-event="/system packag\
    e update\r\
    \ncheck-for-updates once\r\
    \n:delay 3s;\r\
    \n:if ( [get status] = \"New version is available\") do={ install }" \
    policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=jan/03/2017 start-time=04:00:00
/tool e-mail
set address=smtp.gmail.com from=my@gmail.com port=587 tls=starttls \
    user=my@gmail.com

thank you in advance

bpwl · Sat Mar 12, 2022 1:28 am

Please explain again your setup. hEX, ubiquiti, mAP Lite, hAP Lite, hAP ac2. The different outputs are just not consistent with one setup.

The last one is a DHCP server on mAP Lite for the (bridge_lan)-ether1 only.
How do these DHCP server connections make it to wifi? WLAN1 is not connected to the DHCP server (or bridge) on the mAP Lite.

pe1chl · Sat Mar 12, 2022 11:21 am

How about continuing the discussion about someone's particular problem outside the generic topic about DHCP server problem?

bpwl · Sat Mar 12, 2022 11:45 am

I hope forum administrators can move this to a separate topic.
And maybe drag this one in here, from 6.49.4 discussion: viewtopic.php?t=183744&hilit=dhcp#p917489

It has been there since 6.49, but no information found so far.
DHCP problems are seen since 6.38. Related somehow or not?
When and how to use it ? Are the 2 release notes lines saying the same ? Otherwise, how to set the 2nd ?
Code: Select all
*) winbox - added "dhcp" option to "multicast-helper" setting;
*) wireless - added override for multicast-to-unicast translation of DHCP traffic;
.
Or is this some enhancement of 6.40? "*) wireless - always use "multicast-helper" when DHCP is being used;"

aleab · Sat Mar 12, 2022 5:36 pm

sorry, of course could create a separate topic.

sorry again, i create confusion...

to explain i have this situation
# in my customer's office
hex (DHCP server) -- switch -- ubiquiti AP -- hap lite (AP client)

# in my lab (for testing)
map lite (DHCP server) -- switch -- provider AP -- hap ac2 or hap lite (AP client)

on both setup i have same issue.
in customer's office i install powerline to solve situation.
so now i can test only in my lab.

thank you again

aleab · Wed Mar 23, 2022 4:16 pm

nothing...

i test this setup at my home and works fine .
i try to another customer and works fine...

seems only on particular devices not work...
for now is not a problem, i use another vendor to setup this wifi client for ethernet printer...

thank you again

Belce666 · Wed Nov 09, 2022 4:22 am

Greetings.

I have a MKrb750gr3 as core router. I removed 2 unifi AP (have to sell them), and replaced them with 3 TP-Link products. (Archer c60 by now -changing to a C80-, 2 RE200 as wifi extender or repeater, and a WR840, all by TP-Link).

Im having a problem with MK DHCP. When i walk from a room where my cell phone connects to main (Archer c60) wifi router, DHCP works fine... i have a 172.16.0.0/20 network, with queue trees for each network. But when i move to another room where i installed a re200 wifi extender, cell phone connect, DHCP give me the correct IP Address, but traffic is blocked.

The only solution is, with my administration computer, log into the MK and "disable" and "enable" DHCP reservation of my cell phone. After doing this, the cell phone connects to the internet without changing nothing on the phone, just the "!" (no connection) sign dissapear.

pe1chl · Wed Nov 09, 2022 11:13 am

You need to read the replies above before you tag-on your personal problem.
Wifi extenders are trouble, especially when they are not from MikroTik (which you could configure in 4-address mode).
Connect everything by wire and configure it in plain bridge mode, and it will work.

Belce666 · Wed Nov 09, 2022 11:51 pm

ok, I will answer to myself. In my case was a stupid mistake. My core wifi router (Archer C60) does not support One Mesh tech. I was repeating the same SSID on all the wifi extenders/routers. Just assigned a different SSID to each wifi extender and now DHCP reservations works fine, by now...

I think until I can install a core wifi router with "One Mesh" cap. i will have to use many SSID as AP/routers/extenders i will install.

Greetings.

I have a MKrb750gr3 as core router. I removed 2 unifi AP (have to sell them), and replaced them with 3 TP-Link products. (Archer c60 by now -changing to a C80-, 2 RE200 as wifi extender or repeater, and a WR840, all by TP-Link).

Im having a problem with MK DHCP. When i walk from a room where my cell phone connects to main (Archer c60) wifi router, DHCP works fine... i have a 172.16.0.0/20 network, with queue trees for each network. But when i move to another room where i installed a re200 wifi extender, cell phone connect, DHCP give me the correct IP Address, but traffic is blocked.

The only solution is, with my administration computer, log into the MK and "disable" and "enable" DHCP reservation of my cell phone. After doing this, the cell phone connects to the internet without changing nothing on the phone, just the "!" (no connection) sign dissapear.

pe1chl · Thu Nov 10, 2022 10:35 am

Yes, but that is essentially the same as what I wrote. For an extender to work correctly you need the parent AP to support 4-address mode.
What marketing name they attach to that does not really matter.

Who is online