Another DHCP issue

Hello,
Im having issues with DHCP server operation on Mikrotik RB750Gr3, ROs v7.4. Configuration is completely stock default, fresh after reset. I have a Tp-Link EAP 225 connected to the router to provide wifi connectivity. All of the linux devices (desktop, couple of raspberry pi’s) connected both via ethernet and wifi receive correct IP addresses from the pool and work fine. The issues are with both Windows and Android devices. Some of them work fine, and some get wrong IP addresses for some reason and are unable to connect to the internet. DHCP is set to take ips from the 192.168.88.x pool while the affected devices get for example 192.168.1.167 address and 192.168.1.1 gateway so are unable to connect. Here is log from my phone DHCP session:

13:19:04 dhcp,debug defconf received discover id 916208558 from 0.0.0.0 ‘1:ac:xx:xx:xx:xx:xx’
13:19:04 dhcp,debug,packet ciaddr = 0.0.0.0
13:19:04 dhcp,debug,packet chaddr = AC:xx:xx:xx:xx:x
13:19:04 dhcp,debug,packet Msg-Type = discover
13:19:04 dhcp,debug,packet Parameter-List = Subnet-Mask,Router,Domain-Server,Domain-Name,Interface-MTU,Broadcast-Address,Address-Time,Renewal-Time,Rebinding-Time,Vendor-Specific
13:19:04 dhcp,debug,packet Max-DHCP-Message-Size = 1500
13:19:04 dhcp,debug,packet Class-Id = “android-dhcp-10”
13:19:04 dhcp,debug,packet Client-Id = 01-AC-xx-xx-xx-xx-x
13:19:04 dhcp,debug lease not found, new lease, acquire
13:19:04 dhcp,debug ping 192.168.88.14
13:19:04 dhcp,debug defconf received request id 916208558 from 0.0.0.0 ‘1:ac:xx:xx:xx:xx:xx’
13:19:04 dhcp,debug,packet ciaddr = 0.0.0.0
13:19:04 dhcp,debug,packet chaddr = AC:xx:xx:xx:xx:xx
13:19:04 dhcp,debug,packet Address-Request = 192.168.1.165
13:19:04 dhcp,debug,packet Msg-Type = request
13:19:04 dhcp,debug,packet Server-Id = 192.168.1.1
13:19:04 dhcp,debug,packet Parameter-List = Subnet-Mask,Router,Domain-Server,Domain-Name,Interface-MTU,Broadcast-Address,Address-Time,Renewal-Time,Rebinding-Time,Vendor-Specific
13:19:04 dhcp,debug,packet Max-DHCP-Message-Size = 1500
13:19:04 dhcp,debug,packet Class-Id = “android-dhcp-10”
13:19:04 dhcp,debug,packet Client-Id = 01-AC-xx-xx-xx-xx-xx
13:19:04 dhcp,debug lease unexpected state 1
13:19:04 dhcp,debug ping done 192.168.88.14
13:19:04 dhcp,debug defconf sending offer with id 916208558 to 192.168.88.14
13:19:04 dhcp,debug,packet ciaddr = 0.0.0.0
13:19:04 dhcp,debug,packet yiaddr = 192.168.88.14
13:19:04 dhcp,debug,packet siaddr = 192.168.88.1
13:19:04 dhcp,debug,packet chaddr = AC:xx:xx:xx:xx:xx
13:19:04 dhcp,debug,packet Subnet-Mask = 255.255.255.0
13:19:04 dhcp,debug,packet Router = 192.168.88.1
13:19:04 dhcp,debug,packet Domain-Server = 192.168.88.1
13:19:04 dhcp,debug,packet Address-Time = 600
13:19:04 dhcp,debug,packet Msg-Type = offer
13:19:04 dhcp,debug,packet Server-Id = 192.168.88.1
13:19:34 dhcp,debug lease 192.168.88.14 expired

What could be wrong? I’m a beginner so I’m out of ideas. The only suspicious thing I can see in the logs is this line:
13:19:04 dhcp,debug,packet Address-Request = 192.168.1.165

Why the devices actually requests such IP and why it gets it if its outside of the configured pool?
Thanks for help!

Hiding the MAC cause only problem.

Your tp-link is not configured right.

For test add a dhcp-client inside routeros, if something reply (the tp-link) it have dhcp server active.

The tp-links have a shitty software: by default, even if they have to act only as an access-point, they also have the dhcp server on,
but who has chosen such an idiotic thing??? And even between the IP address renewal interval they wake up their dhcp server for a moment
and sometimes some peripheral stupidly takes another address and gateway at random.

They just thought of this thing with their feet.

People on Tp-Link forum (https://community.tp-link.com/en/business/forum/topic/168074) claim that it just an access point and it doesn’t have DHCP server built-in . It does not have any DHCP config options either so there is no way it can be badly configured. Are they wrong? I guess this issue is not fixable then and I need another AP?

every tp-link model have different software, and I do not have that exact model

do the dhcp-client test as suggested.

I already have DHCP client enabled for fetching router IP address from ISP. I see only one entry there and it looks correct. What should I set up there? Please be more specific I’m a beginner :wink:.

another dhcp-client on interface where ap is

“Couldn’t add New DHCP Client - can not run on slave interface”

Sorry, this time it’s my fault.
What I took for granted:
That you knew that when an interface is in a bridge, the bridge must always be used.


You try to the master (bridge)?

regardless of the “TP-Link software quality” @rextended’s response doesn’t explain why it works for linux devices and not android or windows. I see too many accusations made about other vendor’s products made, without any good evidence to support the claims.

I have no TP-Link access points, but I question the assertion made by @rextended based on other people that use the TP-Link access points without issue.

A request for an address in another subnet is not uncommon, especially with mobile clients. If they have a lease from another dhcp server that is still valid (hasn’t expired), then they will request that IP address. The dhcp server, if it is authoritative, will send a dhcp NACK. Then the client will start over, and make a request and accept the offer. If you want to understand more about dhcp, google for dhcp explained, and you will find many links.

See for example DHCP client may fail to obtain a DHCP-assigned IP address

So I would first verify that your router’s dhcp server is set to authoritative and see if that changes the behavior. When a server claims to be authoritative, the client is more likely to accept its “word”.

Also, can you do a packet capture with the linux, windows, and android devices? And if you have another dhcp server so you can give the devices a lease outside the scope of the router’s subnet/mask then it would be more interesting to see why the linux computers work, but android an windows don’t. You can capture packets to the routers’ ram or forward to another server (as described here PACKET CAPTURE FROM MIKROTIK TO WIRESHARK. If you prefer video instruction MikroTik packet sniffer basics

So what are you talking about?

I have all the tp-link access points of my customers that I have sold to them in the past (and then I stopped) and all those who buy and install themselves.

So we want to compare the experience with your nothing?

@rextended
I did as you adviced and apparently client got 192.168.1.151 address assigned. Is there some way to confirm that its the AP doing this? Can I view this DHCP server MAC somewhere?
Here are the logs:

15:11:44 dhcp,debug,packet dhcp-client on bridge sending discover with id 3990051832 to 255.255.255.255
15:11:44 dhcp,debug,packet flags = broadcast
15:11:44 dhcp,debug,packet ciaddr = 0.0.0.0
15:11:44 dhcp,debug,packet chaddr = 74:4D:28:xx:xx:xx
15:11:44 dhcp,debug,packet Host-Name = “MikroTik”
15:11:44 dhcp,debug,packet Msg-Type = discover
15:11:44 dhcp,debug,packet Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific
15:11:44 dhcp,debug,packet Client-Id = 01-74-4D-28-xx-xx-xx
15:11:45 dhcp,debug,packet dhcp-client on bridge sending discover with id 3213959058 to 255.255.255.255
15:11:45 dhcp,debug,packet flags = broadcast
15:11:45 dhcp,debug,packet ciaddr = 0.0.0.0
15:11:45 dhcp,debug,packet chaddr = 74:4D:28:xx:xx:xx
15:11:45 dhcp,debug,packet Host-Name = “MikroTik”
15:11:45 dhcp,debug,packet Msg-Type = discover
15:11:45 dhcp,debug,packet Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific
15:11:45 dhcp,debug,packet Client-Id = 01-74-4D-28-xx-xx-xx
15:11:46 dhcp,debug,packet dhcp-client on bridge sending discover with id 3213959058 to 255.255.255.255
15:11:46 dhcp,debug,packet secs = 2
15:11:46 dhcp,debug,packet flags = broadcast
15:11:46 dhcp,debug,packet ciaddr = 0.0.0.0
15:11:46 dhcp,debug,packet chaddr = 74:4D:28:xx:xx:xx
15:11:46 dhcp,debug,packet Host-Name = “MikroTik”
15:11:46 dhcp,debug,packet Msg-Type = discover
15:11:46 dhcp,debug,packet Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific
15:11:46 dhcp,debug,packet Client-Id = 01-74-4D-28-xx-xx-xx
15:11:47 dhcp,debug,packet dhcp-client on bridge received offer with id 3213959058 from 192.168.1.1
15:11:47 dhcp,debug,packet flags = broadcast
15:11:47 dhcp,debug,packet ciaddr = 0.0.0.0
15:11:47 dhcp,debug,packet yiaddr = 192.168.1.151
15:11:47 dhcp,debug,packet siaddr = 192.168.1.1
15:11:47 dhcp,debug,packet chaddr = 74:4D:28:xx:xx:xx
15:11:47 dhcp,debug,packet Subnet-Mask = 255.255.255.0
15:11:47 dhcp,debug,packet Router = 192.168.1.1
15:11:47 dhcp,debug,packet Domain-Server = 192.168.1.1
15:11:47 dhcp,debug,packet Broadcast-Address = 192.168.1.255
15:11:47 dhcp,debug,packet Address-Time = 43200
15:11:47 dhcp,debug,packet Msg-Type = offer
15:11:47 dhcp,debug,packet Server-Id = 192.168.1.1
15:11:47 dhcp,debug,packet Renewal-Time = 21600
15:11:47 dhcp,debug,packet Rebinding-Time = 37800
15:11:47 dhcp,debug,state dhcp-client on bridge entering <requesting…> state
15:11:47 dhcp,debug,packet dhcp-client on bridge sending request with id 3213959058 to 255.255.255.255
15:11:47 dhcp,debug,packet secs = 2
15:11:47 dhcp,debug,packet flags = broadcast
15:11:47 dhcp,debug,packet ciaddr = 0.0.0.0
15:11:47 dhcp,debug,packet chaddr = 74:4D:28:xx:xx:xx
15:11:47 dhcp,debug,packet Host-Name = “MikroTik”
15:11:47 dhcp,debug,packet Address-Request = 192.168.1.151
15:11:47 dhcp,debug,packet Msg-Type = request
15:11:47 dhcp,debug,packet Server-Id = 192.168.1.1
15:11:47 dhcp,debug,packet Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific
15:11:47 dhcp,debug,packet Client-Id = 01-74-4D-28-xx-xx-xx
15:11:47 dhcp,debug,packet dhcp-client on bridge received offer with id 3213959058 from 192.168.1.1
15:11:47 dhcp,debug,packet secs = 2
15:11:47 dhcp,debug,packet flags = broadcast
15:11:47 dhcp,debug,packet ciaddr = 0.0.0.0
15:11:47 dhcp,debug,packet yiaddr = 192.168.1.151
15:11:47 dhcp,debug,packet siaddr = 192.168.1.1
15:11:47 dhcp,debug,packet chaddr = 74:4D:28:xx:xx:xx
15:11:47 dhcp,debug,packet Subnet-Mask = 255.255.255.0
15:11:47 dhcp,debug,packet Router = 192.168.1.1
15:11:47 dhcp,debug,packet Domain-Server = 192.168.1.1
15:11:47 dhcp,debug,packet Broadcast-Address = 192.168.1.255
15:11:47 dhcp,debug,packet Address-Time = 43200
15:11:47 dhcp,debug,packet Msg-Type = offer
15:11:47 dhcp,debug,packet Server-Id = 192.168.1.1
15:11:47 dhcp,debug,packet Renewal-Time = 21600
15:11:47 dhcp,debug,packet Rebinding-Time = 37800
15:11:47 dhcp,debug,packet dhcp-client on bridge received ack with id 3213959058 from 192.168.1.1
15:11:47 dhcp,debug,packet secs = 2
15:11:47 dhcp,debug,packet flags = broadcast
15:11:47 dhcp,debug,packet ciaddr = 0.0.0.0
15:11:47 dhcp,debug,packet yiaddr = 192.168.1.151
15:11:47 dhcp,debug,packet siaddr = 192.168.1.1
15:11:47 dhcp,debug,packet chaddr = 74:4D:28:xx:xx:xx
15:11:47 dhcp,debug,packet Subnet-Mask = 255.255.255.0
15:11:47 dhcp,debug,packet Router = 192.168.1.1
15:11:47 dhcp,debug,packet Domain-Server = 192.168.1.1
15:11:47 dhcp,debug,packet Broadcast-Address = 192.168.1.255
15:11:47 dhcp,debug,packet Address-Time = 43200
15:11:47 dhcp,debug,packet Msg-Type = ack
15:11:47 dhcp,debug,packet Server-Id = 192.168.1.1
15:11:47 dhcp,debug,packet Renewal-Time = 21600
15:11:47 dhcp,debug,packet Rebinding-Time = 37800
15:11:47 dhcp,info dhcp-client on bridge got IP address 192.168.1.151
15:11:47 dhcp,debug,state dhcp-client on bridge entering state

Btw. is it safe to publish MAC adress on the internet?

what are the other parameters over the 192.168.1.151?

try to open in browser 192.168.1.1 (???) and see what device appear

When i open this address in the browser nothing happens.

Also:
nmap -sn 192.168.1.1
Starting Nmap 7.92 ( https://nmap.org ) at 2022-08-05 15:27 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.02 seconds

Screenshot in the attachment. What other info do you need?
Zrzut ekranu z 2022-08-05 15-29-00.png

The 74:4D:28 is assigned to RouterBOARD.

or you have another dhcp server that assign 192.168.1.x/24 on your network,

or you put on bridge with ISP also your local LAN (and the ISP give 192.168.1.x/24)

or you have two (check!) dhcp server on your routerboard, one give 192.168.88.x and the other 192.168.1.x

@Buckeye
DHCP server is set to authoritative by default.

for see fastly what is the MAC of the rogue dhcp server

once dhcp-client get the IP, ping on routerboard 192.168.1.1 and see what MAC appear on ip/arp

put on forum (remove serial number and dhcp-leases, if any) the results of pasting this on terminal:

/ip pool export
/ip dhcp-relay export
/ip dhcp-server export

check also if the export containing sensitive data before post.

Problem solved - its not APs fault - I have another device connected - an old Tp-link router with OpenWRT which is supposed to operate as a switch. It is supposed to have DHCP server disabled but apparently for some reason it malfunctioned and turned on again. Actually looking at the IP/ARP table got me in the right direction because there is another TP-Link mac (distinct from the AP) assigned to the 192.168.1.1 address. When I powered off this old router DHCP started to operate correctly. Thank you so much for help!

@Buckeye
In the end a tp-link device had to do with it anyway, huh???
:laughing: :laughing: :laughing: :laughing:

For future,
you can enable on /ip dhcp-server alerts a tool that scan the interface and warn on log if found another rogue DHCP-Server, with the rogue MAC address.