Losing network connectivity on hacked Directivo

[michaeljc70]

I applied all the hacks to my Directivo to enable the networking, hooked up my USB network adapter and was able to FTP or telnet in no problem. However, I seem to be losing access to the Tivo a lot. I even rebooted the Tivo and reset my router and it didn't seem to come back. I unplugged the USB adapter and then it seemed to come back.

I think it could be related to the nighttime reboot I think one of the hacks does. I would imgaine that my router may need reseting after the reboot? If that is the case, that is a hassle. Any other ideas on what it could be?

I just expercienced it today. I was at work and using TivoWebPlus and some channels weren't showing properly so I chose reboot. I waited (it was hours ago) and I still can't connect. When I get home I will probably have to reset the router and maybe try unplugging the adapter.

[marlboroman]

Michael,

Which directivo is this and what version? The HR10-250 with 6.3a likes to call /sbin/dhclient so it's a good idea to rename this file. You configured your network using netconfig.tcl correct instead of through rc.sysinit.author? Also, are you sure the network is dying completely or the ipchains firewall keeps coming back up? I moved my /sbin/ipchains file and created a new one that does exit 0 when /etc/netfilter-enable calls for it.

[michaeljc70]

This is a Samsung 4080, version 6.3.

How can I tell if the ipchains firewall keeps coming back up? When it happens, I can't telnet, ftp, TivoWebPlus into it and it doesn't show in my routers table of clients.

[marlboroman]

Get the serial cable out and see what is happening. See if eth0 interface is still up and reporting the correct IP. If it is, then it sounds like an ipchains issue. You should follow the procedure outlined earlier to disable the firewall or you can add a command inside rc.sysinit.author to call /etc/netfilter-disable.

[michaeljc70]

I don't have a serial cable, but when I got home, I unplugged the USB network adapter from the Tivo and plugged it back in. I was able to connect no problem. Could it be my USB adapter (it is old and have had it laying around for yrs). Is it possible it has some kind of sleep mode?

[marlboroman]

The adapter itself shouldn't have a sleep mode. The only other thing I can think of without looking at the console would be to investigate some of the logs in /var/log. It could be that the network is timing out and your require a keepalive command. Maybe schedule a cron job to run every so often to send periodic pings. The console connection would help immensely in troubleshooting. Can make one for a few dollars from radio shack parts or can be lazy and buy one from 9thtee.com or weaknees.com for a few dollars more.

[cheer]

This is almost certainly a DHCP-related problem. Are you using DHCP to assign an IP, or did you assign a static IP? If you assigned a static IP, you must rename dhclient or this problem will continue.

[michaeljc70]

This is almost certainly a DHCP-related problem. Are you using DHCP to assign an IP, or did you assign a static IP? If you assigned a static IP, you must rename dhclient or this problem will continue.

I renamed the dhclient.lease and it is still having the problem. There is another file with a bunch of letters and numbers with extension .lease. Do I need to get rid of that too?


I have verified over and over that merely unplugging the usb adapter and replugging it in restores connectivity. I don't have to reboot or anything. Obviously, doing this a few times a week isn't going to work. The whole purpose was being able to access these files remotely.

[michaeljc70]

I made it through the weekend without losing connectivity. This morning, I noticed it was out again. I remember when I applied the hacks, I beleive one causes a reboot on Sunday and Wed. I lost connectivity Thur and Mon morning.

I will look for that file, but I don't think I have that (it was setup initially to have a static IP).

[cheer]

You have to rename /sbin/dhclient, not dhclient.lease.

[michaeljc70]

That directory doesn't exist.

[drez]

That's not a directory. In linux, executables do not need a file extension.

[michaeljc70]

That's not a directory. In linux, executables do not need a file extension.

I don't have a file or directory with that name.

Since unplugging the usb adapter and plugging it back in fixes the problem, I am suspicious of the adapter. I don't have another one, but might try picking one up or borrowing one. The one I have was one the compatibilty list I saw for the hack.

The other thing is since it seems to happen after a reboot, I can cancel the auto reboots. I think I have it set to reboot 2x a week. Is that really necessary to keep the hacked unit operating smoothly?

[rbautch]

I don't have a file or directory with that name.

Since unplugging the usb adapter and plugging it back in fixes the problem, I am suspicious of the adapter. I don't have another one, but might try picking one up or borrowing one. The one I have was one the compatibilty list I saw for the hack.

The other thing is since it seems to happen after a reboot, I can cancel the auto reboots. I think I have it set to reboot 2x a week. Is that really necessary to keep the hacked unit operating smoothly?

I have found that if unplugging/replugging the adapter makes it work, it's often a symptom of setting network parameters in more than one place, like if you have ifconfig statements in your author file and also have network params set in MFS. Now that most of the instability of TWP has been removed, the only reason to purposely reboot is for fakecall to take effect.

[michaeljc70]

I have found that if unplugging/replugging the adapter makes it work, it's often a symptom of setting network parameters in more than one place, like if you have ifconfig statements in your author file and also have network params set in MFS. Now that most of the instability of TWP has been removed, the only reason to purposely reboot is for fakecall to take effect.

Here is what I have. The route I am not sure what that does or if it is needed as the ips don't look familar to me (my tivo is 192.168.1.111).

In my author file (rc.sysinit.author - network related only):
route add -host 204.176.49.2 gw 127.0.0.1
route add -net 204.176.49.0 gw 127.0.0.1 netmask 255.255.2

if rm -rf /firstboot_flag; then
tivosh /hacks/network.tcl 192.168.1.111 192.168.1.1

In my mfs file (mfs_network):
IP Address = 192.168.1.111
DNS = 4.2.2.2
Default Gateway = 192.168.1.1
Subnet Mask = 255.255.255.0
DHCP is off


I used a script to do the auto-reboot and am not that familiar with it. I assume it is a cron job. How can I disable that?