Community discussions

MikroTik App
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Another DHCP issue

Fri Aug 05, 2022 2:47 pm

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!
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 2:53 pm

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.
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 3:27 pm

People on Tp-Link forum (https://community.tp-link.com/en/busine ... pic/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?
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 3:38 pm

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

do the dhcp-client test as suggested.
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 3:43 pm

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 ;).
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 3:54 pm

another dhcp-client on interface where ap is
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 3:59 pm

"Couldn't add New DHCP Client - can not run on slave interface"
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 4:02 pm

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)?
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 883
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: Another DHCP issue

Fri Aug 05, 2022 4:07 pm

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
Last edited by Buckeye on Sun Aug 07, 2022 6:47 am, edited 1 time in total.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 4:16 pm

I have no TP-Link access points
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?
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 4:23 pm

@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 <bound> state

Btw. is it safe to publish MAC adress on the internet?
Last edited by matv on Fri Aug 05, 2022 5:07 pm, edited 1 time in total.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 4:25 pm

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
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 4:35 pm

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?
You do not have the required permissions to view the files attached to this post.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 4:35 pm

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
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 4:36 pm

@Buckeye
DHCP server is set to authoritative by default.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 4:39 pm

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
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 4:44 pm

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.
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue  [SOLVED]

Fri Aug 05, 2022 5:01 pm

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!
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 5:10 pm

@Buckeye
In the end a tp-link device had to do with it anyway, huh???
:lol: :lol: :lol: :lol:
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 5:12 pm

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.
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 5:14 pm

I actually enabled it for a while but it didn't report anything suspicious. Perhaps I did it wrong.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 5:16 pm

The reports are only on log, like: "dhcp alert on bridge: discovered unknown dhcp server, mac D8:0D:16:15:BB:88, ip 192.168.0.254"
(it is a TL-WA850RE when it renews the leased IP from the routerboard)
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 5:18 pm

My bad: tried it again and it actually works:
dhcp alert on bridge: discovered unknown dhcp server, mac 64:70:02:xx:xx:xx, ip 192.168.1.1
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 883
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: Another DHCP issue

Fri Aug 05, 2022 5:27 pm

@Buckeye
In the end a tp-link device had to do with it anyway, huh???
:lol: :lol: :lol: :lol:
Sounds like rationalization to me. :?
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 5:28 pm

no, it's a hidden apology, I answered to you bad before...
 
User avatar
Buckeye
Forum Veteran
Forum Veteran
Posts: 883
Joined: Tue Sep 11, 2018 2:03 am
Location: Ohio, USA

Re: Another DHCP issue

Fri Aug 05, 2022 5:42 pm

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
I still have no explanation for this, other than chance.
Anyone have a good explanation?
My guess is that they requested the address they previously leased, and accepted the offer from the dhcp server that offered to give them the one they requested.
But why would the windows and androids behave differently? Unless they didn't have a current valid lease in 192.168.88.0/24.
 
matv
just joined
Topic Author
Posts: 11
Joined: Fri Aug 05, 2022 2:28 pm

Re: Another DHCP issue

Fri Aug 05, 2022 5:45 pm

The thing is that my linux devices never leave my home network - contrary to Android and Windows devices. So your theory might actually be true.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Another DHCP issue

Fri Aug 05, 2022 5:46 pm

network topology can help,
and also that android do not wait the reply (I deduce it from log) but send another dhcp request during arp/ping test
maded from routerboard for test if the IP is already used,
and on 2nd request reply the 192.168.1.x

But, in the end, the problem was found.

Who is online

Users browsing this forum: Bing [Bot], Google [Bot], lurker888 and 65 guests