[schmack]

If I do a MENU 6-3 Connection Test, it says it is connected and then is on-line to download BB and to Sling. However, when I return to it some hours later, it's offline again. I can repeat to be back in business.

Any idea how to fix this?

TIA for help!

 

[garys]

Have you tried the Broadband Setup? MENU 6 - 1 - 9 - 2? It may need to be reset.

 

[schmack]

I don't have a 6-1-9-2, only a 6-1-8-2 (no 9 option on that third menu), and it shows Connected and has an IP and the like.

I just put it in the DMZ, as specified here: http://www.dbstalk.com/showthread.php?t=198790&page=3

Perhaps this will fix my problem.

 

[3HaloODST]

I believe that it is more likely a DHCP issue than a port forwarding/DMZ issue. What router do you have? Try assigning the 722K a static IP if your router model/firmware allows.

 

[Mr.Gadget]

I believe that it is more likely a DHCP issue than a port forwarding/DMZ issue. What router do you have? Try assigning the 722K a static IP if your router model/firmware allows.

I don't think it's a DHCP issue (on the router end). If it is related to the IP Address, then it is on the 722k end. I have had the 722k get an address, exit the broadband setup menu, re-enter the menu and the address was lost again within moments! Very flaky! It wasn't always this way, it worked last year.

 

[HDlover]

Yep, having same problem as well as others. Something needs to be fixed by Dish. Makes a sling adapter almost worthless. Also, when the 722k updates every night, does it lose it's connection also? If so, that needs to be fixed also. Again renders the sling adapter almost worthless.

 

[FastNOC]

I don't have a 6-1-9-2, only a 6-1-8-2 (no 9 option on that third menu), and it shows Connected and has an IP and the like.

I just put it in the DMZ, as specified here: http://www.dbstalk.com/showthread.php?t=198790&page=3

Perhaps this will fix my problem.

first thing you should do is take it out of your dmz. unless it's absolutely required, you NEVER want to do that. it opens your entire network to all ports.

 

[nybill38]

I believe this problem has been fixed, my 722K has been working great the past few days, I could be wrong but it appears that a software update has happened, im on L750 now

I'm getting the Hopper installed tomorrow so hopefully that is not have the connectivity issues the 722K was having

 

[bnborg]

I have L750 oon my 722K and the Dish On Line website always shows mine as offline. I have had L750 for a long time.

My router always shows it as one of its current DHCP clients. The address never changes.

 

[HDlover]

Well as Dish said, it appears to be an AT&T problem. I did as they said and hooked it up to my router behind the AT&T router. Seems to have fixed the problem.

 

[bnborg]

I have Frontier DSL but the modem/router is mine. I bought it from Newegg.

Is there something special that I need to configure on the router to get it to work?

Another thing, I notice that when I turn the DVR off (standby) it does drop the connection, as shown by the lights on the Ethernet switch. For DOL or DRA to work correctly, this should not happen. This still does not explain having to go to diagnostics every time I want to use DOL/DRA.

Later: I found two settings that might matter. Under "Stateful Inspection", I found timeout settings for both tcp and udp. Udp was set at 3 minutes. I set both to the maximum setting, 65535 seconds. The second setting was for IPSec PassThrough, which I enabled. We'll see how it goes.

 

[bnborg]

Changing settings on the modem/router did not seem to help.

I went back today and neither Dish On Line nor Dish Remote Access could see my 722k until I went into diagnostics and checked the connection. As usual the connection was fine but checking it "woke it up" and both DOL and DRA saw my dvr.

Even though it does show my OTA channels now, Dish On Line still sucks. It still takes "forever" to show anything besides a bunch of conflicts that I do not care about. DRA does not show the conflicts unless you select that link.

 

[HDlover]

I'm talking about a uverse 2Wire modem and router combined.

 

[HDlover]

Changing settings on the modem/router did not seem to help.

I went back today and neither Dish On Line nor Dish Remote Access could see my 722k until I went into diagnostics and checked the connection. As usual the connection was fine but checking it "woke it up" and both DOL and DRA saw my dvr.

Even though it does show my OTA channels now, Dish On Line still sucks. It still takes "forever" to show anything besides a bunch of conflicts that I do not care about. DRA does not show the conflicts unless you select that link.

Have you tried adding another router behind your router?

 

[bnborg]

No, but I may as well try it.

 

[rr999]

Sure doesn't look like a network problem to me. Looks like an application problem. I ran a couple packet captures and the problem I'm seeing boils down to this (showing only traffic between dvr and msg.sling.com):

Here, in the middle of the night, the dvr closes two connections it has to msg.sling.com (which seems to be the service that handles the persistent connections):

3908 12045.239687 192.168.1.65 8.7.94.107 TCP 60 7049 > colubris [FIN, ACK] Seq=2 Ack=1 Win=1460 Len=0
3909 12045.308503 8.7.94.107 192.168.1.65 TCP 60 colubris > 7049 [ACK] Seq=1 Ack=3 Win=4466 Len=0
3910 12045.309280 8.7.94.107 192.168.1.65 TCP 60 colubris > 7049 [FIN, ACK] Seq=1 Ack=3 Win=4466 Len=0
3911 12045.309550 192.168.1.65 8.7.94.107 TCP 60 7049 > colubris [ACK] Seq=3 Ack=2 Win=1460 Len=0
3912 12045.345151 192.168.1.65 8.7.94.107 TCP 60 33194 > colubris [FIN, ACK] Seq=2 Ack=1 Win=1460 Len=0
3913 12045.414167 8.7.94.107 192.168.1.65 TCP 60 colubris > 33194 [ACK] Seq=1 Ack=3 Win=4426 Len=0
3914 12045.414543 8.7.94.107 192.168.1.65 TCP 60 colubris > 33194 [FIN, ACK] Seq=1 Ack=3 Win=4426 Len=0
3915 12045.414833 192.168.1.65 8.7.94.107 TCP 60 33194 > colubris [ACK] Seq=3 Ack=2 Win=1460 Len=0


Then, 154 seconds later, the dvr opens a new connection (local port 7239) and registers (REG 0000/ACK 0000 messages, data not shown):

3990 12199.020330 192.168.1.65 8.7.94.107 TCP 74 7239 > colubris [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=4294783926 TSecr=0 WS=4
3991 12199.089875 8.7.94.107 192.168.1.65 TCP 66 colubris > 7239 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=1 SACK_PERM=1
3992 12199.090246 192.168.1.65 8.7.94.107 TCP 60 7239 > colubris [ACK] Seq=1 Ack=1 Win=5840 Len=0
3993 12199.091874 192.168.1.65 8.7.94.107 TCP 97 7239 > colubris [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=43
3994 12199.161437 8.7.94.107 192.168.1.65 TCP 97 colubris > 7239 [PSH, ACK] Seq=1 Ack=44 Win=4423 Len=43
3995 12199.161779 192.168.1.65 8.7.94.107 TCP 60 7239 > colubris [ACK] Seq=44 Ack=44 Win=5840 Len=0
4062 12319.225271 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0
4063 12319.294490 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 7239 [ACK] Seq=44 Ack=44 Win=4423 Len=0

Much later (9000 seconds), it opens a second connection (local port 55814) while the first connection remains open and is active on both ends (see keep-alive):

8329 21204.456071 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0
8331 21204.525632 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 7239 [ACK] Seq=44 Ack=44 Win=4423 Len=0
8380 21324.589673 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0
8381 21324.659250 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 7239 [ACK] Seq=44 Ack=44 Win=4423 Len=0
8391 21331.830412 192.168.1.65 8.7.94.107 TCP 74 55814 > colubris [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=8949223 TSecr=0 WS=4
8392 21331.900388 8.7.94.107 192.168.1.65 TCP 66 colubris > 55814 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=1 SACK_PERM=1
8393 21331.900820 192.168.1.65 8.7.94.107 TCP 60 55814 > colubris [ACK] Seq=1 Ack=1 Win=5840 Len=0
8394 21332.832570 192.168.1.65 8.7.94.107 TCP 77 55814 > colubris [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=23
8395 21332.902382 8.7.94.107 192.168.1.65 TCP 77 colubris > 55814 [PSH, ACK] Seq=1 Ack=24 Win=4403 Len=23
8396 21332.902562 192.168.1.65 8.7.94.107 TCP 60 55814 > colubris [ACK] Seq=24 Ack=24 Win=5840 Len=0
8427 21444.724222 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0
8428 21444.793831 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 7239 [ACK] Seq=44 Ack=44 Win=4423 Len=0
8472 21564.858761 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0
8473 21564.927552 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 7239 [ACK] Seq=44 Ack=44 Win=4423 Len=0
8491 21623.057914 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 55814 > colubris [ACK] Seq=23 Ack=24 Win=5840 Len=0
8492 21623.128110 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 55814 [ACK] Seq=24 Ack=24 Win=4403 Len=0

Later, when I attempt to connect to the dvr from the mobile app, the msg service sends a "SND 1032" message to one of the connections and it's ack'ed at the protocol level, but it is not ack'ed (via an expected ACK 0000) message from the application level, so it appears the msg service times out the connection after about 5 seconds and closes its end. The dvr doesn't close its end. The mobile app remains on the "your dvr is not connected", apparently since the dvr didn't respond to the SND. Note, though, that the second msg connection (port 7239) is still active:

10103 26689.479490 8.7.94.107 192.168.1.65 TCP 77 colubris > 55814 [PSH, ACK] Seq=24 Ack=24 Win=4403 Len=23
10104 26689.479856 192.168.1.65 8.7.94.107 TCP 60 55814 > colubris [ACK] Seq=24 Ack=47 Win=5840 Len=0
10106 26694.484202 8.7.94.107 192.168.1.65 TCP 60 colubris > 55814 [FIN, ACK] Seq=47 Ack=24 Win=4403 Len=0
10107 26694.524003 192.168.1.65 8.7.94.107 TCP 60 55814 > colubris [ACK] Seq=24 Ack=48 Win=5840 Len=0
10109 26698.818418 8.7.94.107 192.168.1.65 TCP 60 colubris > 55814 [RST, ACK] Seq=48 Ack=24 Win=4403 Len=0
10125 26727.633844 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0
10126 26727.703211 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 7239 [ACK] Seq=44 Ack=44 Win=4423 Len=0
10164 26847.767428 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0
10165 26847.836416 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 7239 [ACK] Seq=44 Ack=44 Win=4423 Len=0

When I go into the Network Setup menu to wake up the connection, the dvr then appears to notice that the 2nd connection (port 55814) has been closed and closes its end. Then it establishes a new connection (port 42891), does a register (REG 0000/ACK 0000), and once that's happened I reenter the mobile app and now the SND message that arrives on the new connection gets an ACK from the application and after some delay the mobile app gets connected (not shown):

10175 26871.348528 192.168.1.65 8.7.94.107 TCP 60 55814 > colubris [RST, ACK] Seq=24 Ack=48 Win=5840 Len=0
10178 26871.417584 192.168.1.65 8.7.94.107 TCP 74 42891 > colubris [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=14488809 TSecr=0 WS=4
10179 26871.487281 8.7.94.107 192.168.1.65 TCP 66 colubris > 42891 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=1 SACK_PERM=1
10180 26871.487628 192.168.1.65 8.7.94.107 TCP 60 42891 > colubris [ACK] Seq=1 Ack=1 Win=5840 Len=0
10181 26872.434259 192.168.1.65 8.7.94.107 TCP 77 42891 > colubris [PSH, ACK] Seq=1 Ack=1 Win=5840 Len=23
10182 26872.503776 8.7.94.107 192.168.1.65 TCP 77 colubris > 42891 [PSH, ACK] Seq=1 Ack=24 Win=4403 Len=23
10183 26872.504214 192.168.1.65 8.7.94.107 TCP 60 42891 > colubris [ACK] Seq=24 Ack=24 Win=5840 Len=0
10210 26967.900784 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0
10211 26967.970168 8.7.94.107 192.168.1.65 TCP 60 [TCP Keep-Alive ACK] colubris > 7239 [ACK] Seq=44 Ack=44 Win=4423 Len=0
10227 27034.725679 8.7.94.107 192.168.1.65 TCP 77 colubris > 42891 [PSH, ACK] Seq=24 Ack=24 Win=4403 Len=23
10228 27034.725998 192.168.1.65 8.7.94.107 TCP 60 42891 > colubris [ACK] Seq=24 Ack=47 Win=5840 Len=0
10229 27034.730109 192.168.1.65 8.7.94.107 TCP 77 42891 > colubris [PSH, ACK] Seq=24 Ack=47 Win=5840 Len=23
10231 27034.897866 8.7.94.107 192.168.1.65 TCP 60 colubris > 42891 [ACK] Seq=47 Ack=47 Win=4426 Len=0
10342 27088.034671 192.168.1.65 8.7.94.107 TCP 60 [TCP Keep-Alive] 7239 > colubris [ACK] Seq=43 Ack=44 Win=5840 Len=0


So long story short, there don't appear to be any issues at all with connectivity between the DVR and the msg service at the protocol level. Rather, it's the dvr application software that stops receiving data from the connection despite the fact that it has been successfully received and ack'ed at the TCP level by the dvr.

I captured another sequence like this a day later. Two connections open to msg.sling.com. Active TCP keep-alive's on both, but when a SND 1032 message is sent to the dvr on one of the connections, it doesn't respond with an ACK and the server side closes the connection. Going into Network Setup causes a new connection to be established and remote access starts working.

 

[Mr.Gadget]

Echostar - Wake up!

This problem has been going on for over 6 months now. SOLUTION???? Getting tired of pressing 20 buttons to get the service online again. Really, you can't figure it out?

Can the "DIRT" contacts help here???

 

[HDlover]

Have you tried a router behind your router?

 

[Mr.Gadget]

Have you tried a router behind your router?

NO. Why would this make a difference? The service worked for almost two years, then stopped with the latest software update.

 

[HDlover]

Mine use to work also it stopped working so I put a router behind my router. Got anything to lose by trying? I'm sure you have some old routers laying around, doesn't everyone?