[solved] dhcp-client at WAN is stuck with status searching

Hi, as I mentioned recently I’m a noob in the mikrotik’s world and have a few basic knowledge about networking.

I installed a hEX Router at home to manage a single LAN and two ISP (at this point not interested in load balancing, etc) from scratch (without the wizard setting).

My two ISP needs a DHCP Client but I have some issues with ISP2 (MitraStar GPT-2541GNAC):
Some times the dhcp-client stucks “searching” when the IP lease expires. Other times I manually release the lease to test one dhcp-client’s script and again stucks “searching”.

I have running the ISP2’s modem over three years without issues from PCs, Ubiquiti ER-X and OpenWRT.
I guess in some way my mikrotik floods or knocks the DHCP Server running at ISP2’s modem, but all works fines with the ISP1’s modem (Huawei EchoLife HG8245Q2).
I discarded an physic issues inverting ports and replacing patch cords.

I made a research at the forum but the dhcp-client searching issues are not related with my actual scenario.
At this point I have no idea where to see or what to touch :frowning: I guess I’m mispelling some mikrotiks config.

Thanks :slight_smile:

Wire diagram:

                   Mikrotik hEX (RB750Gr3)

ISP1 (FTTH)  --->  port 1 (wan1)

ISP2 (FTTH)  --->  port 2 (wan2)

                   port 3-5 (ether3-5)  --->  LAN Switch (bridge)

My config at WinBox:

interesting problem and I don’t have an answer to. maybe some of the options in DHCP client but that’s pure guess.

what if you give it an static IP, would it hold it without fail?

solar77: The DHCP-Client has hostname and clientid. Are you talking about those options?

Can the Mikrotik’s DHCP Server listening at bridge (interface) generate any conflict with the MitraStar’s one listening at wan2 based on subnet or a wrong firewall rule?

Here I found some “interesting” logs:

Perhaps this is unrelated but I saw some assigned IP lease from all instead dhcp-casa server.

Here my FireWall rules:

Filter rules

> ip firewall filter print
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 
 1    chain=input action=accept connection-state=established,related,untracked log=no log-prefix="" 
 2    chain=input action=drop connection-state=invalid log=no log-prefix="" 
 3    chain=input action=accept protocol=icmp log=no log-prefix="" 
 4    chain=input action=drop in-interface-list=!LAN log=no log-prefix="" 
 5    chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 
 6    chain=forward action=accept connection-state=established,related,untracked log=no log-prefix="" 
 7    chain=forward action=drop connection-state=invalid log=no log-prefix="" 
 8    chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=no log-prefix=""

NAT Rules

> ip firewall nat print      
 0    chain=srcnat action=masquerade out-interface-list=WAN log=no log-prefix="" 
 1    ;;; DNS Redirect
      chain=dstnat action=dst-nat to-addresses=10.0.0.3 to-ports=53 protocol=udp src-address=!10.0.0.3 dst-port=53 log=no log-prefix="" 
 2    chain=dstnat action=dst-nat to-addresses=10.0.0.3 to-ports=53 protocol=tcp src-address=!10.0.0.3 dst-port=53 log=no log-prefix="" 
 3    chain=srcnat action=masquerade protocol=udp src-address=10.0.0.0/24 dst-address=10.0.0.3 dst-port=53 log=no log-prefix="" 
 4    chain=srcnat action=masquerade protocol=tcp src-address=10.0.0.0/24 dst-address=10.0.0.3 dst-port=53 log=no log-prefix="" 
 7    ;;; http test
      chain=dstnat action=dst-nat to-addresses=10.0.0.198 to-ports=8000 protocol=tcp in-interface-list=WAN dst-port=8000 log=no log-prefix=""

Thanks :slight_smile:

hostname and clientid are standared. this is to say what the DHCP server would look for when give IP address

looks like the DHCP server is actively refusing to give 192.168.1.10 to ether2 of the Mikrotik
please check and ensure there is not another client , either static or DHCP, on the same router is using this ip address.
also check that the MAC address of ether2 is not a duplicate of anything else that is connected to the MitraStar router
of there is a loop somewhere?

/system logging add topics=dhcp

This will give you more details of what is going on with the DHCP client as well as more about the DHCP server “all”, what the IP is for this DHCP server.

your firewall rule is fine, it’s just the default
your NAT rule looks OK, disable / remove rule 3 and 4 as these are not needed for DNS redirection but that’s inrelevent to this DHCP client issue.

also just to double check, you took ether2 out of the bridge, did you?

I did factory reset on the MitraStar, and the MikroTik is the only device connected him, but I will check again.

I saw at logs (see bottom) DHCP-Client sends Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific
Question: Can this params generate a denegation on the MitraStar’s DHCP Server?

Here the bridge’s config

And here the logs.

Logs after manually release the DHCP-Client: https://gist.github.com/nachopro/de060b69ed8eb76b0158a44ebac20193
Logs after turn off and turn on the MitraStar: https://gist.github.com/nachopro/583c95be43c37bb90b1788bb4b842ff2

Thanks again

/export hide-sensitive file=anynameyouwish

Yes! https://gist.github.com/nachopro/a7b5086b1a681f01df95d15ac2301fe7

Looks okay for the most part, the only thing I dont understand is the following
add action=dst-nat chain=dstnat comment=“DNS Redirect” dst-port=53 protocol=
udp src-address=!10.0.0.3 to-addresses=10.0.0.3 to-ports=53
add action=dst-nat chain=dstnat dst-port=53 protocol=tcp src-address=
!10.0.0.3 to-addresses=10.0.0.3 to-ports=53
add action=masquerade chain=srcnat dst-address=10.0.0.3 dst-port=53 protocol=
udp src-address=10.0.0.0/24
add action=masquerade chain=srcnat dst-address=10.0.0.3 dst-port=53 protocol=
tcp src-address=10.0.0.0/24

What are you attempting to accomplish??
If you simply want to force users to use ROUTER DNS, then following suffices…
add action=redirect chain=dstnat comment=
“Force Users to Router for DNS - TCP” disabled=yes dst-port=53 protocol=
tcp src-address-list=yourdefined_firewall addres-xxxxxxx (OR interface-list=yourdefined-interfacelist-yyyyyyyy)
add action=redirect chain=dstnat comment=
“Force Users to Router for DNS - UDP” disabled=yes dst-port=53 protocol=
udp src-address-list=xxxxxxx (OR in-interface-list=yyyyyyyyy)

As for your WAN issues, try simple wan without the script. If it works you know your script is buggy.

anav I have a post about the DNS redirect: http://forum.mikrotik.com/t/redirect-outgoing-dns-requets-to-internal-dns-server/139894/1 I’ll try what you suggested, thanks.

TL;DR;
MitraStar breaks their own DHCP Server if a client is named “hex” :laughing:

I think found the solution… the last 35 releases proves it :laughing: xD

If I name the Mikrotik as “hex” the MitraStar shows an empty entity in their DHCP Server Leases list :open_mouth:
Next, when I trigger a release it dissapears :open_mouth:

The solution that I found is change de F :astonished: CKING hostname of the Mikrotik to any other string :laughing: :laughing: :laughing: :laughing: :laughing: :laughing: :laughing:

Thank so so sooooo much to all of you.

Glad you found the fix. Sorry I find it a bit funny, the problem was that you named a Mikrotik hEX “hex”… :laughing: :laughing: :laughing:

A friend was setting up folders for equipment in his database. He used valves, pipes, pumps, etc as folder names, but he could never access any files in the pipes folder.
It turned out pipes was a reserved word in the operating system.

This is a funny story with a happy ending!!