Hi Liz. No changes anywhere. Did you find idiosyncrasies in my modem?
Thus far I see absolutely consistent results using one W7, two W10, one Vista, four different android systems and an iPhone. All the above listed browsers plus more. None of the browsers have add-ons or extensions except FF, Tor and Chrome on the Win computers. I've disabled all extensions in those browsers on two of the computers for testing. In two cases, the browsers were virgin M$ Edge and never previously used. It also makes no difference connecting by ethernet or wifi.
Conversely, all of my computers and devices (6) thgat I can use to connect to the internet through the Verizon internet work flawlessly to load this CC screen. I also checked it out on a friend computer at a company in Pensacola this morning and her internet worked just fine to pull up the full screen. So basically, I have no way to defeat the error going through Hughes and no way to reproduce the error using three different internet systems that are not Hughes.
Liz, were you able to open an account and access the full add a credit card screen using Hughes? If so, about the only thing left is some goofball glitch my modem.
@MarkJFine mentioned modem DNS and TLS/SSL errors in my two "issue" threads. All that's above my pay grade and doesn't compute. All I know is both of these issues have been ongoing for months and began around the same time. One is always instantly cured with a modem reboot and the other is seemingly incurable.
Thanks for the additional details. Nothing in the SCC jumped out at me, but I did a lot of testing today and will definitely escalate to engineering for their input. I'm failing to get to the Manage Credit Cards page now. However, I did notice that even on my Android on a cellular connection, I was getting the same error. I'll bug Amanda to see if she gets the same thing on her cell connection.
I'll let you know once we have any updates or additional questions.
Your cooperation, patience, and understanding are much appreciated.
Still testing this out... I'm starting to think that the website in general has issues. Amanda also was not able to get to the Manage Credit Cards page on her cellphone (Verizon), and now's she's also getting the 504 error just by trying the main website. I'm waiting on a 3rd cell connection test to see if it also fails. So far, I've never been able to get to that page today in spite of trying all the usual troubleshooting steps. I guess I was lucky yesterday when I did get to the add credit card form.
Are you seeing the same today on your non-HN connections? Have you inquired with natural pet's support about this?
I just checked and I'm able to get manage credit cards section and the add a card popup just fine. I used my phone browser and then used a real computer tethered to the verizon phone internet.
I tried it with the Hughes and got the same useless add a card screen.
Have a good weekend!
I forgot to answer your question Liz. Yes I asked them about the truncated add a card screen. They had no info about such a problem. I sent them a screen cap and they were clueless. Never seen anything like it before. I didn't tell them my ISP was Hughes.
Here's what it looks like on my phone using the 4G LTE Vz. I hit this everytime no matter if it's my phone or a tethered computer.
How odd... I'm not even getting to the non-functional card screen. I only ever get these errors on computer and mobile, respectively:
I'm puzzled... I'm going to test this out on my home PC on Verizon, and Amanda said she'll try on her Comcast connection.
That is bizarre. Over all the years of doing business with this company, the only error or failure I ever remember is the truncated add a card screen that began a few months ago.
Not sure if it helps, but I just tried a traceroute to 18.104.22.168 (Amazon AWS Cloudfront), and it started going wonky with some long delays as soon as it hit Level3 right out of GWID 068.
I wouldn't be shocked if Level3 had some really bad routing tables if that's where these other GWs are going through.
Thank you. This doesn't give me any answers but it does give me questions.
Are the GWID things you speak of going wonky the events 12, 13 and 14 as shown on this traceroute?
Is this what is giving people the 504 and timeout errors when accessing this store?
After running many traceroute operations, I see I always experience the same request time outs so I can't understand why these timeouts mean anything since I have no problem loading the site or any page within it other than the add credit card form.
Why wouldn't I be seeing 504 errors?
Here's the traceroute run through the Verizon connection.
Why is this so much different than the Hughes traceroute?
Does this influence on my abiility to faultlessly load the add a credit card form while I can never see the full form when accessing through Hughes?
1. "Are the GWID things you speak of going wonky the events"
No. Our's were experiencing large delays in hop 5, which is outbound from the gateway @Liz and I are on (assumably, since I think Gaithersburg is also on Beam 68 on the San Diego Gateway). Checking again today, that delay is no longer there, and looks similar to yours.
That said, whatever beam/gateway you are going thru is hitting the same Level3 path I tested yesterday, so clearly the problem is intermittent somewhere in the path:
hop 1: router
hop 2: modem
hop 3-5: Hughes Gateway
hop 6-8: Level3
hop 9-11: Amazon
hop 15: Amazon Cloudfront
2. "Is this what is giving people the 504 and timeout errors"
Not necessarily. Some content delivery networks such as Amazon's put some blocks in place in some areas as a security measure from hackers probing the site. As you can see Amazon's isn't that efficient and ultimately gets through, otherwise it would have just died there in an endless loop.
3. "After running many traceroute operations..."
Again, this wouldn't necessarily cause 504s. Seeing long delays much earlier in the path, as stated in #1 would definitely cause them. For example, yesterday, there were delays as long as 2000ms in hop 6 that could cause a timeout.
4. "Why is this so much different than the Hughes traceroute"
Verizon likely used locally cached information to get to the target. That's why it seemingly went directly flawlessly there in one hop (and in 42ms or less). The second picture doesn't tell me who they originally used upstream to get to Amazon so it's hard to tell how it was originally accomplished.
I should add right here that I'm not a real fan of Level3 and would tend to be suspicious of them as an upstream provider ahead of Hughes every time. I would not doubt that a lot of slowness seen by HughesNet customers was actually an upstream Level3 problem.
I often see really bad routing tables from them, and occasional long delays like yesterday, meaning their equipment may be either set incorrectly (MTUs?) or incapable of handling the load or environment. For example, I see regularly see delays and erratic behavior between Level3 and Microsoft's servers. I also see a ton of spam trace back to their internal servers acting as spam relays, which likely were hacked at one point. Bottom line, it seems as if Level3 don't do a lot of regular maintaining and security checks of their own system, nor do they make regular adjustments to ensure the most efficient path wrt to the load or bad hops (down or overloaded servers that should be avoided). I especially have no respect for the spam part, which to me is unconscionable for an upstream provider.