It’s the only client I have an issue with. Actually I have two Fire Tv’s I’m only having an issue with the newer 4K version. Symptoms: Once the lease expires client disconnects from the network and I physically have to disconnect and reconnect patch cable and its fine until the lease expires again after seven days.
You could try adjusting the lease to a short time - five minutes for example and disconnect or switch off all the other devices, to see then if the lease renews - this will demonstrate if another device is conflicting for some reason.
It is also a good idea to make sure that the dhcp pool isn’t giving leases that actually exist on the network as statics. Go round, check every device if it has a static write it down. Where possible try to make sure all your static addresses are within a certain range 192.168.88.50 - 100 for example. And then edit the DHCP pool to provide addresses in a different range. Most people setup huge dhcp pools, like 200 addresses when there is on 20 devices possible - so of course a pool of 40 addresses is more than sufficient.
Next, make sure the name of the device is different from your other fire tv - they cannot be the same, but sometimes the manufacturers make the device name the same, because they never expect somebody to have two of them.
Failing that you could try removing that switch port from the master port and setup a seperate subnet with its own dhcp server and pool.
Or lastly give up and assign a static address.
Just out of interest, have you enabled uPNP on your routerboard. I had problems with my Playstation and Android TV until I did.
Tried all your suggestions before I posted before I posted, different lease periods had same consequences, moved device to different Vlan same. I just gave it a static.
I am so glad I came across this issue because I thought I must have something wrong and upon checking everything I concluded there was some sort of conflict between the amazon 4k network adapter and the way the lease renews on the mikrotik, this is what prompted me to search and google and found this post.
I have an identical issue to what you are describing, I have about 30 different clients connected to the 750 GL (cell phones, access points, tvs, etc). The only device that is presenting issues is precisely the Amazon Fire TV (4k version). I also have 1 FireTV Stick and one regular Fire TV (non 4k / first generation) and neither has this problem. Only the 4k version has this issue.
I have also gone through each of the clients and all are set to DHCP, not a single device is using static IP.
I’m guessing my immediate solution same as you would be to just give the amazon Fire TV a static IP or set the lease time to a year or something (which I don’t think is a good idea) but would be good to get some insights from someone at Mikrotik and see if someone else is able to reproduce the same issue.
Cheers
I just ran into this problem this past week myself! I don’t have a Fire TV, but a friend of mine just got one, and asked me for a router recommendation, so I told him to get a 951Ui-2HnD for his home. 
The default lease time on recent versions of RouterOS is very short: 10 minutes. And his Fire TV kept “losing” the network connection exactly every 10 minutes! I saw in the router logs that the Fire TV did not try to renew its lease until a couple of seconds after it expired.
I thought maybe a bug in the Fire TV firmware didn’t like short lease times, so I raised the lease time to 8 hours. Guess what? Fire TV now drops off the network every 8 hours.
I got fed up and finally just gave it a static.
I searched and searched to see if other people were having similar problems with Fire TV and DHCP but came up with nothing. I found this thread on the MikroTik forums by pure accident. I didn’t think it could possibly be a MikroTik problem because all other devices on the network work fine, and I have never experienced a DHCP client that has a problem with the MikroTik DHCP server.
I am still not convinced it is a MikroTik problem, but if it isn’t, it is a weird coincidence that the only place I have ever seen this discussed is on this forum, by other people who are also using MikroTik routers.
I have to believe this is a bug in the Fire TV…my understanding is that DHCP clients should renew their DHCP lease at the halfway mark of the lease time if they are still on the network and intend to keep the IP. So with 10 minute leases, the Fire TV should have been renewing every 5 minutes. With 8 hour leases, every 4 hours. In both instances, the Fire TV waited until just after the lease expired to renew it, which of course is too late.
It also seemed as though the problem only occurs when it is connected to the network with ethernet. When we tried it on WiFi it seemed fine.
– Nathan
Similar problem here…
I have same problem too.
Hi,
I also have a FireTV 4k and I investigated the problem in more detail. I used Wireshark to capture the DHCP renew communication between the router and the FireTV and came across a strange behavior. I set the lease-time to 3m so the renew occurs more frequently and is easier to capture.
The capture contains the initial assignment (cable was plugged in) and one renew process.
FireTV capture:
The FireTV sends a Broadcast DHCP-Request approximately 90 seconds before the lease is going to time out. The Mikrotik router responds with an DHCP-ACK containing only the remaining (short) lease-time. This procedure is repeated several times until the lease finally times out.
Then the FireTV drops its address and sends a new DHCP-discover. It gets assigned the same address with 3m lease-time. During that process the FireTV looses the network connection for approximately 20s.
There are also some strange ICMP packets that seem to have a problem. The router has no firewall configured and I can ping it from a laptop without problems. So I am not sure what’s the deal with them and if they are related to the problem.
Windows 10 capture:
In contrast a Windows 10 laptop sends a Broadcast DHCP-Inform 90 seconds before its lease would expire; gets an DHCP-ACK from the router and then sends a Unicast DHCP-Request directly to the Mikrotik. The router responds with a DHCP-ACK and new lease-time of 3 minutes.
I used a hAP lite with RouterOS v6.35.2. The FireTV / Windows 10 Laptop where both connected by cable to ether2. A laptop running Wireshark is connected to ether3. The mirror-source is ether2 and the mirror-target is ether3. A export of the configuration is attached.
Sadly I am not skilled enough to determine if the Mikrotik or the FireTV misbehaves or if it is a combination ob both. I also tried to find the correct “dhcp renew” process but didn’t find the specifics. I only found that there has to be a DHCP-Request followed by a DHCP-ACK.
Can anyone take a look and give me a hint what is going wrong?
I would really like to chase that error down and be able to report it to those who can fix it.
Any comment is highly appreciated!
Best regards,
Lui
Wireshark-captures_and_router-config.zip (2.49 KB)
I just checked … The same behavior with RouterOS v6.34.5 and v6.36rc21.
Best regards,
Lui
Those ICMP packets don’t have a problem, they indicate a problem.
The router sends back a DHCP ACK and the device says that the port this reply is sent to is unreachable.
You need to re-do the trace and expand it to full detail for one of those DHCP request/DHCP ack/ICMP exchanges,
and maybe also for the correct one. Then look into the several option bits and fields and see what is different.
It may be something simple like a “broadcast” flag with incorrect value, or the device may want to receive the
reply as a broadcast instead of a directed reply.
It would help when you can also make a trace of the device making a DHCP request against another router that
handles the situation correctly.
Hi,
sorry that it took me so long to dig further into this issue.
Thank you pe1chl for your response. I tried what you suggested and captured the renewal process when the FireTV is connected to a different router. I used a ZyWall USG 100 (works fine with the FireTV).
The DHCPREQUEST sent from the FireTV is identical (apart from checksums and IP addresses).
The DHCPACK responded from the routers is however different in some parts.
The setup with MikroTik is shown left; the setup with the ZyWall is shown on the right:
First difference is that the “seconds elapsed” (secs) field in the dhcp packet is set to 0 by MikroTik (in contrast the ZyWall set it to 90).
In the RFC2131 on page 9 it is stated that this field is “Filled in by client, seconds elapsed since client began address acquisition or renewal process.”. This defines the field in the DHCPREQUEST. On page 27 there is a explanation that the secs field can be 0 in the DHCPACK packet; but this is referring to the initial DHCPDISCOVER message.
So I think this difference doesn’t matter regarding our problem.
The setup with MikroTik is shown left; the setup with the ZyWall is shown on the right:
The second difference is that the “IP Address Lease Time” (option 51) is responded with the short remaining lease time by the MikroTik. The Zywall reset this value to the initial 3 minutes.
The third difference is that the “Renewal Time Value” (option 58) and the “Rebinding Time Value” (option 59) are not sent by the MikroTik at all. Those options where requested by the FireTV.
In the ZIP-File I attached are the Wireshark pcapng files as well as the two text-files you see in the screen shots. The text files contain the two packages that are involved in the renewal process in full detail (one DHCPREQUEST and one DHCPACK package for each setup).
Can anyone confirm that the DHCPREQUEST from the FireTV is correct?
I am wondering if the responded (short) lease time by the MikroTik is correct. Should the ACK from the MikroTik look like this?
RFC2131:
https://tools.ietf.org/html/rfc2131
Best regards,
Lui
Capture-details.zip (6.48 KB)
I think it does not look that bad…
Of course the lease time from the MikroTik is very short, but I think you have set that yourself to debug it.
(i.e. you could set it higher in the DHCP server but then you have to wait longer to reproduce the same issue)
You could try adding the two options manually to the MikroTik DHCP server (a somewhat laborious task, but
it is made simpler because you have the packet from the ZyWall where you can see these options) and check
if that solves it.
When you did this test, did you still see the related ICMP message and was it present on the ZyWall as well?
Because when the router rejects the ACK that way, of course it is not going to process it, and playing with
option fields is probably not going to help.
Hi pe1chl,
thanks for your quick reply.
I indeed set the lease time to only 3m for debugging purpose. With “short lease time” from MikroTik I meant that the ACK is sent with the remaining lease time and not the full 3m. So on the client (the FireTV) the lease runs out because it is never extended.
If I set the lease time to a higher value the problem is still there … only it occurs less often.
I will try that and report my results.
The ICMP message was also there on the ZyWall. It seems that packets has no effect in that matter.
Best regards,
Peter
Yes, it may be that the DHCP client is listening on a raw socket and sees the reply, while there is a firewall
that rejects the reply in the normal INPUT path. Not very friendly, but it should not disrupt operation.
In that case fiddling with the 2 options may still work.
However, the fact that the router does not reply with a new full-length lease when it is re-requested after
half the lease period is also a bit strange. Maybe that is a bug, but then it should be possible to find
the conditions when it occurs because the DHCP server normally works OK for PC and other clients.
(in my experience, at least)
Hi,
I modified the dhcp-server so that it sends those two options as well. I used the following dhcp-server config for that.
/ip dhcp-server
add address-pool=pool1 disabled=no interface=ether2 lease-time=3m name=server1
/ip dhcp-server option
add code=58 name=RenewalTimeValue value="'90'"
add code=59 name=RebindingTimeValue value="'157'"
/ip dhcp-server network
add address=10.0.0.0/24 dhcp-option=RenewalTimeValue,RebindingTimeValue dns-server=10.0.0.1 gateway=10.0.0.1
I verified with Wireshark that the options are really sent. Sadly it didn’t help. The lease time still does not renew properly.
I checked with three other devices as dhcp clients (a Windows 10 laptop, a RPi and another MikroTik router). The main difference is, that all those three devices send a unicast to the dhcp server to renew the lease. The FireTV however sends a broadcast.
In section 4.4.5 of the RFC2131 [1] the reacquisition and expiration is explained. If I understood it correctly there are two states the client can go into. The RENEWING state and the REBINDING state. The client should go in the RENEWING state first and use a unicast packet to request an extension of the lease time. If there is no response from the dhcp server the client proceeds in the REBINDING state and sends a broadcast.
So I blocked all unicast packets to the dhcp server to force my laptop to enter the REBINDING state. The laptop (as expected) sent a broadcast packet and got a correct response with the full lease time. With this capture I finally was able to pinpoint the problem! 
The FireTV didn’t set the client ip address to its current address but used 0.0.0.0 instead. Regarding to the RFC the “Client IP address” (ciaddr) has to be set in the DHCPREQUEST (no matter if RENEWING or REBINDING state; see last part of RFC2131 section 4.3.2).
To me it looks as if the FireTV does two things wrong:
- It skips the RENEWING state and instantly goes into REBINDING state (and uses a broadcast).
- The DHCPREQUEST is sent without a proper ciaddr (this is probably the main problem).
It is still strange that RouterOS does not respond with the full lease time.
Best regards,
Lui
Always nice to learn something!
Is the software on that device uptodate?
You could try filing a software bug, but it will probably be very difficult…
Hi,
I can absolutely confirm that
Thanks for your time helping me to hunt this bug. Without your hints I wouldn’t have come that far! Much appreciated!!
Yes, the software is “Fire OS 5.2.1.0 (550144920)” and the menu said that there where not updates available.
The Amazon customer support was quite helpful. They told me they can forward my bug report to the development team if I send it in by email (so I did).
I am not expecting that Amazon will fix this issue anytime soon … but I am gladly proven wrong. If I get any feedback from them I will update this thread.
Best regards,
Lui
I’m seeing the same issue. Running Router OS 6.35.4 on RB 450G. Hard wired Amazon Fire TV - latest version. DHCP kicks every 10 minutes. I had to set a static IP to stabilize. Any progress on a solution from Amazon or MikroTik?
Thanks!
A week ago I asked the Amazon customer support if they have any new information regarding this issue. They informed me that they only can forward a bug to the development team but have no access to see its actual status. 
It would be interesting if other professional equipment (like Cisco, Juniper, …) handle the DHCP renewal with Fire TV differently. Sadly I don’t have such devices at home to test that myself. I would be really nice if someone (that has that equipment) could run this test.
What still puzzles me is, that so little reports about this Fire TV DHCP issue can be found online. It seems rarely anyone has this issue (or isn’t aware of it); so probably the majority of home routers handle the DHCP request differently and are not as strict as MikroTik is.
Best regards, Lui
I’m also experiencing this issue - I too reached out to Amazon to be told that not a single user has complained about this issue and as they have not had any complaints - have not started work towards a resolution.
Could everybody experiencing this issue please request some sort of formal acknowledgment from Amazon (a ticket number, or something)? It would seem this is just on the “we don’t care” pile at the moment.