After a power outage the Tablo does not properly reconnect and therefore does not record shows.
This has happened several times. If there is a power outage the Tablo does not automatically reconnect to the Web properly and therefore shows do not record.
For example recently we went on vacation for two weeks. About a week into the vacation apparently there was a power outage and a weeks worth of the programs we wanted to record were not recorded.
If I reboot the Tablo it then connects and resumes recordings.
As far as I can tell from the several instances this has happened is that the Tablo boot faster than the router and there is therefore no DHCP server to hand out an IP.
Here is the stupidity of the situation in my estimation. The Tablo never re-tries to get an IP address after the initial failure to obtain one from the default DHCP server.
In my estimation it should retry let’s say every 5 minutes or even 10, 30 or even 60 minutes, but just not retrying is completely unacceptable. If I had a simple way of holding off the power to the Tablo until the router had rebooted I would do it, but that seems pretty kludge to me.
Has anyone else experienced this or does Tablo Support have any suggestions or could they fix this please.
Fizix
P.S. The ability to assign a static IP (at the Tablo not via IP reservation on the router) would also solve this problem - hint hint.
Yes, I have the same problem. We have had a number of power outages the last 3 wks and the Tablo has never come up. And yes I agree with you on the router reboot - mine takes about 3-4 mins to come online and the Tablo reboots in less than one minute. I do have a DHCP reservation set for Tablo. I will support your suggestion that the Tablo should retry every 5 mins until it comes up or shut down after 6 tries.
PS It always comes online after a 5min wait manual reboot after power is restored.
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK or a DHCPNAK message. The client
retransmits the DHCPREQUEST according to the retransmission
algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to give adequate probability of
contacting the server without causing the client (and the user of
that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
restarts the initialization process. The client SHOULD notify the
user that the initialization process has failed and is restarting.
DHCP clients are responsible for all message retransmission. The
client MUST adopt a retransmission strategy that incorporates a
randomized exponential backoff algorithm to determine the delay
between retransmissions. The delay between retransmissions SHOULD be
chosen to allow sufficient time for replies from the server to be
delivered based on the characteristics of the internetwork between
the client and the server. For example, in a 10Mb/sec Ethernet
internetwork, the delay before the first retransmission SHOULD be 4
seconds randomized by the value of a uniform random number chosen
from the range -1 to +1. Clients with clocks that provide resolution
granularity of less than one second may choose a non-integer
randomization value. The delay before the next retransmission SHOULD
be 8 seconds randomized by the value of a uniform number chosen from
the range -1 to +1. The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds. The client
MAY provide an indication of retransmission attempts to the user as
an indication of the progress of the configuration process.
No I have not, but I have a Harmony Hub, Philips Hue, Roku 3, Ring Doorbell, 4 phones, and 6 tablets that all use DHCP and have no problem reconnecting. I discount the Phones, tablets and the Ring since they are battery powered and may retain their address, but the Harmony, Hue and Roku go down and come up with the power, and they reconnect. I have therefore qualified the router by similarity.
Given that another user has experienced this and I have had no other DHCP issue with the Asus RT-AC88U router, I think it is fair to say that the issue lies with the Tablo. I have also verified that it does not appear in the Asus router’s client list when this happens.
Also how would the “user” get notified by the “client” [Tablo]? If there is no interface to recognize that it is there.
P.S. The reality is that I do not have the time to become a DHCP expert nor do I plan to buy a sniffer to troubleshoot this.
OK, I forgot to mention that I have over 30 clients with DHCP reservations and they ALL come online after a power failure - EXCEPT the Tablo. I also do not have a sniffer, but think this information that has occurred over 10 times in the last month is enough to prove the point. And my network is VERY good with NO problems with Tablo over two years except the power failure problem.
Almost all of the ethernet client/server standards have timeout and retry from the client as part of the standard. So it’s hard to identify just who or what is at fault without more information.
So was the DHCPREQUEST retransmitted after the appropriate timeout.
I’ve “enjoyed” several power outages since we’ve had the Tablo and haven’t had the problem like you describe, so there must be something else, mate. I’m on 2.2.10.
How long does your router take to reboot? Routers like the ASUS RT-AC88U have a lot of horsepower and functions so it takes them several minutes to boot after power is restored. So you have not convinced me that there is no Tablo side problem. I am running the latest firmware.
At zippy (won’t let new users @ more than two - geez)
I am confused by your reply. Tablo IS the client and therefore responsible for the retry. Again since many other clients (as confirmed by the other user also) have no problem coming back on line, the fault would seem to fairly conclusively point to the Tablo.
Furthermore, I follow information on my Router on SNB forums and if there were significant DHCP issues, I would expect to have seen significant traffic on the issue(s) there.
At Radojevic (geez again)
I have my main router and managed switch on a hefty UPS, so I have no issue with many shorter power outages. However, anything over about 20 minutes and the UPS shuts everything down in an orderly fashion (i.e. 4 NAS boxes, Router, Switch, Computer and Cable Modem. My wife and kids compters have their own smaller UPS’s.
Unfortunately we not infrequently have power outages that are over an hour long here.
SWFL here. Tropical storm country. UPS for the electronics, plus a backup generator for the house. Should be enough propane in the tank for 3-4 days if needed.
Like many others I don’t have any problems after a power failure. And I have 2 tablos connected into an intelligent switch which is then connected into a powerline adapter. Thus the tablos can’t access the dhcp server until the powerline adapters boot. And they take a long time to boot since they need to access the dhcp server.
So does the tablo retry the DHCPREQUEST and if that fails reenter the init flow. There is nothing to fix unless you have the answers to just a few simple questions.
So a few more data points about my system. The Tablo is connected to a switch which is connected to the router. The switch comes up almost immediately, but the router does not, so the Tablo immediately sees an active Ethernet connection, but the DHCP server is not yet ready.
I suspect that your powerline adapters do not offer an active ethernet (not IP connection, I am talking about the physical layer) connection to the Tablo until they are finished connecting to the DHCP server, so the scenario is NOT the same. My Phillips Hue hub and Harmony hub (both DHCP assigned are attached to the same switch and come up.
Just because I do not have the answer to the question you are asking does not mean the there is nothing to fix. To me that is sort of like saying “Although your computer won’t start, and your PSU will run a similar mother board, since you can’t measure the voltages on your PSU, there is nothing to fix.” This is not exact, but gives the idea.
You have not yet given a scenario that will allow the other DHCP dependent devices connected to this same interface that also boot quickly (like the Philips Hue hub and the Harmony hub) to connect just fine but not the Tablo.
Looking over the DHCP protocol I think the question of DHCPREQUEST is premature. The client must first issue a DHCPDISCOVER message. Since the router is not yet online it cannot respond with a DHCPOFFER message. The client should periodically send a DHCPDISCOVER until a DHCPOFFER is received.
Again clearly the DHCP server is receiving the messages from the other devices and offering them and granting the addresses.
Most powerline adapters are actively managed ethernet devices. And if they were not fully initialized where would the DHCPDISCOVER request go. Would it time out as you suggest for your configuration? And actually I have a router behind a ISP router. And the DHCP server is on the ISP router. So I not only have powerline but 2 routers that have to fully boot for tablo to get to the DHCP server.
I wonder if any retry might be involved in my setup. So what would suggest needs to be fixed to bring tablo inline with the standard.
I don’t think a device will even send the Discovery request until it sees an active ethernet (hardware) connection. So until the powerline adapters ethernet port enables (harware connection), I don’t think the Tablo (or any other connected device) will send a Discovery request.
I have been looking at the router capabilities and it appears that the RT-AC88U keeps all DHCP transactions in its system log, So I may be able to do some sleuthing after all.
I may try simulating a power outage by turning everything off and restarting the Tablo and then the Router & Switch, so that I can inspect the logs. That may shed some light on it.
My suggestion is that the Tablo should periodically (say every 5 mins) retry Discovery until it receives a valid DHCPOFFER.
At the moment my tablo won’t connect remotely. The router seems to see it as I have logged into the router remotely. I can’t reset the tablo because it is connected to an inaccessible plug. I will have to wait til I get home.