When I first got HughesNet in beginning of 2018, I could access github just fine. About six months after and until now, I have been unable to load it. The website and any programs that update from that site cannot connect. Google Chrome and Firefox both just give me a "connection reset" error or "connection timed out" error. Seems to be the case for any repository as google drive does it too however that will still load 80% of the time. I contacted support and they simply said "GitHub doesn't work with us. Try Google Drive." then they turned my web accelerator back on as an attempt to fix it. (I have it turned off because some websites don't like it.) Sure I can use Google Drive but I can't have everyone that I download files from just switch over to that as well.
Anyone have experience with this and come up with any workarounds or cures?
I'm not. Mine's getting locked up somewhere 8 hops past HughesNet.
Pinging is fine, but the response is intermittently delayed and really not representative of what you need for a contiguous stream of data.
That's not bad. Mine goes from Level3 to zayo in LA and dies somewhere in there.
When I'm on hughesnet and ask a search engine "What's my IP address" it gives me a 184.xx.xx.xx number (dynamically assigned, may be different on different days).
That's same number that the web page on github-debug dot com retrieves in its tests.
It is the same number the github-debug dot com diagnostic is trying to ping when it reports "Destination net unreachable".
If I try to ping the same number, I also get "Destination net unreachable".
That "184.xx.xx.xx" number does not appear in any tracert that I've run.
Interesting. That's actually your public IPv4. They won't be able to get to it because you're behind a double-NAT. So if they've suddenly started using that technique to verify faked IPs it's not going to get very far. Come to think of it, it might not work for people behind VPNs, either.
Ok. So this is getting weird.
I went to https://188.8.131.52, bypassing the DNS going direct to their IP. FF told me it there was a domain error with the certificate (and rightfully so). I bipassed that and was redirected to https://github.com. The page displayed normally. Cool...
Did a shift-refresh to make sure it wasn't a cached version, and it timed out.
So it's definitely not IP validation because I wouldn't have gotten thru. There's something intermittently clogging the warp engines somewhere in the path and someone needs to play Spock.
Speaking of intermittent (and sllloooooow), I let it go and got in again:
"There's something intermittently clogging the warp engines somewhere in the path and someone needs to play Spock."
Github is currently working for me via Hughesnet.
I tried the github-debug dot com diagnostics again, and these two errors still occurred, so I guess they are irrelevant.
Two errors that stood out to me were:
- The ssh git clone test also said "The authenticity of host '[github dot com]' (140...4) can't be established."
- A ping test from some github host to my ip address said "Destination Net Unreachable". [this was the 184.xx.xx.xx public ipv4 address which as MarkJFine pointed out, might not work from behind a NAT (network address translation) router, either hughesnet's or github's.]
I believe I've solved the issue.
Like the other posters here, I haven't been able to load pages from Github in my web browser or to use git over HTTPS for some time now. However, I noticed that I can ping Github without any issues (so DNS is resolving correctly and there is a valid network path from my machine to github.com). I also noticed that using git over SSH works perfectly well.
So...it looks like I'm just seeing HTTPS traffic to Github throttled to the point of being unusable most of the time (with some occasional reprieves as mentioned by other posters).
To fix this, I simply created a SOCKS5 proxy to a remote computer (not on HughesNet's network) that I have SSH access to and then configured my web browser to send all web traffic through this proxy. And...voila! Github loads right away. That's all it takes to solve the issue until HughesNet gets their act together and fixes it for the rest of us.
Here are the steps I used:
Step 1: Open an SSH tunnel (on localhost port 1080) to a remote server to use as an HTTP(S) proxy
$ ssh -f -N -D 1080 email@example.com
Step 2: Launch your browser with the proxy enabled (I'm using chromium here)
$ chromium --proxy-server=socks5://localhost:1080
And that's all there is to it.
If you don't have SSH access to a remote server, just look for an HTTP(S) proxy server that you can use. It's all the same in the end. The end goal is to have your browser route all outgoing traffic (over the HughesNet network) to the proxy server and then (over the not-HughesNet network) to your end destination (such as github.com). This allows you to totally dodge the HughesNet-Github bottleneck.
Have fun and happy hacking!
Using open proxies that you've arbitrarily chosen off the internet is a really really bad idea.
I can periodically get as far as the home page loading but it never fully loads. If I try to navigate anywhere else, it just fails.
That's actually somewhat telling, or at least I think it is, though I'm not very versed in the whole network thing. It makes me wonder if the problem is somewhere along the connection path, as in one or more of the providers along the way. Century Link, for example, seems to be popping up a lot over the last couple of years when people are having connection issues, whatever they may be, to specific sites, and because the route to the destination depends on the subscriber's gateway, and its location, only some may be affected.
Again, I'm not very versed in this kind of thing, but maybe Mark or Corrosive has an idea as to whether this could be the problem, or at least a contributor to it.
Edit: I should have read the rest of the thread before posting, as I see that Mark has already touched on this possibility...
"Seems that there are some really horrendous routes being generated to Github somewhere, and by somewhere, I probably know where (not HN tho)."