Help daily update now failed

[stevehaley]

My tivo has been working perfectly for years but now the daily update is failing both over the net and over the phone.
The test call will work over the phone but not network
The tivo has a turbonet card installed and everything appears to working ok in that I have ftp, http & telnet connectivity and I can ping to the outside world

I have tried all the suggestions eg backgrounding the hacks, resetting the NIC but to no avail

tclient shows the following when trying over the net
04/19:12:08:43: /tvbin/TClient: Executing HTTP command: /tvbin/http_post /var/log/svclog http://204.176.49.3:80/tivo-service/mlog.cgi OFF OFF ON
04/19:12:08:43: /tvbin/TClient: about to do HServer Call
04/19:12:08:43: /tvbin/TClient: Executing HTTP command: /tvbin/tclient_post 204.176.49.3:80 /var/tmp/HServer.send /var/tmp/HServer.recv 300 ON
04/19:12:13:44: /tvbin/TClient: http POST command failed: timeout waiting to read
04/19:12:13:44: /tvbin/TClient: doHttpCall returned: 0
04/19:12:13:44: /tvbin/TClient: Connect/POST has failed, we've warned the user, set status to Failed
04/19:12:13:44: /tvbin/TClient: failed connect - aborting

over the phone it makes the test call fine but failed on an update - was just hanging here
04/19:05:16:53: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.31:8080/dynamic/PC/W2/PC-W2-p13988-v1008.slice.bnd -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:17:00: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.32:8080/dynamic/PC/DB/PC-DBS-p13988-v1082.slice.bnd -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:17:15: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.31:8080/dynamic/PG/00/PG-0001172-p13988.slice.bnd -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:36:59: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.31:8080/dynamic/PG/W2/PG-W2Ant-p13988-t2.slice.bnd -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:38:15: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.33:8080/content/13988-1-1/Showcase/bsky50/SC-bsky50-d2-e13996-r13984-v363.slice.gz -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:38:18: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.33:8080/content/13988-1-1/Showcase/bsky55/SC-bsky55-d2-e13996-r13984-v361.slice.gz -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:38:19: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.33:8080/content/13988-1-1/Showcase/bsky59/SC-bsky59-d2-e13996-r13984-v362.slice.gz -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:38:23: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.33:8080/content/13988-1-1/Showcase/bsky62/SC-bsky62-d2-e13996-r13984-v361.slice.gz -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:38:27: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.33:8080/content/13988-1-1/Showcase/chfour56/SC-chfour56-d2-e13996-r13984-v367.slice.gz -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:38:33: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.33:8080/content/13988-1-1/Showcase/chfour57/SC-chfour57-d2-e13996-r13984-v367.slice.gz -D /var/packages -T 0230000601F1216 -C 1208582050 -d
04/19:05:38:36: /tvbin/TClient: Executing HTTP GET: /tvbin/http_get -U http://204.176.49.33:8080/content/13988-1-1/Showcase/chfour66/SC-chfour66-d2-e13996-r13984-v367.slice.gz -D /var/packages -T 0230000601F1216 -C 1208582050 -d
then the box hung

You are dealing with a complete tivo/unix novice so please make it simple:)

thanks in advance
stephen

[stevehaley]

Tried the phone line again and this time it worked but cant get the net updates working
Any help much appreciated

[Pete77]

Do you have an & sign at the end of each line in your rc.sysinit.author or rc.sysinit.author.edit file (the Startup Editor file if you have that module installed in Tivoweb) If not this might be causing your issues by not all processes being properly backgrounded.

Rerunning Guided Setup to another program source platform and then back to your current platform (rebooting after each Guided Setup run is complete with a soft reboot and a hard power off reboot) may also help fix the daily call problem via network.

[stevehaley]

Do you have an & sign at the end of each line in your rc.sysinit.author or rc.sysinit.author.edit file (the Startup Editor file if you have that module installed in Tivoweb) If not this might be causing your issues by not all processes being properly backgrounded.

Rerunning Guided Setup to another program source platform and then back to your current platform (rebooting after each Guided Setup run is complete with a soft reboot and a hard power off reboot) may also help fix the daily call problem via network.

Dont have a rc.sysinit.author or rc.sysinit.author.edit - this is a very old install and was done per instructions way back then. - all my stuff appears to be in rc.sysinit

this is the relevant bit I think

echo "rc.sysinit is complete"
source /etc/rc.d/rc.net
/bin/bash </dev/ttyS3 >& /dev/ttyS3 &
/sbin/tnlited 23 /bin/bash -login &
/sbin/tivoftpd &
/var/hack/tivoweb-tcl/tivoweb &
/var/hack/bin/cron &

[Pete77]

echo "rc.sysinit is complete"
source /etc/rc.d/rc.net
/bin/bash </dev/ttyS3 >& /dev/ttyS3 &
/sbin/tnlited 23 /bin/bash -login &
/sbin/tivoftpd &
/var/hack/tivoweb-tcl/tivoweb &
/var/hack/bin/cron &

rc. sysinit is fine. Just more likely to trash your machine if you make a mistake editing it.

I see you already have the & sign at the end of each line so that can't be the issue. Perhaps try the re-run Guided Setup approach. Or it could be the transparent proxy problem. Who is your ISP? Not someone like Tiscali, TalkTalk or Virgin ADSL is it?

[stevehaley]

Dont know if this helps but when making the test call it executes the 1st http_post fine
/tvbin/http_post /var/log/svclog http://204.176.49.3:80/tivo-service/mlog.cgi OFF OFF ON

but the second
/tvbin/tclient_post 204.176.49.3:80 /var/tmp/HServer.send /var/tmp/HServer.recv 300 ON

appears to time out if I execute at the bash prompt I get

Sun Apr 20 12:04:12 2008: /tvbin/tclient_post invoked
connecting to 204.176.49.3:80
read 1484 bytes from file
writing 1484 bytes to socket
socket 5 ready for writing
wrote 1484 bytes to socket
EOF read from file
select-ing for header
timeout waiting to read
and the hserver.recv file is empty

[stevehaley]

My ISP is BE I had some major network issues with them over the time this failed but dont think they have put in a transparent proxy - not sure how you can tell
Just wondering if any of the checks they had me do on the modem have snafued any of this but fairly sure I put everything back the way it was
MTU is fine because I can ping the ip used in the http get with a 1500 packet size

PING 204.176.49.3 (204.176.49.3): 1500 data bytes
1508 bytes from 204.176.49.3: icmp_seq=0 ttl=240 time=194.620 ms
...............

--- 204.176.49.3 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 193.687/194.167/195.255 ms

[stevehaley]

according to http://www.lagado.com/tools/cache-test I dont have a trasparent cache

[Pete77]

My ISP is BE I had some major network issues with them over the time this failed but dont think they have put in a transparent proxy - not sure how you can tell
Just wondering if any of the checks they had me do on the modem have snafued any of this but fairly sure I put everything back the way it was
MTU is fine because I can ping the ip used in the http get with a 1500 packet size

My mother has Be Unlimited, which I do the maintenance etc on when I visit.

The firmware http interface on the Thomson router (Be Box) they supply is horribly badly designed and hard to use compared to say a Netgear and its very easy to change settings to something that blocks certain kinds of internet access without you realising you have done it.

Perhaps invoking the factory reset button on the router might well resolve your issues.

[stevehaley]

Factory reset it and restored old config with no joy
Then spent an hour redoing it from factory config which has worked
Heaven knows why as the config was from before the problems
The BE box is actually extreemly flexible just need to use telnet to configure it - web interface is poor though

Many thanks for your help

[Pete77]

Factory reset it and restored old config with no joy
Then spent an hour redoing it from factory config which has worked
Heaven knows why as the config was from before the problems
The BE box is actually extreemly flexible just need to use telnet to configure it - web interface is poor though

Many thanks for your help

I'm glad you got it sorted even if it was long winded. It seemed as though it had to be the router setting with most of the other possible likely causes ruled out.

One thing I have found with the web interface is that some router settings such as port forwarding do not survive a power cycle.:eek:

[stevehaley]

I'm glad you got it sorted even if it was long winded. It seemed as though it had to be the router setting with most of the other possible likely causes ruled out.

One thing I have found with the web interface is that some router settings such as port forwarding do not survive a power cycle.:eek:

Ok now tracked the cause to a change in the way the speedtouch SW now works so you were right.

They have changed the way an internal transparent proxy on the router behaves. You can confirm if it is active if you type an illegal url into a browser and it comes back with a speedtouch window error message.

The easiest way to change it is to backup up the config then look for the following

[ dnss.ini ]
config domain=config timeout=15 suppress=0 state=enabled trace=disabled syslog=disabled WANDownSpoofing=enabled WDSpoofedIP=198.18.1.0

Change WANDownSpoofing=enabled to WANDownSpoofing=disabled

[ dsd.ini ]
intercept config WDSpoofedIP=198.18.1.1 servertimeout=10 connecterrorurl=/cgi/b/ic/connect/ categoryerrorurl=/cgi/b/ic/connect/ monitorintercepturl=/cgi/b/ic/connect/ unauthorizedrequrl=/cgi/b/ic/blocked/ imageredirect=enabled imageredirecturl=/images/spacer.gif alwaysuseip=disabled
urlfilter config state=enabled blockproxy=disabled blockipaddress=disabled blockobscuredip=disabled defaultaction=accept
syslog config syslog=unauthorized
debug config turbomode=disabled
debug proxy state=disabled dest=0.0.0.0 port=0
debug recycling state=enabled interval=5 httpidle=1 otheridle=12
config state=automatic

Change config state=automatic to config state=disabled

SAve the file under a new name then upload back to the speedtouch

ALternatively use CLI to make changes

Hope this saves someone from tearing their hair out in future

[Mark Ward]

Ok now tracked the cause to a change in the way the speedtouch SW now works so you were right.

They have changed the way an internal transparent proxy on the router behaves. You can confirm if it is active if you type an illegal url into a browser and it comes back with a speedtouch window error message.

The easiest way to change it is to backup up the config then look for the following

[ dnss.ini ]
config domain=config timeout=15 suppress=0 state=enabled trace=disabled syslog=disabled WANDownSpoofing=enabled WDSpoofedIP=198.18.1.0

Change WANDownSpoofing=enabled to WANDownSpoofing=disabled

[ dsd.ini ]
intercept config WDSpoofedIP=198.18.1.1 servertimeout=10 connecterrorurl=/cgi/b/ic/connect/ categoryerrorurl=/cgi/b/ic/connect/ monitorintercepturl=/cgi/b/ic/connect/ unauthorizedrequrl=/cgi/b/ic/blocked/ imageredirect=enabled imageredirecturl=/images/spacer.gif alwaysuseip=disabled
urlfilter config state=enabled blockproxy=disabled blockipaddress=disabled blockobscuredip=disabled defaultaction=accept
syslog config syslog=unauthorized
debug config turbomode=disabled
debug proxy state=disabled dest=0.0.0.0 port=0
debug recycling state=enabled interval=5 httpidle=1 otheridle=12
config state=automatic

Change config state=automatic to config state=disabled

SAve the file under a new name then upload back to the speedtouch

ALternatively use CLI to make changes

Hope this saves someone from tearing their hair out in future

Steve, the BIGGEST of BIG THANKS to YOU!

I've done a 4000mile round trip to sort out my Dad's tivo and I've tried every trick in the book. I was sure his modem was the problem and I found this thread this evening. I go home tomorrow morning and I thought I was going home defeated. All data is currently downloading. Fantastic!

Thanks, Mark.

Off Topic PS. Now I can spend my last evening working out how to get the damned router to see the Linksys Voip box, it worked for a while but assigned it an IP address in the wrong range, I deleted, gave the Linksys a fixed IP and it hasn't been seen since:eek: