cancel
Showing results for 
Search instead for 
Did you mean: 

Has anybody else encountered corrupted HTTPS streams lately?

New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

On the phone now. When did you get GLaDOS to record your prerecorded messages? All I could think of when talking to the robo operator was "Remember that time the platform was sliding into the fire pit and I was like 'Goodbye' and you were like 'No way!' and then I was all 'we were only pretending we were going to murder you'? That was great." (https://www.youtube.com/watch?v=JQ4incSkNOA) This isn't a complaint, I just thought it was really funny. (And for once the robot could actually understand what I was saying. Are you sure it's not someone with a really straight face sitting in a cubicle?)

Phone call over. Fairly brief. Spoke to a very helpful tech named Cassandra Lopez. She gave me a case number immediately (490 41 645) and ran some diagnostics, found nothing wrong. She also gave me a ref number for another department that I seem to recall is loosely affiliated with HughesNet for "complementary" diagnostics of my home equipment. (I think I'll pass on that one.)

What should I do next, Chris?

By the way, I have posted all of my troubleshooting notes on my blog, including packet captures for both sides of a failed HTTP download. Your engineers may find it useful:

https://jacksontech.net/index.php/2015/07/hughesnet-troubleshooting/

Can I make some constructive criticism? I was so excited when I thought I heard bebop jazz on the hold music. It turned out to be really watered down blues (ish, of a sort) music. How much would it cost HughesNet to license some Jimmy Smith? 

Anyone else call in yet?

New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

Probably some sort of compression/acceleration for our benefit. Probably overloaded and eating things it shouldn't. There is a status report for "TCP Acceleration" deep in your modem's Control Center. I can't find this feature documented anywhere...
Associate Professor

Re: Has anybody else encountered corrupted HTTPS streams lately?

New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

There's no way to be positive without me trying to download the same file from the same server from a non-HughesNet connection. I can try it next time I go to the college campus, although that might be awhile.

That being said, I coaxed another friend to do some experimenting with netcat on his server. It was a non-HTTP TCP session over port 8888 and it exhibited the same packet reshaping as the server in the Netherlands.

Level3 is a commonality. Traceroute to the first server goes through Level 3 in Dallas, traceroute to the second server goes through Level3 in Washington. Traceroute to the files I listed also go through Level3. They all end at different ISPs.

I think if Level3 was doing that kind of reshaping there'd be a *lot* more reports of trouble though. However, it could be an issue if HughesNet is peered with Level3 at AMA, and that particular link is being problematic.

For those of you that are NOT having problems: can you traceroute to those servers above and see if they go through Level3? Please note that the Ruby gem is actually being downloaded from rubygems.global.ssl.fastly.net due to a few HTTP redirects. (The Ruby gem and the Django source are the most predictably failure-prone files.)
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

It just occurred to me what might be reshaping the packets: the system HughesNet uses to keep my connection rate-limited at the 10Mbit/s I'm paying for...

Hmm, except that should just drop packets, not alter them.

I need to research more on traffic shaping.
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

---------------------------------------------------------------
TCP Acceleration Diagnostic Statistics --------------------------------------------------------------- Status                                                        GOOD All Backbones UP                         YES                  GOOD  IGPW Error                               NO                     IPGW Flow Contrl in effect               NO                     PBP Resets Received                      0                    GOOD  PBP Resets Transmitted                   0                    GOOD  RBP Poll SACKS Rcvd                      0                      RBP Poll SACKS Txed                      0                      PBP SACKs Received                       0(0.00%)             GOOD  PBP SACKs Transmitted                    0(0.00%)             GOOD  PBP Zero Window Received                 0(0.00%)             GOOD  PBP Zero Window Transmitted              0(0.00%)             GOOD  PBP Packets Retransmitted                0(0.00%)             GOOD  TSK Conn Resets                          0(0.00%)             GOOD  TCP SACKs Received                       2(0.01%)             GOOD  TCP SACKs Transmitted                    0(0.00%)             GOOD  TCP Zero Window Received                 0(0.00%)             GOOD  TCP Zero Window Transmitted              0(0.00%)             GOOD  TCP Packets Retransmitted                4(0.03%)             GOOD  PEP Outage Time:  0 %  PEP Helper Stats: MAX LLRTT BB#                            0                    Packets Transmitted                      444                  Packets Received                         24614                TCP Packets Received                     7377                 TCP Packets Transmitted                  15126                Num of Spoofed Conns                     53  <<<< wat?                 
HughesNet, what are you doing
HughesNet

HughesNet, stahp

Personally, my money's on this system. These stats are from my modem, so if there's something going wrong on the HughesNet side, I'm guessing I have no way of knowing.

Could also be "Inroute Protection" I suppose.

While I'm wild mass guessing (WMG) I'm also going to postulate solar flares and interference from the top-secret SETI listening post under my house.

Edit: Seems like it occasionally hits "BAD" status without triggering a red X:
TCP Packets Retransmitted                5(2.02%)             BAD 
Associate Professor

Re: Has anybody else encountered corrupted HTTPS streams lately?

Well, doubt I ran a trace to the exact addresses you did, aside from the ruby one as I didn't read your blog post, or packet captures any.


Remember, I am on a totally different beam and gateway, while L3 is the ISP for Hughes at my gateway, I am ALWAYS routed through Qwest, for everything, and that Qwest hop always gives issues in the evenings.  Strange that L3 is offloading data to what is essentially Century-Link.

Give me more IP's or addresses and I will give you more trace results. >.>  Rather bored today.
Associate Professor

Re: Has anybody else encountered corrupted HTTPS streams lately?

Well, doubt I ran a trace to the exact addresses you did, aside from the ruby one as I didn't read your blog post, or packet captures any.


Remember, I am on a totally different beam and gateway, while L3 is the ISP for Hughes at my gateway, I am ALWAYS routed through Qwest, for everything, and that Qwest hop always gives issues in the evenings.  Strange that L3 is offloading data to what is essentially Century-Link.

Give me more IP's or addresses and I will give you more trace results. >.>  Rather bored today.
Associate Professor

Re: Has anybody else encountered corrupted HTTPS streams lately?

One day, ONE DAY, I shall find out how part of the Hughes infrastructure works... I am wondering if they are modifying the TCP packets because of the high latency and most systems requiring "low" latency for connectivity...  I know they have to play tricks with data when your connecting to battle.net, and the PSN.
New Member

Re: Has anybody else encountered corrupted HTTPS streams lately?

Git fetches fail too, both HTTPS and with the Git protocol (TCP based, of course). How about plain ol' github.com?
traceroute to github.com (192.30.252.128), 30 hops max, 60 byte packets  1  router.home.lan (192.168.1.1)  0.675 ms  0.696 ms  0.715 ms  2  100.64.66.209 (100.64.66.209)  1.505 ms  1.264 ms  1.304 ms  3  dpc6935193146.direcpc.com (69.35.193.146)  705.181 ms  1141.323 ms  1435.407 ms  4  dpc6935196058.direcpc.com (69.35.196.58)  1735.510 ms *  625.403 ms  5  * * *  6  ae-1-60.edge3.Washington4.Level3.net (4.69.149.18)  662.701 ms  672.544 ms  642.256 ms  7  ae-1-60.edge3.Washington4.Level3.net (4.69.149.18)  612.648 ms  652.673 ms  662.773 ms  8  GITHUB-INC.edge3.Washington4.Level3.net (4.53.116.102)  642.714 ms  622.330 ms  626.069 ms  9  192.30.252.201 (192.30.252.201)  647.447 ms  726.175 ms  676.327 ms 10  github.com (192.30.252.128)  636.464 ms  634.074 ms  650.374 ms
The machine right after the last DirectPC host never gives me a response...

I'm bored too. Kinda bad that we both consider the HughesNet forum to be entertainment.