amazon fire tv not getting dhcp address after lease expires on mikrotik router

Harley2002 · Mon Jan 25, 2016 6:23 pm

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.

LincolnG · Wed Jan 27, 2016 6:25 pm

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.

Harley2002 · Thu Jan 28, 2016 4:19 pm

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.

momon · Wed May 18, 2016 2:41 am

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

NathanA · Wed May 18, 2016 10:01 am

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

efaden · Wed May 18, 2016 5:20 pm

Similar problem here....

takekazuomi · Tue May 31, 2016 11:26 am

I have same problem too.

luidoltp · Wed Jun 01, 2016 2:45 pm

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:

FireTV-DHCP.jpg

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:

W10-DHCP.jpg

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

luidoltp · Wed Jun 01, 2016 8:25 pm

I just checked ... The same behavior with RouterOS v6.34.5 and v6.36rc21.

Best regards,
Lui

pe1chl · Wed Jun 01, 2016 11:34 pm

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.

luidoltp · Mon Jun 06, 2016 4:08 pm

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:

ACK-difference1.jpg

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:

ACK-difference2.jpg

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

pe1chl · Mon Jun 06, 2016 5:02 pm

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.

luidoltp · Mon Jun 06, 2016 5:34 pm

Hi pe1chl,

thanks for your quick reply.

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)

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.

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.

I will try that and report my results.

When you did this test, did you still see the related ICMP message and was it present on the ZyWall as well?

The ICMP message was also there on the ZyWall. It seems that packets has no effect in that matter.

Best regards,
Peter

pe1chl · Mon Jun 06, 2016 5:39 pm

The ICMP message was also there on the ZyWall. It seems that packets has no effect in that matter.

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)

luidoltp · Tue Jun 07, 2016 1:29 am

Hi,

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.

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.

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)

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:
1) It skips the RENEWING state and instantly goes into REBINDING state (and uses a broadcast).
2) 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

[1] https://tools.ietf.org/html/rfc2131#section-4.4.5

pe1chl · Tue Jun 07, 2016 12:27 pm

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...

luidoltp · Tue Jun 07, 2016 9:08 pm

Hi,

Always nice to learn something!

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!!

Is the software on that device uptodate?

Yes, the software is "Fire OS 5.2.1.0 (550144920)" and the menu said that there where not updates available.

You could try filing a software bug, but it will probably be very difficult...

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

matterney · Mon Jul 18, 2016 1:32 am

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!

luidoltp · Mon Jul 18, 2016 12:37 pm

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

troykelly · Sun Jul 31, 2016 2:48 am

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.

efaden · Sun Jul 31, 2016 4:22 am

Same problem... I got a roku instead when Amazon support was useless.

Sent from my iPad using Tapatalk

trapdoor123 · Tue Aug 02, 2016 1:25 pm

I have exactly the same problem. I couldn't work out why my FireTV stick kept dropping out after a period of time - I figured it was an issue with wireless strength or something. So I spent the money and replaced it with the FireTV so that I could cable it directly to the main switch, but that drops out too! So not the wireless. I then recently bought a Kindle Fire tablet and unbelievably that is suffering from the same problem too!

No other devices on my network have any issues with DHCP renewals - it is only the Amazon devices. I have sent emails to Amazon outlining the problem and asking them to pass on the details (including a link to this post) to their development teams. It seems like this should be an easy fix - the standard Android DHCP client seems to work just fine! So I have done my bit - and if anyone else is told that no-one else has complained about this to Amazon, you can now safely politely let them know that they are misinformed!

luidoltp · Tue Sep 06, 2016 12:45 am

Hi,

I also got a Kindle Fire 7 (5th gen) running FireOS 5.3.1.0 in my hands and tested it. As trapdoor123 pointed out, the Kindle Fire has also the same issue. However the "reconnection" process (after the ip address is dropped) is faster (~ 3 sec). This is probably the reason why so little people recognize this issue.

Maybe it's a bold statement, but I wouldn't be surprised if all Amazon devices running FireOS have this issue.
Sadly there is still no response / acknowledgement from Amazon regarding this bug.

Best regards, Lui

p.s: I also got the chance to test a Kindle Oasis ebook reader (FW-Version: Kindle 5.8.2); this reader handles the DHCP renewal flawlessly.

Revelation · Sat Sep 10, 2016 3:44 am

You could try setting up a relay for the DHCP server. Now typically this is needed when a DHCP server sits in another subnet. Based on the Packet Capture I assume that it is a /24 and the gateway on the router is also the DHCP server.

What I would do is setup a relay pointing to the DHCP server for anything inbound on that interface - where you FireTV connects. This should capture Broadcast traffic over ports 67 & 68 and force them to the DHCP server. This may solve your issue.

pe1chl · Sat Sep 10, 2016 10:17 am

You could try setting up a relay for the DHCP server.

The issue has already been debugged and identified, please read back above.
It has nothing to do with a relay. It is a firmware bug in the Amazon devices.

Revelation · Sat Sep 10, 2016 3:06 pm

Actually if you read my statement again you will see that I never wrote that it was a problem with dhcp relay. What I gave you was a possible workaround to the behavior of the FireTV.

bigcw · Wed Mar 22, 2017 1:07 pm

This thread has not been updated for some time, does anyone have an update on the situation? I am having customers complain of the same issue.

Chris

bigcw · Wed Mar 22, 2017 3:39 pm

Replying to my own thread... I've bought a Fire TV as I was getting so many customer complaints and wanted to replicate the problem for myself.

Yes this does seem to be DHCP related; the problem goes away if you set a static IP.

From what I can see, the DHCP lease expires and the Fire TV renews it a few seconds later. All should be fine, except that this break in connectivity causes the box decide that there is no internet connectivity. Video will stop playing after any buffer has been used up. Even though the device has a new lease with the same IP address it still refuses to reconnect. Only a reboot of the Fire TV gets it back.

I am going to report to Amazon myself, but in the mean time has anyone else got anywhere?

Chris

gnvdude · Thu Apr 13, 2017 6:08 am

Replying to my own thread... I've bought a Fire TV as I was getting so many customer complaints and wanted to replicate the problem for myself.

Yes this does seem to be DHCP related; the problem goes away if you set a static IP.

From what I can see, the DHCP lease expires and the Fire TV renews it a few seconds later. All should be fine, except that this break in connectivity causes the box decide that there is no internet connectivity. Video will stop playing after any buffer has been used up. Even though the device has a new lease with the same IP address it still refuses to reconnect. Only a reboot of the Fire TV gets it back.

I am going to report to Amazon myself, but in the mean time has anyone else got anywhere?

Chris

Same issue. Just cross graded from my UBNT EdgeRouter to the Mikrotik. First issue was the 10 minute Amazon Fire TV stream issue due to base config setting at 10min lease. Extended to 24 hours. Did not fix. Came upon this thread. Topic push. I have really been impressed with the Mikrotik, but this simple issue is plain stupid, one I never encountered on my Ubiquiti Edge Router.

Any solutions other than static?

pukkita · Thu Apr 13, 2017 8:53 am

This doesn't look related to mikrotik DHCP server implementation, but actually poor implementation on the Fire.

Try setting authoritative=yes in the DHCP server config and see if it makes a difference.

gnvdude · Fri Apr 14, 2017 5:41 am

This doesn't look related to mikrotik DHCP server implementation, but actually poor implementation on the Fire.

Try setting authoritative=yes in the DHCP server config and see if it makes a difference.

DHCP server set to authoritative=yes

let's see what happens.

Let's say Amazon does have an issue with how they've programmed their Fire DHCP client. Until upgrading or cross grading to Mikrotik I've never encountered or even read about Amazon devices having an issue with DHCP lease timeouts and renewals. I had a 24 hour lease on my Ubiquiti and everything worked smooth. The Fire TV's can't even renew without issue with the Mikrotik, it totally goes offline. No issues with using my Synology or QNAP DHCP server and Fire leases. So I'm really going to point the finger at Mikrotik on needing to address this issue. All my echo devices appear to riding out the renewal storm without incident, or at least they aren't going belly up like the Fire. But the fact that this issue never surfaced for my using different routers and DHCP server designs I think Mikrotiks code needs to be examined. Not saying Amazon doesn't need to do their part either.

pukkita · Fri Apr 14, 2017 11:30 am

Can you paste a config export here?

pe1chl · Fri Apr 14, 2017 11:43 am

So I'm really going to point the finger at Mikrotik on needing to address this issue.

That is not how IT and standards work. When you check above, it has been identified as a problem in the Fire. The fact that others have worked around it does not mean that everyone has to.

Lex1020 · Fri Apr 14, 2017 2:11 pm

So I've actually looked into this issue before with my in laws. It's definitely an issue with the Fire TVs, both stick and set top box. As mentioned above the Fire TVs don't handle DHCP properly. They should be attempting to renew their lease 1 minute before it expires but they don't. Instead they don't renew their lease until it expires which causes it to say connectivity is lost. Assign it a static IP.

Sent from my LG-H872 using Tapatalk

axc27 · Sat Jun 17, 2017 10:44 pm

I can confirm the same problem with the current fireTV stick (I think they called it 2nd generation).
Loses IP address for a few seconds instead of renewing it in advance. Very annoying when streaming media.

I circumvented this problem by giving the fireTV stick a static DHCP lease with a 24hour expiration time. As I do not have my TV running 24/7 this is fine. Every time the TV is switched on, the 24hour countdown starts from the beginning.
It caused me some headache to find the issue, until I stumbled upon this thread and verified in the logs that the device looses the IP first, and then disconnects from the WLAN AP, just to reconnect right afterwards.

I can live with that, as I wanted the FireTV stick in a different IP range anyways. Nevertheless I only observed that behaviour on the FireTV (the only Amazon fire-device).
I have an IP range for devices which keep the NAS turned on. NAS does auto-shutdown when no connections and no devices in that IP range are up. And as I don't want my phones or tablets to keep the NAS on all the time, the main DHCP IP range is not covered here.

Best,
axc27

Wed Jun 21, 2017 2:19 pm

axc27, could you please test out the latest Release Candidate RouterOS version as it has such changes in the wireless that maybe could help for the dhcp issue with the amazon fire tv?
*) wireless - always use "multicast-helper" when DHCP is being used;

luidoltp · Thu Jun 22, 2017 12:19 am

@uldis: The problem also exists on the Amazon Fire TV 4K connected by cable.

ArtursL · Wed Jul 05, 2017 5:11 pm

Amazon Fire TV DHCP lease issue fixed since RouterOS 6.40rc31.

axc27 · Sat Jul 08, 2017 11:12 am

I just installed the current 6.40rc36 and can confirm: problem fixed.
The DHCP lease is now correctly reassigned with a fireTV stick 2 connected via WLAN.

THNX

Steveocee · Sat Jul 08, 2017 12:37 pm

This is really surprising. I have been using 2 fire sticks in my household over the last year with 2 different RB's (2011 & recently 3011) and haven't had this problem once.

I have always set dhcp authorative to yes though, maybe that would have been the sue now though as a fix is coming.

Who is online