TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Main TiVo Forums > TiVo Help Center
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 02-12-2009, 11:24 AM   #421
bm5
Registered User
 
Join Date: Dec 2008
Posts: 3
Quote:
Originally Posted by cgf View Post
This seems to do the trick:

rm /var/log/svclog.upload
mkdir /var/log/svclog.upload

Making svclog.upload a directory seems to confuse things enough to cause the tivo to avoid uploading a file which times out and stops the phonehome process from working.
guys just bringing this up again. I followed cgf's method way back in early January and it is still working. I am able to get successful calls over turbonet daily.

by the way, I came here to look up something else but was surprised to find this problem is still happening. VERY disappointing response from Tivo
bm5 is offline   Reply With Quote
Old 02-12-2009, 12:19 PM   #422
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Makes sense to me.

Although I do wonder what any potential downsides might be (both to us AND to TiVo).
bittmann is offline   Reply With Quote
Old 02-12-2009, 12:28 PM   #423
nmiller855
Registered User
 
Join Date: Sep 2000
Location: East of Houston, Texas, USA
Posts: 5,304
I haven't made any modifications to my series 1 TiVo since any of this started & it is working fine now. Every once in a while a call fails & I just restart the call & it goes through quickly.
nmiller855 is offline   Reply With Quote
Old 02-12-2009, 06:37 PM   #424
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
Quote:
Originally Posted by bittmann View Post
Something I wonder...could anyone with a later version TiVo check their logs and see if that particular CGI is still part of the nightly call, and if so, is it an HTTP1.1 or 1.0 "claimed" connection in the logs. Erm...Has that already been reported here and I just missed it?

BittMann
i saw a trace of a newer TIVO elsewhere showing http 1.1 to that cgi.
joeysmith is offline   Reply With Quote
Old 02-14-2009, 11:35 AM   #425
vjquan
Registered User
 
Join Date: Feb 2009
Posts: 16
I joined this forum for the sole purpose of sending TivoJerry my TSN. I too experience the same problems most are having - call failed, call interrupted, etc. While the recent discussions have been about clearing logs, I only have the dial-up option and do not have access to the file system. This is frustrating to say the least as I constantly, on a daily basis, babysit to see what it did. Does anyone know if this affects series 2 boxes? If not, what's the difference? I would like to upgrade to HD, but their boxes only support cable while I'm on DirecTV. I would hate to waste my lifetime subscription transfer on a non-HD machine, but am tempted to do so. This has been going on too long! I am hopeful that a resolution is in the works, but I don't see any indication of that happening. Is this going to be one of those problems where it just gets brushed off? There's got to be many more out there that just aren't posting.
vjquan is offline   Reply With Quote
Old 02-14-2009, 11:58 AM   #426
dbranco
Registered User
 
dbranco's Avatar
 
Join Date: Nov 2003
Posts: 629
Quote:
Originally Posted by vjquan View Post
Does anyone know if this affects series 2 boxes? If not, what's the difference?
I have a Series 2 box connected to the same phone line as my (often-failing) Series 1. It has never experienced any "Service Unavailable" or bogus "Call Interrupted" errors.

I sent TiVoJerry my S1 TSN, and at his request, later sent him the S2 TSN. I suspect he is looking at at the logs for each box, trying to determine what the difference is.
dbranco is offline   Reply With Quote
Old 02-14-2009, 12:16 PM   #427
tzone
Registered User
 
Join Date: Feb 2002
Posts: 16
I've also been having problems on a recently repurposed Series 1 unit with Lifetime service and turbonet. I initially thought that my old turbonet card (ISA riser with Kingston NIC) was going bad so I opened another Series 1 of mine that is retired and took out the newer (much smaller) NIC and put that in the unit. It made no difference. I even went so far as to reimage the drive in the unit and repeat guided setup but that seemed to take on the order of 15-20 tries for it to complete (but it eventually did amongst a bunch of service unavailable and call interrupted messages).

My question for TiVoJerry is: Do you still need captures of the failed events? If so I can get out my old 10baseT hub and use wireshark to capture a failed call if you would like. I see that several others have already provided you with TCP captures so I just want to see if you would like to have more data or not before I go to all the work to set this up.

/troy
tzone is offline   Reply With Quote
Old 02-14-2009, 01:47 PM   #428
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Quote:
Originally Posted by dlee0708 View Post
I finally got with my mom and had her hook up my ethernet hub and got a trace of Service Unavailable failure. I have PM TivoJerry about it.

It sends a POST of the log file and fails to get the 2nd packet to the Tivo Server.

1. The first packet has the content-length field with the first packet being 63 bytes (the not sending the content-length field problem of several years ago must have been fixed).

2. Then the Tivo sends the next 1460 bytes

3. A response from the server is received for the first 63 bytes (ack 64)

4. The Tivo doesn't see the ack for the next 1460 bytes, so it resends the 1460 bytes again

5. Still no response and this happens for about 5 minutes (resends it 10 times with no response from the Server).

6. The Server sends a Internel Server Error back to the Tivo and the Ack it sends with it indicates it never has received any bytes after byte 63 (Ack 64).

I am positive everyone is going to jump on its a Tivo Server problem because it says a Server Internel Error, but the fact that the HTTP error coming back from the server has an Ack of 64 indicates the TCP/IP stack on the operating system did not receive the 2nd packet (the 1460 bytes). If its a problem at the Server, its not an application/process that TivoInc has that is the problem, but a problem in the Operating System Tcp/ip stack on the Tivo Server (which I assume is Linux). I find this highly unlikely. One thing I do notice is that the HTTP POST sent to the Tivo Server is HTTP/1.0. All the browsers now use HTTP/1.1. I don't know enough about the protocol differences to know what all the differences are, but I would think that would be something to look at and I would bet if the Tivo would start using HTTP/1.1 the problem would go away.

Here is the dump:

.
.
.
(data in Original Post on 02/07/2009)
Well, I think my mother has pretty much had it with this situation. She has not had a successful connection since Dec 3, no program guide data since Dec 17.

I took the data from my Tcp capture and wrote a simple little test program to send the same connetion to Tivo and it works fine (acks the 2nd packet). The difference is the 2nd packet sent by my test program is 536 bytes instead of 1460 like the Tivo is sending. For some stinking reason Vista is setting the MTU down to 576 when I run my program and just sending 536 bytes at a time. But if I run Outlook Express and send a large file it sends much larger packets (still not 1460, but at least larger than 536). I don't know where this problem is, but I am giving up on this. I wish Tivo would at least tell us what is going on. Just even knowing if the packets are getting to TivoInc would be something. But as far as telling us what they have determined what is wrong, nothing has come back.
dlee0708 is offline   Reply With Quote
Old 02-14-2009, 01:54 PM   #429
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Quote:
Originally Posted by tzone View Post
I've also been having problems on a recently repurposed Series 1 unit with Lifetime service and turbonet. I initially thought that my old turbonet card (ISA riser with Kingston NIC) was going bad so I opened another Series 1 of mine that is retired and took out the newer (much smaller) NIC and put that in the unit. It made no difference. I even went so far as to reimage the drive in the unit and repeat guided setup but that seemed to take on the order of 15-20 tries for it to complete (but it eventually did amongst a bunch of service unavailable and call interrupted messages).

My question for TiVoJerry is: Do you still need captures of the failed events? If so I can get out my old 10baseT hub and use wireshark to capture a failed call if you would like. I see that several others have already provided you with TCP captures so I just want to see if you would like to have more data or not before I go to all the work to set this up.

/troy

Troy,

If you ever connect up the Hub, I am curious does yours fail the same way my mothers does (see post on 02/07/2009 for full data if you want to see it). My mothers makes a connection, sends a Http POST packet of 63 bytes, then sends 1460 bytes, gets the ack from TivoInc of the first 63 bytes (ack 64) but never gets an ack from TivoInc for the 2nd 1460 byte packet. Then all you see is the Tivo resend the 2nd packet about 10 times and then a Server error from TivoInc (still just acking the first 63 bytes) and the connection ends.
dlee0708 is offline   Reply With Quote
Old 02-14-2009, 03:40 PM   #430
mec1991
Cranky old coot
 
mec1991's Avatar
 
Join Date: Nov 2004
Location: Back home where I belong
Posts: 659
Haven't posted for awhile, but the past few days I have been getting about 30% failures, either service unavailable during connecting or call interrupted during downloading. Much better than in Dec and Jan but obviously still not fixed as I had earlier thought. Oh well, at least I have up to date guide data with a little babysitting.

One thing, though, I have really learned to appreciate the UI of the S1; it is blazing fast and I am not blindsided by ads like I am on my S2

I'd really like to keep the old Sony purring along as long as possible. I plan on getting a HD model if they ever support clear QAM with guide data. I personally have no use for a STB with 900 channels and really only want my locals in HD. The SciFi channel crap is still going to be crap regardless of whether it is in HD or not.

OTA is a non starter for me as I cannot use an outdoor antenna and the two indoor ones I tried worked as well as hooking up a banana instead.
mec1991 is offline   Reply With Quote
Old 02-14-2009, 05:47 PM   #431
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Quote:
Originally Posted by vjquan View Post
I joined this forum for the sole purpose of sending TivoJerry my TSN. I too experience the same problems most are having - call failed, call interrupted, etc. While the recent discussions have been about clearing logs, I only have the dial-up option and do not have access to the file system. This is frustrating to say the least as I constantly, on a daily basis, babysit to see what it did. Does anyone know if this affects series 2 boxes? If not, what's the difference? I would like to upgrade to HD, but their boxes only support cable while I'm on DirecTV. I would hate to waste my lifetime subscription transfer on a non-HD machine, but am tempted to do so. This has been going on too long! I am hopeful that a resolution is in the works, but I don't see any indication of that happening. Is this going to be one of those problems where it just gets brushed off? There's got to be many more out there that just aren't posting.
[offtopic]

With respect to DirecTV and TiVo: Have you seen this?

[/offtopic]
bittmann is offline   Reply With Quote
Old 02-14-2009, 05:57 PM   #432
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Quote:
Originally Posted by dlee0708 View Post
Well, I think my mother has pretty much had it with this situation. She has not had a successful connection since Dec 3, no program guide data since Dec 17.

I took the data from my Tcp capture and wrote a simple little test program to send the same connetion to Tivo and it works fine (acks the 2nd packet). The difference is the 2nd packet sent by my test program is 536 bytes instead of 1460 like the Tivo is sending. For some stinking reason Vista is setting the MTU down to 576 when I run my program and just sending 536 bytes at a time. But if I run Outlook Express and send a large file it sends much larger packets (still not 1460, but at least larger than 536). I don't know where this problem is, but I am giving up on this. I wish Tivo would at least tell us what is going on. Just even knowing if the packets are getting to TivoInc would be something. But as far as telling us what they have determined what is wrong, nothing has come back.
FWIW: I messed around with my TiVo a bit, setting the MTU on the NIC way down. Tried 1460, 1400, 800, and 128 (!!) byte MTUs with the same result -- regardless of MTU, sometimes it'd hang on the POST, sometimes it wouldn't. For what little THAT's worth.

BittMann
bittmann is offline   Reply With Quote
Old 02-14-2009, 07:46 PM   #433
pip55
Registered User
 
Join Date: Dec 2005
Posts: 42
I have a SA series2 that's joining in on the data guide loss. Haven't been able to successfully download & install since December. When I do a search for local numbers they are found and downloaded no problem but if i try any in- state numbers with test phone connection or make daily call, they all fail. Tried 818 450 1705 & 602 605-1880 & other states as well. Burbank and Arizona came the closest to completion but failed on download or install. I was going to try a new image install as well, thinking perhaps an older software version might work but apparently doesn't look well. If an older image doesn't remedy the problem does that point to a integral motherboard situation for the series 1 & 2 that conflicts with new scripts from Tivo Central? I have a hughes sddvr40 that downloads data as always. Not ready to do a Cl&Del yet, although I believe that has been tried already. Can you serial connect to unmodded series2?
pip55 is offline   Reply With Quote
Old 02-14-2009, 08:17 PM   #434
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
You'd be the 1st Series2 that's experiencing this issue, if that's the case.

How confident are you in your phoneline/your modem? (That'd be my first suspicion...It's the least complicated explanation, anyhow)
bittmann is offline   Reply With Quote
Old 02-14-2009, 08:30 PM   #435
vjquan
Registered User
 
Join Date: Feb 2009
Posts: 16
Quote:
Originally Posted by bittmann View Post
[offtopic]

With respect to DirecTV and TiVo: Have you seen this?

[/offtopic]
Thanks, but this is just another DTV receiver where they charge monthly fees. I'm interested in a stand alone Tivo where I can transfer my lifetime service.
vjquan is offline   Reply With Quote
Old 02-14-2009, 08:35 PM   #436
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Arrow

Quote:
Originally Posted by bittmann View Post
FWIW: I messed around with my TiVo a bit, setting the MTU on the NIC way down. Tried 1460, 1400, 800, and 128 (!!) byte MTUs with the same result -- regardless of MTU, sometimes it'd hang on the POST, sometimes it wouldn't. For what little THAT's worth.

BittMann

BittMann,

That is real interesting information. Could you set the MTU down to 576, do a Daily Call and post the the Tcp capture like you did on 02/09, except also post the HTTP POST /tivo-service..., the next packet the Tivo sends (seq 64) and then the next 2 packets received by TivoInc (or the whole thing if you want). I would do this myself, but its my Mom's Tivo that is having the problem and it doesn't have telnet access (still kicking myself for not adding that). I mainly want to see the size of the packets sent to TivoInc and what ack packets coming back from TivoInc telling me what packets it has received.

I just don't understand why my test program running on my mom's computer gets responses from TivoInc, but the Tivo doesn't. I thought it was because of the MTU difference, but your little test shows different and I just want to see what the difference is when you set the MTU down to what her computer has it set at. I can change my program to look like your test and see what happens on my mom's Tivo. Maybe we can figure out what is making it fail, because it appears Tivo isn't making any effort to tell us. This is the first time I haven't defended Tivo, but I have not heard Jack Squat from them, so I have changed my tune.. I'm not expecting a fix from Tivo necessarily, but at least info on what they know. I have spent a ton of time and my mothers time trying to help find the problem instructing my 82 year old mother on how to set up the network and then me getting the trace and sending to it Tivo with all the info and I don't think they have done anything (or if they have done anything they haven't said anything).

The one thing that for sure Tivo should know is whether the packets sent from my mom's Tivo are making it to TivoInc. If they aren't getting there, then I can tell her ISP they need to fix whatever it is that is blocking the packets to TivoInc, but I don't feel I should do that unless I know for sure that TivoInc is not getting the packets.

Last edited by dlee0708 : 02-14-2009 at 08:45 PM.
dlee0708 is offline   Reply With Quote
Old 02-14-2009, 08:39 PM   #437
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
I can give it a shot, but it'll be a bit.

And don't give up on TiVo just yet. If this was "easy", it would've been fixed earlier. And if it wasn't something that they are going to try to fix, TivoJerry wouldn't be involved.

BittMann
bittmann is offline   Reply With Quote
Old 02-14-2009, 09:47 PM   #438
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Quote:
Originally Posted by bittmann View Post
I can give it a shot, but it'll be a bit.

And don't give up on TiVo just yet. If this was "easy", it would've been fixed earlier. And if it wasn't something that they are going to try to fix, TivoJerry wouldn't be involved.

BittMann
I can certainly wait for you to have a chance. Glad you are able to this.

I probably shouldn't have gotten harsh, but it's starting to get frustrating. To be honest, I really don't think my my mothers problem is really a Tivo problem (Tivo DVR or Server at TivoInc), but a network issue that is not handling this old HTTP HTML1.0 format (or something like that), but TivoInc should be able to look at our logs, compare them to what there Ethereal/WireCapture are seeing on their end and tell us where the problem is. It happens on my mothers Tivo 100% of the time. It would be very simple to figure this out, look at my mothers capture, look on their side and see if they are getting the packets. Dang, I tried to keep from going negative, but I did it again. Please Tivo, restore my faith.

Last edited by dlee0708 : 02-14-2009 at 09:56 PM.
dlee0708 is offline   Reply With Quote
Old 02-15-2009, 10:00 AM   #439
tzone
Registered User
 
Join Date: Feb 2002
Posts: 16
Quote:
Originally Posted by dlee0708 View Post
Troy,

If you ever connect up the Hub, I am curious does yours fail the same way my mothers does (see post on 02/07/2009 for full data if you want to see it). My mothers makes a connection, sends a Http POST packet of 63 bytes, then sends 1460 bytes, gets the ack from TivoInc of the first 63 bytes (ack 64) but never gets an ack from TivoInc for the 2nd 1460 byte packet. Then all you see is the Tivo resend the 2nd packet about 10 times and then a Server error from TivoInc (still just acking the first 63 bytes) and the connection ends.
I connected everything up this morning (old Netgear 10baseT hub and Wireshark). My capture does look very similar to yours with several retransmissions on both ends and eventually ends with:

HTTP/1.1 500 Internal Server Error

Note that this is in a house with two TiVoHD units that connect just fine to the tivo service via broadband everyday.

Now to see if I can get a download interrupted capture next.

/troy
tzone is offline   Reply With Quote
Old 02-15-2009, 10:15 AM   #440
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Quote:
Originally Posted by tzone View Post
I connected everything up this morning (old Netgear 10baseT hub and Wireshark). My capture does look very similar to yours with several retransmissions on both ends and eventually ends with:

snip
/troy
Could you post your capture. If you are seeing several retranmissions by the Tivo Server that is different than what my mom is getting. I would be curious to see exactly what you are getting.

Here is what I have:
Code:
No.     Time        Source                Destination           Protocol Info
     25 197.419017  192.168.1.4           204.176.49.2          TCP      1157 > http [SYN] Seq=0 Ack=0 Win=512 Len=0 MSS=1460

Frame 25 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 0, Ack: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
     26 197.502033  204.176.49.2          192.168.1.4           TCP      [TCP ZeroWindow] http > 1157 [SYN, ACK] Seq=0 Ack=1 Win=0 Len=0

Frame 26 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
     27 197.502453  192.168.1.4           204.176.49.2          TCP      1157 > http [ACK] Seq=1 Ack=1 Win=1460 Len=0

Frame 27 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
     28 197.584177  204.176.49.2          192.168.1.4           TCP      [TCP Window Update] http > 1157 [ACK] Seq=1 Ack=1 Win=4236 Len=0

Frame 28 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
     29 197.641810  192.168.1.4           204.176.49.2          HTTP     POST /tivo-service/mlog.cgi HTTP/1.0

Frame 29 (117 bytes on wire, 117 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 1, Ack: 1, Len: 63
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     30 197.698146  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 30 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     31 197.825455  204.176.49.2          192.168.1.4           TCP      http > 1157 [ACK] Seq=1 Ack=64 Win=4299 Len=0

Frame 31 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 1, Ack: 64, Len: 0

No.     Time        Source                Destination           Protocol Info
     32 197.827593  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 32 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 1524, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     33 198.280470  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 33 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     34 199.199982  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 34 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     35 201.040309  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 35 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     36 203.244885  192.168.1.1           192.168.1.4           UDP      Source port: 4457  Destination port: 40116

Frame 36 (174 bytes on wire, 174 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 192.168.1.1 (192.168.1.1), Dst Addr: 192.168.1.4 (192.168.1.4)
User Datagram Protocol, Src Port: 4457 (4457), Dst Port: 40116 (40116)
Data (132 bytes)

0000  54 4d 44 50 01 00 00 11 00 78 00 00 00 02 00 74   TMDP.....x.....t
0010  54 4d 53 53 5f 54 45 53 54 5f 4e 4f 44 45 00 00   TMSS_TEST_NODE..
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  30 30 31 45 32 41 30 38 43 44 39 38 38 38 45 45   001E2A08CD9888EE
0040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0070  ff ff ff ff 00 00 00 00 00 00 00 01 ff ff ff ff   ................
0080  ff ff ff ff                                       ....

No.     Time        Source                Destination           Protocol Info
     37 203.245308  192.168.1.4           192.168.1.1           ICMP     Destination unreachable

Frame 37 (202 bytes on wire, 202 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 192.168.1.1 (192.168.1.1)
Internet Control Message Protocol

No.     Time        Source                Destination           Protocol Info
     38 204.720520  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 38 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     39 212.080887  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 39 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     40 226.802100  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 40 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     41 256.243644  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 41 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     42 315.127624  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 42 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     43 432.895135  192.168.1.4           204.176.49.2          HTTP     Continuation

Frame 43 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     44 497.652716  204.176.49.2          192.168.1.4           HTTP     HTTP/1.1 500 Internal Server Error (text/html)

Frame 44 (767 bytes on wire, 767 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 1, Ack: 64, Len: 713
Hypertext Transfer Protocol
Line-based text data: text/html

No.     Time        Source                Destination           Protocol Info
     45 497.653135  204.176.49.2          192.168.1.4           TCP      http > 1157 [FIN, ACK] Seq=714 Ack=64 Win=4299 Len=0

Frame 45 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 714, Ack: 64, Len: 0

No.     Time        Source                Destination           Protocol Info
     46 497.653565  192.168.1.4           204.176.49.2          TCP      1157 > http [ACK] Seq=2984 Ack=715 Win=4380 Len=0

Frame 46 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 2984, Ack: 715, Len: 0

No.     Time        Source                Destination           Protocol Info
     47 503.004188  204.176.49.2          192.168.1.4           TCP      http > 1157 [RST, ACK] Seq=715 Ack=64 Win=4299 Len=0

Frame 47 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 715, Ack: 64, Len: 0

dlee0708 is offline   Reply With Quote
Old 02-15-2009, 10:43 AM   #441
technomutt
Registered User
 
Join Date: Jun 2004
Posts: 103
my 2 cents

Haven't logged in here in a while, and found this thread. A friend and I have between us 5 Tivos... 3 of which are Series 1 Sony SVR-2000s. Of these, two are lifetimes. Of these, one is on dialup, the other has a turbonet. All have 120GB hard drives or larger.

None of our units has ever gone for more than 48 hours without a successful call, and those few error times occurred over the Christmas holiday. One time I thought the guide data might be corrupted on the turbonet unit, so I did a "Clear Program Data & To Do List" which seemed to clear the problem. But I suspect I could have just waited a day and it would have cleared itself.

Just for fun last evening I re-ran the guided setup on the lifetime Sony with the turbonet card and while it was slow, it completed successfully.

So I guess this is one of those annoying "mine works fine" posts.

However, I have 2 questions:

1. Is the modem in the Series 1 box a V32 (33.6Kbps max) modem, a K56flex or the other non-standard 56Kbps modem (I forget the name), or is it a true V90 standard 56Kbps modem? This is for those who are dropping the connection and have ruled out the quality of the POTS line and have properly filtered their DSL (if applicable) away from the Tivo's phone line. I am reminded of times back in 1999 or so where folks with dialup internet access on their computers couldn't connect or dropped the connection. Their modems would be 56K capable, and they would dial into 56K ready ISP's but the phone line itself could not support those speeds. Those early modems would not downshift properly to 33.6 or slower, so the connection was dropped. The solution was to modify the modem's initialization string for force connections at only V32 or slower.

I also recall once connecting a dialup computer to a verizon FIOS "simulated POTS" line (not VOIP) and it would connect at 33.6 max. I know... "why would anyone do that if you have FIOS". Well, just because I could.

2. For those having issues with turbonet, do you use anything other than a standard residential-grade router and your ISP's DNS servers? No Sonic Walls or other firewall? No proxies or other DNS redirects? No Comsifters or other internet "filters"? The environments where all of my turbonet equipped Tivos have been have standard issue routers... nothing fancy. I've experienced FIOS, DSL and even fixed wireless. Never Comcrap. You can't pay me enough to use Comcrap. I don't care how fast it bursts to, I will never use cable internet. Aside from their weird DNS practices and their tendencies to throttle "heavy" users, I feel their service is way overpriced for it's value.

That's my 2 cents... hopefully there was something useful to someone.
technomutt is offline   Reply With Quote
Old 02-15-2009, 10:53 AM   #442
tzone
Registered User
 
Join Date: Feb 2002
Posts: 16
Quote:
Originally Posted by dlee0708 View Post
Could you post your capture. If you are seeing several retranmissions by the Tivo Server that is different than what my mom is getting. I would be curious to see exactly what you are getting.

Here is the service unavailable pcap that I grabbed this AM.

Code:
No.     Time        Source                Destination           Protocol Info
      1 0.000000    192.168.1.125         204.176.49.2          TCP      ardus-mtrns > http [SYN] Seq=0 Win=512 Len=0 MSS=1460

Frame 1 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
      2 0.013255    204.176.49.2          192.168.1.125         TCP      http > ardus-mtrns [SYN, ACK] Seq=0 Ack=1 Win=0 Len=0

Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
      3 0.013625    192.168.1.125         204.176.49.2          TCP      ardus-mtrns > http [ACK] Seq=1 Ack=1 Win=1460 Len=0

Frame 3 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
      4 0.026489    204.176.49.2          192.168.1.125         TCP      [TCP Window Update] http > ardus-mtrns [ACK] Seq=1 Ack=1 Win=4356 Len=0

Frame 4 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
      5 0.026871    192.168.1.125         204.176.49.2          TCP      [TCP segment of a reassembled PDU]

Frame 5 (116 bytes on wire, 116 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 1, Ack: 1, Len: 62

No.     Time        Source                Destination           Protocol Info
      6 0.031136    192.168.1.125         204.176.49.2          TCP      [TCP segment of a reassembled PDU]

Frame 6 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
      7 0.140865    204.176.49.2          192.168.1.125         TCP      http > ardus-mtrns [ACK] Seq=1 Ack=63 Win=4418 Len=0

Frame 7 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 63, Len: 0

No.     Time        Source                Destination           Protocol Info
      8 0.142636    192.168.1.125         204.176.49.2          TCP      [TCP segment of a reassembled PDU]

Frame 8 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 1523, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
      9 0.143619    192.168.1.125         204.176.49.2          HTTP     POST /tivo-service/mlog.cgi HTTP/1.0 

Frame 9 (1179 bytes on wire, 1179 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 2983, Ack: 1, Len: 1125
[Reassembled TCP Segments (4107 bytes): #5(62), #6(1460), #11(1460), #12(1460), #13(1460), #14(1460), #15(1460), #18(1460), #19(1460), #20(1460), #21(1460), #28(1460), #30(1460), #8(1460), #9(1125)]
Hypertext Transfer Protocol

No.     Time        Source                Destination           Protocol Info
     10 0.205644    204.176.49.2          192.168.1.125         TCP      [TCP Dup ACK 7#1] http > ardus-mtrns [ACK] Seq=1 Ack=63 Win=4418 Len=0

Frame 10 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 63, Len: 0

No.     Time        Source                Destination           Protocol Info
     11 0.342584    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 11 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     12 0.742875    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 12 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     13 1.542766    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 13 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     14 3.142979    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 14 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     15 6.343634    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 15 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     16 10.010958   Buffalo_2e:3c:c0      Pc-Pos_32:02:27       ARP      Who has 192.168.1.125?  Tell 192.168.1.254

Frame 16 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Address Resolution Protocol (request)

No.     Time        Source                Destination           Protocol Info
     17 10.011213   Pc-Pos_32:02:27       Buffalo_2e:3c:c0      ARP      192.168.1.125 is at 00:0b:ad:32:02:27

Frame 17 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Address Resolution Protocol (reply)

No.     Time        Source                Destination           Protocol Info
     18 12.744360   192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 18 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     19 25.546190   192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 19 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     20 51.149872   192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 20 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     21 102.357150  192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 21 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     22 144.361886  Pc-Pos_32:02:27       AbitComp_bb:f7:40     ARP      Who has 192.168.1.200?  Tell 192.168.1.125

Frame 22 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: AbitComp_bb:f7:40 (00:50:8d:bb:f7:40)
Address Resolution Protocol (request)

No.     Time        Source                Destination           Protocol Info
     23 144.361905  AbitComp_bb:f7:40     Pc-Pos_32:02:27       ARP      192.168.1.200 is at 00:50:8d:bb:f7:40

Frame 23 (42 bytes on wire, 42 bytes captured)
Ethernet II, Src: AbitComp_bb:f7:40 (00:50:8d:bb:f7:40), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Address Resolution Protocol (reply)

No.     Time        Source                Destination           Protocol Info
     24 176.868701  192.168.1.125         204.176.49.2          TCP      ardus-mtrns > http [FIN, ACK] Seq=4108 Ack=1 Win=4380 Len=0

Frame 24 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 4108, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
     25 176.882276  204.176.49.2          192.168.1.125         TCP      [TCP Dup ACK 7#2] http > ardus-mtrns [ACK] Seq=1 Ack=63 Win=4418 Len=0

Frame 25 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 63, Len: 0

No.     Time        Source                Destination           Protocol Info
     26 186.882844  Buffalo_2e:3c:c0      Pc-Pos_32:02:27       ARP      Who has 192.168.1.125?  Tell 192.168.1.254

Frame 26 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Address Resolution Protocol (request)

No.     Time        Source                Destination           Protocol Info
     27 186.883222  Pc-Pos_32:02:27       Buffalo_2e:3c:c0      ARP      192.168.1.125 is at 00:0b:ad:32:02:27

Frame 27 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Address Resolution Protocol (reply)

No.     Time        Source                Destination           Protocol Info
     28 279.282428  192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 28 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     29 299.997627  204.176.49.2          192.168.1.125         TCP      [TCP Previous segment lost] http > ardus-mtrns [FIN, ACK] Seq=714 Ack=63 Win=4418 Len=0

Frame 29 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 714, Ack: 63, Len: 0

No.     Time        Source                Destination           Protocol Info
     30 299.999440  192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]

Frame 30 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460

No.     Time        Source                Destination           Protocol Info
     31 299.999455  192.168.1.125         204.176.49.2          TCP      [TCP Dup ACK 30#1] ardus-mtrns > http [ACK] Seq=4109 Ack=1 Win=4380 Len=0

Frame 31 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 4109, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
     32 300.001673  204.176.49.2          192.168.1.125         HTTP     [TCP Retransmission] HTTP/1.1 500 Internal Server Error  (text/html)

Frame 32 (767 bytes on wire, 767 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 63, Len: 713
Hypertext Transfer Protocol
Line-based text data: text/html

No.     Time        Source                Destination           Protocol Info
     33 300.003943  192.168.1.125         204.176.49.2          TCP      ardus-mtrns > http [ACK] Seq=4109 Ack=715 Win=4380 Len=0

Frame 33 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 4109, Ack: 715, Len: 0

No.     Time        Source                Destination           Protocol Info
     34 308.268104  204.176.49.2          192.168.1.125         TCP      http > ardus-mtrns [RST, ACK] Seq=715 Ack=63 Win=4418 Len=0

Frame 34 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 715, Ack: 63, Len: 0

No.     Time        Source                Destination           Protocol Info
     35 309.996818  Buffalo_2e:3c:c0      Pc-Pos_32:02:27       ARP      Who has 192.168.1.125?  Tell 192.168.1.254

Frame 35 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
Address Resolution Protocol (request)

No.     Time        Source                Destination           Protocol Info
     36 309.997054  Pc-Pos_32:02:27       Buffalo_2e:3c:c0      ARP      192.168.1.125 is at 00:0b:ad:32:02:27

Frame 36 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
Address Resolution Protocol (reply)
/troy
tzone is offline   Reply With Quote
Old 02-15-2009, 12:24 PM   #443
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Quote:
Originally Posted by tzone View Post
Here is the service unavailable pcap that I grabbed this AM.

(...Snip)
/troy

That is pretty much the same as my mothers except for 3 things.

1. On yours, the Tivo sends out 4 packets (#5, #6, #8 and #9) before it goes back and starts retransmitting the #6 packet (Seq 63) because it never gets a response from the TivoServer for packet #6.

My mothers only gets out 3 packets before retransmitting the 2nd packet.

2. On yours the first packet is 62 bytes whereas my mothers is 63. I imagine its because your log file is smaller and therefore the content-length field a 4 digit number whereas my mothers is a 5 digit. I would be curious as to what this packet has in the data. Here is my mothers

Code:
0000  00 1e 2a 08 cd 98 00 0b  ad 32 12 1f 08 00 45 00   ..*..... .2....E.
0010  00 67 09 7c 00 00 40 06  b1 b6 c0 a8 01 04 cc b0   .g.|..@. ........
0020  31 02 04 85 00 50 6e 0a  21 55 33 d4 24 ea 50 18   1....Pn. !U3.$.P.
0030  11 1c 57 c5 00 00 50 4f  53 54 20 2f 74 69 76 6f   ..W...PO ST /tivo
0040  2d 73 65 72 76 69 63 65  2f 6d 6c 6f 67 2e 63 67   -service /mlog.cg
0050  69 20 48 54 54 50 2f 31  2e 30 0d 0a 43 6f 6e 74   i HTTP/1 .0..Cont
0060  65 6e 74 2d 4c 65 6e 67  74 68 3a 20 36 34 38 34   ent-Leng th: 6484
0070  31 0d 0a 0d 0a                                     1....
My mothers has Content-Length: 64841, I am guessing yours is probably like Content-Length: 4170 therefore making the packet 1 byte less than my moms. Could you post what is in packet #5.

3. On yours at packet #10 the TivoServer does resend an ack that it sent at #7. On my mom's, the ack is never resent by the server.



But what I would really like to see is what is TivoInc seeing on their end for these Service Unavailable issues, that is what I would just love to know. Man, would that ever be informative.

Last edited by dlee0708 : 02-15-2009 at 12:36 PM.
dlee0708 is offline   Reply With Quote
Old 02-15-2009, 04:39 PM   #444
pianoman
:-|
 
pianoman's Avatar
 
Join Date: Jun 2002
Location: Metairie, LA
Posts: 3,666
Checking back in to the thread because my Series 1 started having failed calls again (Turbonet). Both test calls and forced daily calls would end with a "Failed. Service Unavailable" error.

I repeated my fix from last time (removing all files in the /var/log directory) and my very next call completed successfully on the first try.

There is definitely something going on which is related to the amount of data being transferred. When my log files were very small, calls completed with no trouble.

I unfortunately still do not have access to a hub, so I can't provide a capture as another data point.
__________________
You inspired me, Pianoman! -- M82A1A
Pianoman, you have inspired me. -- hefe
Pianoman, that's not very inspiring. -- edhara
pianoman is offline   Reply With Quote
Old 02-16-2009, 12:30 AM   #445
cgf
Registered User
 
Join Date: Mar 2002
Location: Boston, MA
Posts: 24
Quote:
Originally Posted by bm5 View Post
guys just bringing this up again. I followed cgf's method way back in early January and it is still working. I am able to get successful calls over turbonet daily.

by the way, I came here to look up something else but was surprised to find this problem is still happening. VERY disappointing response from Tivo
I've been wondering about this myself.

I haven't been having the problem since the hack that I mentioned but 1) I'd like to not have to use the hack and 2) I keep wondering why people with bash access to their S1's aren't at least trying the hack.
cgf is offline   Reply With Quote
Old 02-16-2009, 08:41 AM   #446
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
I have tried the hack.

It improves my percentage *greatly*, but apparently it doesn't completely do away with the need to contact the Mothership -- in the logs, there appears to be a contact with that server (I can't remember -- is it during/right after the "FourOneOne Request" or some such?) even if there are no logs to send. SO, the chances of it hanging during a log POST are mitigated, but there is still the problem of the communication going poorly.

So I've removed the hack in order to (hopefully) be able to give TivoJerry usable logs.


That being sadi: If I hadn't connected for a month or two, and I had telnet access, you're darned right that the first thing I'd do is try to clear logs/block svclog.upload from being created/whatever it TOOK to get my TiVo back on line.

BittMann
bittmann is offline   Reply With Quote
Old 02-17-2009, 10:44 PM   #447
Illusion
Registered User
 
Join Date: Jun 2008
Posts: 29
The issue has cropped up again on my neighbor's Tivo after a few weeks of 100% successful calls.

Mine is currently doing well still....currently.
Illusion is offline   Reply With Quote
Old 02-18-2009, 08:27 AM   #448
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
I know I'm going back in time a little bit on this one, but thought it worth commenting upon as I've switched back & forth between network and dial several times in the interim, and have tried to keep tabs on what is happening:

Quote:
Originally Posted by dcstager View Post
One thing everyone should try if they haven't already is to do a cold reboot every time you try and switch between connecting by modem and connecting by network. Just changing settings does not work immediately. You have to unplug it, let it spin down completely, then plug it back in.

Switching from network to modem you have to do this. Changing from modem to network you have to do it. The network connect works best. A turbonet card or cachecard is cheap on ebay since lots of people are finished with the series 1 hardware.
From looking at the route data in the TiVo itself, I suppose that switching from PPP dialup to turbonet could potentially cause funkiness with the default route. While it is possible to re-initialize (or manually change) the network configuration, the easiest way by far to recover from this issue would be (IMO, and in my experience) to simply restart the recorder. When switching from TurboNet to PPP dialup, however, it seems to "just work" here...a restart certainly won't hurt in that situation, either. That being said, I haven't had to reboot myself -- every time I've switched turbonet to PPP it's "just worked". Not to say that this would be the case for everyone, though, naturally (if for whatever reason you lose your network default route, that will definitely bork your communication the next time you try to make a daily call over the network).

And from my experience, a coldstart (pulling the power, letting everything spin down, etc.) is not required...simply doing a restart from the TiVo menu will completely re-load the kernel and re-establish the network configuration. While a coldstart would be useful in a situation where hardware is "hung", it generally isn't (and shouldn't be!) something that is necessary for clearing network issues.

But like I said: That's MY experience...which may not be what everyone else sees.

BittMann

Last edited by bittmann : 03-02-2009 at 09:15 PM. Reason: clarification
bittmann is offline   Reply With Quote
Old 02-18-2009, 09:21 AM   #449
Illusion
Registered User
 
Join Date: Jun 2008
Posts: 29
Just so you know, me and my neighbor are kinda acting as a control here. We both have Phillips Series 1 on dial up. We use different dial in numbers. We have changed no settings at all since this issue came up. Sometimes it works, sometimes it does not. We have both experienced long periods of repeated failures, and long periods of repeated successes. Long periods in this case is in the weeks time-frame.
Illusion is offline   Reply With Quote
Old 02-18-2009, 10:00 AM   #450
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
Quote:
Originally Posted by cgf View Post
I've been wondering about this myself.

I haven't been having the problem since the hack that I mentioned but 1) I'd like to not have to use the hack and 2) I keep wondering why people with bash access to their S1's aren't at least trying the hack.
I got my null modem adapter the day after my connecting problem cleared up. I was all set to try the hack but didn't need it. I don't think there are that many turbonet problems anymore. The only one I am aware of is dlee708's mother's TIVO (somebody correct me if I am wrong here). Since my issue cleared up I have not had one single failure. Have not had a chance to test dialup again. I did get a failure the last time I tried.
joeysmith is offline   Reply With Quote
Reply
Forum Jump




Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Advertisements

TiVo Community
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
vBulletin Skins by: Relivo Media

(C) 2013 Magenium Solutions - All Rights Reserved. No information may be posted elsewhere without written permission.
TiVoŽ is a registered trademark of TiVo Inc. This site is not owned or operated by TiVo Inc.
All times are GMT -5. The time now is 09:19 PM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |