Tivo Control Station 1.1.2

[dgi]

That seems to have done it. TCS reported the network back up at exactly that time. Before that, I thought it might help if I restarted the TiVo, and discovered another TCS bug: If the network server is running while rc.sysinit.author starts TCS, the TiVo doesn't respond to the remote until it is restarted with the network server not running. This is consistently reproducible.

As for the dig thing, it seems the BSD dig in OSX doesn't have an option for TCP/UDP, so I had to go to the Debian-m68k box. My ISP's nameservers respond to both TCP and UDP, but my router only responds to UDP. This is useful to know, but somewhat irrelevant, because "no nameservers are responding" evidently doesn't mean that they don't respond, but that www.zirakzigil.net can't be resolved.

[Zirak]

Originally Posted by dgi

That seems to have done it. TCS reported the network back up at exactly that time. Before that, I thought it might help if I restarted the TiVo, and discovered another TCS bug: If the network server is running while rc.sysinit.author starts TCS, the TiVo doesn't respond to the remote until it is restarted with the network server not running. This is consistently reproducible.

I can understand why that may happen, but not why it would persist. How long did you wait before pulling the plug? Startup is a busy time for the tivo, even more so if you run "heavy" startup hacks including tcs and tivoweb. How long did you wait? Can you reproduce the issue now that the website is back up?

As for the dig thing, it seems the BSD dig in OSX doesn't have an option for TCP/UDP, so I had to go to the Debian-m68k box. My ISP's nameservers respond to both TCP and UDP, but my router only responds to UDP.

I'm not sure what this means, since TCS uses TCP requests. Never an IP change since you cranked it up? This seems unlikely as some content providers juggle the "primary" IP as a load balancing technique. (TCS dns accepts the first IP and pitches the rest) Are you saying your router doesn't pass TCP, or that you are using your router as a DNS? (Easy to hack many routers)

This is useful to know, but somewhat irrelevant, because "no nameservers are responding" evidently doesn't mean that they don't respond, but that www.zirakzigil.net can't be resolved.

At the time of coding, it seemed to me that the inability to resolve zirakzigil was a reasonable proxy for the network being down. This is true probably 99.9 % of the time, and proved to be much less than that over the past 2 weeks. Hurricanes and hackers suck.

nod, the "fix" only means that zirakzigil and google can't be resolved. One would think google would be cached. This isn't the perfect solution, but it cover all cases excepting the case where there is a hurricane in florida and google has disappeared from the internet radar.

If I can reproduce the problem you speciified I will fix it.

[dgi]

Originally Posted by Zirak

I can understand why that may happen, but not why it would persist. How long did you wait before pulling the plug? Startup is a busy time for the tivo, even more so if you run "heavy" startup hacks including tcs and tivoweb. How long did you wait? Can you reproduce the issue now that the website is back up?

It didn't matter whether the TiVo was restarted or unplugged for 5-10 minutes. Same result: no response to remote even after 5-10 minutes of uptime. Have not tried it since the website went back up, nor do I intend to for quite some time, but I don't expect different results.

Originally Posted by Zirak

I'm not sure what this means, since TCS uses TCP requests. Never an IP change since you cranked it up? This seems unlikely as some content providers juggle the "primary" IP as a load balancing technique. (TCS dns accepts the first IP and pitches the rest) Are you saying your router doesn't pass TCP, or that you are using your router as a DNS? (Easy to hack many routers)

Evidently, it just skips the router and goes straight to the ISP's DNS. I have NS1IP as the router and NS2IP and NS3IP as the ISP's DNS.

Originally Posted by Zirak

At the time of coding, it seemed to me that the inability to resolve zirakzigil was a reasonable proxy for the network being down. This is true probably 99.9 % of the time, and proved to be much less than that over the past 2 weeks. Hurricanes and hackers suck.

nod, the "fix" only means that zirakzigil and google can't be resolved. One would think google would be cached. This isn't the perfect solution, but it cover all cases excepting the case where there is a hurricane in florida and google has disappeared from the internet radar.

If I can reproduce the problem you speciified I will fix it.

Just to be paranoid, you can check if zirakzigil and google and yahoo can't be resolved...

[rung]

I seem to remember when I installed the original TCS, there were symbolic links between the module files in tcs/modules and tcs/modules/modules. No matter how I unpack this distribution (with tar or cpio), I don't get those links - I get two (or three) copies of the same modules in the various directories. Am I doing something wrong?

Thanks.

[dgi]

They're supposed to be hard links...

[Zirak]

It really doesn't matter if they are hard or soft links, I opted for hard. You can check to see if they are indeed hard links by checking that the inodes are the same for the two files. Alternatively you could edit one with a cosmetic change and then diff the 3 files. If there are no differences, they are hard links.

[Zirak]

Originally Posted by dgi

It didn't matter whether the TiVo was restarted or unplugged for 5-10 minutes. Same result: no response to remote even after 5-10 minutes of uptime. Have not tried it since the website went back up, nor do I intend to for quite some time, but I don't expect different results.

I can not reproduce this, albeit with zirakzigil up.

Evidently, it just skips the router and goes straight to the ISP's DNS. I have NS1IP as the router and NS2IP and NS3IP as the ISP's DNS.

This makes sense, as the router doesn't support tcp, only udp. TCS tries it, but treats it like a "down" DNS since it doesn't get a reply.

Just to be paranoid, you can check if zirakzigil and google and yahoo can't be resolved...

That would qualify as pretty paranoid. I'm considering rewriting that code a bit as it currently is a bit unwieldy. I'll consider that and other options at that time. It may be possible to tweak the DNS code so it can tell the difference between unresolvable and unreachable. Its been way too long since I looked at that code to know.

[rung]

Originally Posted by Zirak

It really doesn't matter if they are hard or soft links, I opted for hard. You can check to see if they are indeed hard links by checking that the inodes are the same for the two files. Alternatively you could edit one with a cosmetic change and then diff the 3 files. If there are no differences, they are hard links.

That's a pain. With symbolic links, you can tell with a simple ls -l. I didn't realize that hard links were so hidden (linux newbie alert). Just wondering - what's the advantage?


edit - does cygwin support hard links? I just did this

ln appsrunning.sh test
notedpad test (made a change)
cat test
cat appsrunning.sh

They were different. The I nodes were different too. ln = cp in cygwin?

[Zirak]

Originally Posted by rung

That's a pain. With symbolic links, you can tell with a simple ls -l. I didn't realize that hard links were so hidden (linux newbie alert). Just wondering - what's the advantage?

Hard links came first, they are just another entry in the directory for the same file. When you remove a file, the space isn't deallocated unless its the last directory entry for the file. Accessing a hard link is exactly the same as accessing the original file entry.

A symbolic link stores the actual path in the directory. There are 2 problems with symbolic links, first, the file could be deleted and leave the symbolic link orphaned, and second the system has to look up the name in the directory twice, first for the file you reference, and then for the file that the link references. Its less efficient. Symbolic links were created because it is impossible to hard link across file systems as they don't have the same directory.

Note that windows and Mac OS has the same problem as symbolic links with their shortcuts and aliases.

edit - does cygwin support hard links? I just did this

ln appsrunning.sh test
notedpad test (made a change)
cat test
cat appsrunning.sh

They were different. The I nodes were different too. ln = cp in cygwin?

Sounds whacked to me. I can't look at it as I'm currently trying to recover the disk that has cygwin on it.

[lenroc]

Originally Posted by rung

ln = cp in cygwin?

Sometimes.

It's apparently a filesystem limitation... FAT doesn't support hard links, and the Cygwin developers knew that many people running Cygwin would have FAT drives. So they made "ln" fall back to "cp" on drives that don't support hard links.

NTFS does support hard links, though, apparently:

Lenroc@blackdragon /cygdrive/c $ date > base

Lenroc@blackdragon /cygdrive/c $ ln base target

Lenroc@blackdragon /cygdrive/c $ date >> target

Lenroc@blackdragon /cygdrive/c $ cat target
Tue Sep  7 12:54:24 USMST 2004
Tue Sep  7 12:54:32 USMST 2004

Lenroc@blackdragon /cygdrive/c $ cat base
Tue Sep  7 12:54:24 USMST 2004

Lenroc@blackdragon /cygdrive/c $ cd /cygdrive/d

Lenroc@blackdragon /cygdrive/d $ date > base

Lenroc@blackdragon /cygdrive/d $ ln base target

Lenroc@blackdragon /cygdrive/d $ date >> target

Lenroc@blackdragon /cygdrive/d $ cat base
Tue Sep  7 12:55:44 USMST 2004
Tue Sep  7 12:55:58 USMST 2004

Lenroc@blackdragon /cygdrive/d $ cat target
Tue Sep  7 12:55:44 USMST 2004
Tue Sep  7 12:55:58 USMST 2004

("/cygdrive/c" is FAT32, "/cygdrive/d" is NTFS)

[rung]

Originally Posted by lenroc

NTFS does support hard links, though, apparently:

Thanks for the valuable information! I moved my cygwin installation to a ntfs partition and all the links were installed correcly. Permissions were a blast from the past (haven't seen those in a while), but a umask 0 and a chmod -R +w tcs got me up and running.

TCS is now downloading and installing all the modules from zirakzigil.net Very cool.

[rung]

I just updated XP to SP2. If you want to use the new XP firewall you will have to manually add the following programs to the exception list: portmap, rpc.nfsd, rpc.mountd and tclsh8.3. Once that is done, TCS works perfectly again.

[rung]

Originally Posted by Zirak

I'm not sure what this means, since TCS uses TCP requests. Never an IP change since you cranked it up? This seems unlikely as some content providers juggle the "primary" IP as a load balancing technique. (TCS dns accepts the first IP and pitches the rest) Are you saying your router doesn't pass TCP, or that you are using your router as a DNS? (Easy to hack many routers)

TCS DNS lookups haven't ever worked for me either. I finally had a chance to packet sniff it. It just looks like the TCP SYN packets to the DNS are never acknowledged. The IP is correct and the port is 53. The UDP DNS lookup immediately after the TCS attempt (which is done by my firewall logger) works fine. I am using a standard Linksys cable-modem router. Is there a setting I need to change?

Thanks.

[Zirak]

No, this probably means that your DNS doesn't support TCP requests. Although most seem to support both TCP and UDP, some don't support TCP requests. You can verify that this is the issue using DIG (A windows version is available, google for it.)

Alternatively, you could google for a "public" DNS server, and test for TCP support with DIG.

[dgi]

Originally Posted by Zirak

Alternatively, you could google for a "public" DNS server, and test for TCP support with DIG.

http://www.opennic.unrated.net/public_servers.html