Valerie Rake

A Log In Problem Resolved - Satellite ISP

Discussion created by Valerie Rake on Feb 16, 2016
Latest reply on Feb 16, 2016 by Stefanie Sanders

I’m planting this (condensed) story here for community reference.  I’m including some of the things that were tried as solutions, as well as what actually worked for this user.  Kudos to CJ Donio, investigating with technical staff, for finally identifying a solution.  Please add any other problems / solutions you've encountered.

 

We had a user report that she was unable to log in to Canvas from her home network, though she could log in from campus.  The user (and other household members also associated with our university) could log into to other university systems from home; the only system not accessible was Canvas.

 

The user’s home ISP was HughesNet, a large satellite service. As an interesting complication, the user could access Canvas from home if she used her phone and her data connection to log in, and then switch from data to her home network.

 

We use shibboleth for authentication.  The user could get to our university’s log in page, enter her credentials, and then was sent to the usual white post-login/redirecting page, which should have sent her to Canvas. That page would sit for about a minute, and then she would get a messaging saying the sever was reset while trying to connect.

 

The first suggestion was to have the user contact her ISP, and have a feature known as 'Turbo Page' or Web Boost (some type of web acceleration) disabled.  I gather that as a general rule, with this feature disabled, Canvas seems to load much more consistently on satellite connections. This suggestion came up again, later on in the troubleshooting.

 

In this case, it turned out that there was no web acceleration function enabled on their connection.  She could turn it off and on, however, and it made no difference.

 

The next suggestion was ask if the ISP was caching DNS for Canvas.  Since Canvas’ IP addresses change regularly, this could cause problems. CJ suggested that the user run a traceroute on her system.  He also suggested that the ISP could be caching certificates; this would be rare but not unheard of.

 

The user did run a traceroute, but it apparently timed out (attributed to network security).

 

Finally, we got the suggestion to have the user try clearing the SSL State from her Window’s machine. That did the trick.  The user said she’d tried clearing the cache early on, but had not gone that deep.

 

In case this strategy is new to you as well, here are the steps CJ sent:

  1. Windows control Panel (says 8.1 and earlier version are the same)
  2. Network and Internet
  3. Delete Browsing History and Cookies
  4. Select the "Content" tab
  5. Scan down the listing for "Clear SSL State"

 

Valerie

Outcomes