i’d like to ask if someone else encounters this problem with the newest RouterOS version: dhcp client (“WAN” port) “looses” IP. My router: MikroTIk hEX 6.41.3
The log says: dhcp,critical,error dhcp-client on WAN-ETH1 lost IP address X.X.X.X received NAK from dhcp server 0.0.0.0
The ISP gives dynamic ip-s, lease time is 6 hours (i can see this in ip-dhcp client).
The problem solves when the modem is restarted (nothing else is touched, the router isnt restarted).
If you guys/girls have any thoughts on this, please help me out, customer isnt happy… but i think its modem and/or ISP problem, but i dont know.
One more question: how can i view if the router automatically changes mac address of port? or something like this does not happen?! (I hope so, but if not, how can i check if my mac changed?)
Router keeps the mac unchanged on the port unless you do that manually. If the port is bridge, use administrative mac address for it. When dhcp client looses the ip, it asks for it again. If not, just force the refresh and see the timings of the newly provided ip. May happen you describe real error, but so far these things always worked fine for me.
I don’t think this sounds like your problem, but I’ll mention it anyway. An initial DHCP request will be sent via broadcast to 255.255.255.255, and replies are sent to 255.255.255.255. After all, the interface doesn’t have an IP address yet, so where else can the server send the reply.
DHCP renew requests are unicast to the issuing DHCP server. Make sure you’re allowing DHCP replies from the DHCP server IP address in your firewall rules.
A MAC address is only changed manually in all cases I’m aware of.
I’d suggest obtaining a packet capture of the incident for further evaluation. The NAK from 0.0.0.0 seems unusual to me, but I’d have to refresh my memory on specifics of how the renew and request work to be sure. A packet capture will provide the MAC address of the device that sent (or relayed) the NAK to you.
Thank you for ur time and answer!
Basically if it would be (please correct me if im incorrect) a firewall rule problem, this would occure on every dhcp release/renew right? But this happens randomly (like in the 2 last days they had 3 times this problem, before no one said anything but maybe they just didnt “see” the problem).
“Make sure you’re allowing DHCP replies from the DHCP server IP address in your firewall rules” → please tell me, how can i do this? (maybe: forward chain, source ip=dhcp server ip, and accept?)
Packet caputre → i never did it, bc i never had to. If you have the time and patience, please provide me an as well written asnwer like u did before
Okay, the MAC wont change until i force it (and i dont want to.) Its not bridged, its a “standalone WAN” port, which is a dhcp client and from the internal lan bridge’s ip range is NATted to the “WAN” port.
What did you mean by “see the timing of the newly provided ip”? Would please be a little bit more specific? I would appreciate that!
Thank you!
PS.: i use mikrotik at home too, and i have really no problems like this at home…
The inconsistency you describe doesn’t necessarily disprove a firewall issue since it’s possible a failure wasn’t noticed.
After DHCP renew fails and the DHCP lease time expires, the router loses the IP address. Then it sends a DHCP request to 255.255.255.255 again. Then it should obtain a new, possibly different IP address.
in your firewall rules, that should accept the DHCP renew reply. Of course, if you have a rule above this one that drops the DHCP reply, it will hit first and this rule will never be matched.
Here’s a packet capture config that sends the packets to a host.
/tool sniffer
set filter-interface=<monitored interface> filter-ip-address=10.28.0.135/32 filter-stream=yes streaming-enabled=yes streaming-server=10.28.0.50
This will capture packets on the monitored interface with a source or destination of 10.28.0.135, and send the packets to host 10.28.0.50. I’d use Wireshark to capture the packets on the 10.28.0.50 host myself. If you’re a Linux guy tcpdump does the same thing.
In /tool sniffer, type start to start the capture, and stop to stop the capture. Alternately, you can configure, start and stop from the GUI as well.
Then you can analyze the packets to justify your argument that this is probably something your ISP needs to fix.
Thanks again! I found something intersting ,maybe this could be the culprit… i imported the same config on an other mikrotik i have here and i put the WAN port on a simple SOHO Asus router, where i set 120sec lease time (thats the minimum for him) and i saw that the router renews the IP at 1 minute left → i tested it with 3 minutes, mikrotik renews at 1,5 minutes. So basically the situation is like this → mikrotik somehow forces to renew at the half ot the lease time… and the ISP (surelly, i dont know i just assume) doesnt enables dhcp requests, so only if the modem is rebooted do i get internet. It seems the problem is with mirktik now. How to change this? How can i set a dhcp client to release/renew only when the lease expires?? There is some problem with the dhcp client maybe?
Thanks for your reply.
I have read the RFC (during study)and do know how DHCP works. Nevertheless an RFC does not mean that Mikrotik is bug free regarding DHCP, it just states what functionality is used. Therefore referring to an RFC is not helping people in need and does not construct a way forward.
If you dont recognize this perhaps you havent attended tranning like CCNP, JICNP (even CCNA) or any other training from a professional equipement vendor.
I’m not saying DHCP client in ROS is bug free. I’m just saying that regarding re-lease timer ROS DHCP client works according to RFC and that @sjafka was looking at wrong symptom (which is clearly explained by RFC linked by @tippenring).
IMO the only problematic thing was you laughing at @tippenring due to linking RFC as a reply …
Reading RFC is very useful when you need to find out which end of a failed conversation is responsible for the failure. So in the OP’s case, the server was responding with a NAK to a renewal request coming after half of the lease time, and @tippenring gave that link to the RFC to explain why the renewal at half of the lease time is a correct behaviour, and starting to attempt to renew the lease after the time expires completely is not.
You have jumped in without describing your actual problem, just criticising someone else’s post from 2018 without even checking for the context. So what’s you actual issue with DHCP? The same symptom (NAK in the log) may have different reasons, and only sniffing the traffic and subsequent analysis can tell what the root cause is.
Im not trying to look smart, as i dont know the solution to this also (still looking to get a pcap file when it happens), i find it a waste, this RFC linking al the time and decided to repsond for once. I understand that this was not constuctive also, my apologies. However i do find that this happens a lot on this community and just wanted to state out that every time a person looks and finds inconsistancies it is better to dive into the logs then refering to something that will state how it should work. Ill have a go with wireshark en be usefull for once.
