Per a private message from Jay, I called HughesNet this morning.
I had to re-explain the issue to the Customer Service rep even though she could see the referenced case# that Jay gave me with instructions for me to talk to the Home Technical Support team. That seemed to be a waste of my and her time. Since I was directed to call HN and use the case# to be connected to the Home Technical Support Team, she should have immediately connected me to that department. It took 10 minutes before she connected me to that department.
Once I got to Brett at Home Technical Support I had to re-explain the issues. Unfortunately he could not do much since it wasn't his job (he is a contractor for HughesNet). However, he did have me do some things that no one else at HughesNet had ever suggested. He had me change the modem/router DNS settings, the Wi-Fi bandwidth, and update the time settings. Now to see if these changes solved the issues I've been experiencing since 15 December 2018. Stay tuned...
Understand the DNS and bandwidth issues.
Resetting the DNS because of a bad entry is always a good first thing to do. However, I'm not sure setting it to something other than the default (Obtain from ISP) is a good idea. Third-party, free DNSes might be quicker than HN's, but are exremely susceptible to spoofing.
Using 802.11ac (40 channel, 80MHz b/w) on 5GHz should be done whenever possible, because it allows the maximum transfer rate. Some older devices don't do 'ac', just 'n' or 'g' so you might not get the full b/w or it might not work at all (no 'g' on that setting).
Setting the time zone is curious advice, since I'm not certain anything other than the internal logs themselves do anything with it. So, that's just weird.
Jumping in for Jay while he's out the next couple of days. I won't dance around the fact that I am not happy to hear what occurred on your call to both our support lines. Agreed with Mark on most points, but the time setting could be a recommendation to make sure that there are no conflicts with certificates and that any handshakes don't fail because of time discrepancies. Most likely it is all in regard to security protocols being touchy. I'll check in with you tomorrow to get updates on the situation.
Update after 24 hours with the different DNS and bandwidth settings. Ethernet connected computers have always connected to the ftp server on multiple tries over the past 24 hours. Wi-Fi connected devices had success once but have failed multiple times over the past 24 hours. I have not yet rebooted the modem; waiting to see if the Ethernet connected computers (which are primary for ftp access) lose their ftp access.
Have also noticed that loading of web pages in the web browser is much snappier than it has been for weeks.
Not ready to declare success yet but looking more hopeful, thanks to the settings changes that the Home Technical Support rep made yesterday.
That is great news! As for the wireless devices, do you have a way to test these devices for packet loss over the air? Do the devices exhibit the same behavior on both 2.4GHz and 5GHz?
Sorry for the delay in updating on the ftp issue. After changing the DNS setting on the modem on Thursday, 21 March, it appeared that the ftp connection issue might have been resolved, at least for the Ethernet connected computers. I made several ftp connections on Thursday and Friday from multiple computers with different OS versions and they connected without any problems. Saturday morning, 23 March, I connected OK from one computer, however Saturday afternoon the connection from the same computer to the same ftp server failed. Over these same three days Wi-Fi connected handheld devices were hit-and-miss with ftp connections whether on 2 GHz or 5 GHz. The Wi-Fi handheld devices did connect via the AT&T LTE network however using the same software.
Sunday morning, 24 March, I cycled the power on the modem. Computer connections via Ethernet were OK. Wi-Fi ftp connection worked from one device but failed on another device. Monday morning, an Ethernet computer connected OK, but the same computer and a Wi-Fi device failed to connect to the ftp server that evening.
Tuesday morning, 26 March, at 0650 MST: I tested the ftp connection from one of the Ethernet connected computers; it worked. However at 0705 MST the same connection failed. I don't have any way to detect packet loss but did run a traceroute from the computer that failed to connect. It failed to complete the trace:
traceroute to www.weasner.com (184.108.40.206), 64 hops max, 72 byte packets
1 192.168.42.1 (192.168.42.1) 0.469 ms 0.232 ms 0.197 ms
2 100.67.112.193 (100.67.112.193) 0.424 ms 0.357 ms 0.256 ms
3 host1743300129217.direcway.com (220.127.116.11) 590.670 ms 566.960 ms 589.957 ms
4 host17433004221.direcway.com (18.104.22.168) 599.858 ms 637.780 ms 599.531 ms
5 ae3-651.bar2.sanfrancisco1.level3.net (22.214.171.124) 619.946 ms 597.855 ms 609.841 ms
6 * * *
7 sjo-b21-link.telia.net (126.96.36.199) 602.075 ms 627.716 ms 639.845 ms
8 defensenet-ic-302038-sjo-b21.c.telia.net (188.8.131.52) 609.946 ms 637.273 ms 589.843 ms
9 * * *
10 184.108.40.206 (220.127.116.11) 590.229 ms 596.803 ms 609.822 ms
11 * * *
I realize (like most technical people) that Internet routing is a mess. But it does seem strange that the routing via the HughesNet network connection is hit-n-miss but that it always works via the AT&T LTE network. At this point I'm not certain how to proceed.
My last ftp session was on Thursday, 18 April, beginning at 0725 MST. Over the next 30 minutes I experienced ftp failures. If I could get logged in to my server I could not get a directory listing. If I could get a directory listing I could not upload a 10 KB text file. It took multiple reconnections before I was successful. So, yes, the problem still seems to be occurring.
I've kind of lost the bubble on where we were on this.
Did we ever check to see if your FTP client had a timeout setting, and if so, was it set to 120 seconds?
Both client apps I use on the desktop do have timeout settings. They were 60 seconds on one and 30 seconds on the other. I have set both to 120 seconds. Will see what happens.