Tablo Ripper 2.4.1 Stopped working after 2.2.26 update [SOLVED] IP Address problem

#1

After the Tablo 2.2.26 update my Tablo Ripper stopped working. I am running Ripper 2.4.1.

I tried loading the ripper on a second computer and it did not work there either.

The ripper program will load, it finds my Tablo by name, flashes that it is “load record list” and initializing, and then just stops.

I tried renaming the data directory in case there might have been corruption. But no help.

The Tablo works just just fine. It records all of my shows, works with my Ruku and the Chrome app.

The Tablo is on the local network with a fixed IP. There have been no changes to the router.

Here is a snippet of the log file: (X’ed out my IP)

“2019-05-02 00:29:53.445721+00:00”}], “success”: true}
5/1/2019 7:49:59 PM IsTabloListLoaded=True
5/1/2019 7:49:59 PM 1 device(s) found.
5/1/2019 7:49:59 PM Matched Tablo2(XXX.XXX.XXX.15)
5/1/2019 7:49:59 PM cbxTablo_SelectedIndexChanged
5/1/2019 7:49:59 PM GetRecordingList_Selected
5/1/2019 7:49:59 PM GetTabloList
5/1/2019 7:49:59 PM cbxTablo_SelectedIndexChanged
5/1/2019 7:49:59 PM InvokeApi
5/1/2019 7:49:59 PM JSON: {“cpes”: [{“http”: 21020, “public_ip”: “73.45.17.170”, “ssl”: 0, “host”: “tablo-quad”, “private_ip”: “XXX.XXX.XXX.15”, “slip”: 21021, “serverid”: “SID_5087B801171A”, “inserted”: “2018-08-24 20:15:26.750823+00:00”, “server_version”: “2.2.26rc1910517”, “name”: “Tablo2”, “modified”: “2019-05-02 00:29:53.483721+00:00”, “roku”: 0, “board”: “quad”, “last_seen”: “2019-05-02 00:29:53.445721+00:00”}], “success”: true}
5/1/2019 7:49:59 PM IsTabloListLoaded=True
5/1/2019 7:49:59 PM 1 device(s) found.
5/1/2019 7:49:59 PM Matched Tablo2(XXX.XXX.XXX.15)
5/1/2019 7:49:59 PM cbxTablo_SelectedIndexChanged
5/1/2019 7:49:59 PM GetTabloRecordingList
5/1/2019 7:49:59 PM InvokeApi
5/1/2019 7:49:59 PM Exception: The remote server returned an error: (401) Unauthorized.

Any help please…

#2

All I can tell you is that Tablo Ripper is working properly on both of my 4-Tuner Tablos running on 2.2.26. @CycleJ developed this program and perhaps he can look at your log and determine where the problem is. Good luck.

1 Like
#3

TabloRipper also working on my 4 tuner and Quad, both running 2.2.6.

1 Like
#4

Just curious…what Tablo model are you running? I have a Dual Lite and even though I can get the upgrade I haven’t done so yet. TR is more important to me than the commercial skip feature. The 4 tuner models seem to be OK with the update…wondering if it is a problem with only the 2 tuner models.

#5

Reading through @Splawn’s log file it appears that the problem is with a Tablo Quad unit.

The only problem I have seen with recordings that have been processed for commercial skip is that they typically take approximately 50% longer to download. Once downloaded, I can edit them just like unprocessed recordings.

#6

I found my problem. I do not use a standard 10.x or 192.x network addressing. I use my own numbering system and rely on NAT for internet access. So the 2.2.26 update thought that none of my devices where on the same network as the Tablo.

My problem got worse when I turned off remote access in the Tablo. As soon as I did, all of my Rokus stopped working as well. The 2.2.26 update somehow has changed the way it handles network addressing. I called Tablo, had them roll me back to 2.2.24 and all is as it was.

#7

Glad you figured it out - the exception you reported seems to happen then the Tablo doesn’t like the client (your TabloRipper PC in this case).

I’m not sure what Tablo’s network restrictions are for client/server connections, but you seem to have found a new one.

503 Server Excpetion Error
#8

The official reply from Tablo follows, and the IANA/ICANN standard for the internet. (which I do not follow on my private network):

It looks like because your Tablo and client(s) are on atypical subnets, it’s causing an authentication issue for LAN communications. We have made some security improvements in the 2.2.26 firmware, which is why this is only apparent now.

The Internet Assigned Numbers Authority (IANA) reserves the following IP address blocks for use as private IP addresses:

10.0.0.0 to 10.255.255.255
172.16.0.0 to 172.31.255.255
192.168.0.0 to 192.168.255.255

I use an address range outside these ranges. Tablo 2.2.26 restricts local clients to the above address ranges. ( I am behind my own firewall, I can address how I want. NAT takes care of the rest.)

All of my other devices allow me to program their adresses, subnets, and gateways, therefor I had no problems. Becase I am behind a router and firewall under my control, this had not been an issue before the update.

So when I updated to 2.2.26 and had the Tablo’s remote access turned on, the Roku’s kept working through the Tablo’s remote LAN port, but the ripper could not authenticate because of it’s non-supported IP address. Once I turned off the remote access port on the Tablo the Roku’s also stopped working leaving me dead in the water. Nothing worked.

After Tablo support realized what had happened (see above) I was backed out to 2.2.24 and everything is working again.

Thank You Tablo for tightening security!
Request: give your Tablos configurable IP adressing.

My 15 year HP printer has this as standerd!

1 Like
#9

Actually, you’re wrong about that. If you use any address block other than the IANA approved ones, you could get into a situation where your internal devices will not connect to certain Internet sites. Since public IP addresses can be anything other than the IANA private blocks, it’s possible a DNS lookup for a site could return an address that conflicts with your internal network numbering. So you would end up trying to connect to a local address when you actually want an Internet one.

What’s your rationale for not using one of the approved address blocks?

1 Like
#10

Yes and no. It’s networking, it’s software… and yes, you can do whatever you want. Sometimes this is useful (hacking for example, and there are actually more legitimate cases…). But if you’re not into the darker or mystical arts, it’s wise to follow the guidance given.

2 Likes
#11

FlyingDiver,

I configure my router’s DHCP to use FreeDNS which will never return an adress on my own network as my computers are not registered on any DNS servers. Do you even know how DNS works?

I use an aproved IP adress between my internet provider and the modem and my router. It is only on LAN that I use a non aproved IP block. Once I get passed the “aproved” IP, I configure my router’s DHCP to use FreeDNS which will never return an adress on my own network as my computers are not registered on any DNS servers.

The IANA aproved blocks of IP adresses are for use when they face the internet directly. My LAN/IP do not.

I use NAT translation in my router wich makes ALL OF MY DEVICES LOOK LIKE AN APROVED ADDRESS. I.E. All of my devices have the same IP adress, that of my ROUTER. My router has an address from Xfinity wich faces the internet.

I have had this setup since I have had cable internet without any problems.

I use a non standard block because the numbers are easier for an old fart like me to rember for my static ip devices such as my printers and TABLO.

But through this all they still can remotely connect to my device, go figure that:

[LAN access from remote] from 45.79.173.217:48420 to 166.166.166.15:8887 Thursday, May 23,2019 21:33:59
[LAN access from remote] from 45.79.173.217:49986 to 166.166.166.15:80 Thursday, May 23,2019 21:33:59

And it is a non standard device. GO figure.

#12

#13

Riddle me this - you’re using 166.166.166.XX on your internal LAN. What happens when you try to connect to some Internet server that’s using a legitimate IP address in that network range?

BTW, this is not a DNS problem. And yes, I know very well how DNS works. I did this stuff professionally for quite a while.

1 Like
#14

This is the part that interests me. Maybe it’s just an age difference but the “approved” IP ranges are the only ones I’ve ever used so THEY are actually the ones easier for me to remember. :slight_smile:

I was curious to as to what the reasoning behind you using a non-standard block would be. To each his own but I think when you choose to do that, you are the minority and I wouldn’t expect most products to just support that. Having said that, I get your point about having the ability to specify IP, subnet, etc. but from a support perspective, when trying to reach a wider range of potential users, a good portion of whom are probably not very technical, it makes sense to make it as “idiot proof” as possible out of the box.

I’ve got a technical background myself and enjoy tinkering but quite honestly I’ve never even entertained the thought of using public IPs on my LAN devices. I know it should never happen, but in business situations I HAVE seen it happen because of really bad network configuration and assumptions.

2 Likes
#15

Nilex,

Actually this whole conversation is irrelevant. If Tablo had just left in the ability to configure the network like they had up to 2.2.24. This would be a non-issue.

If you go searching through the community you will find other people that have had similar issues before 2.2.24. For instance, if they had the Tablo on segment of the network and the client on another, the two would not communicate except through the remote port on the Tablo. This is not acceptable.

Can I be the only one with this problem? Are there no business’ using a Tablo with a registered IP?

I am abandoning this conversation as of now.

I will not respond to further inquires.

#16

Finally.