Problems with connections to the UVP site.

[otoien]

From early this week I have kept getting "This site can’t be reached" messages when I try connecting from Chrome under Windows 10. It has been on and off - I sometimes can connect for a short while, but then for instance when I have tried posting a message the connection is lost. I wait and try again later and by reloading the edit page  I am finally able to get the post though. I do not see any problems connecting to other sites from Chrome.

 

Then just now I got the idea to try the Edge browser, and it connected immediately without problems while Chrome continues to refuse to connect. This also happened after the cache was emptied in Chrome and Chrome restarted. So, this seems to be a Chrome specific problem. Does anyone else experiencing this?

 

Edit: I spoke too soon, the problems also appeared in Edge when I tried to make this post. I just had a lucky moment when I initially connected with Edge. I edited the title accordingly.

[Cadmium]

Just to report I have had no problems, but I have no idea what the problem might be.

 

[ulf]

dito

[nfoto]

No problems. Firefox on Windows and Linux.

[otoien]

OK, thank for the feedback. I will have to keep experimenting - perhaps see if a VPN connection to the university that use a different name server than my internet provider could improve it. 

[JMC]

I'm having problems with it today - seems to be intermittent though, some times it goes straight through and other times it just hangs (Firefox, Windows 8).

[dabateman]

No problems with chrome on Android. 

But I did see that many of the entries in the dedicated uv lens section have gone missing. Or cleaned up. 

[otoien]

7 hours ago, JMC said:

I'm having problems with it today - seems to be intermittent though, some times it goes straight through and other times it just hangs (Firefox, Windows 8).

Yes, that is what I have been seeing. When it works the response is quite fast, but then intermittent hangs.

[Andrea B.]

EDITOR'S NOTE:  I combined my several responses to the connection difficulties.

 

Is hosting service running?

I just checked the Site5 server status and there have been no shutdowns during December.

 

Going now to check other things.

No problems found in our UVP System Logs or Error Logs.

 

I'll try Chrome and Firefox now.

No problems on Macbook with Safari, Chrome & Firefox.

 

If my husband's machine is still on, I'll go try Windows now.

We've got Windows 10 with Firefox and Opera. No problems accessing UVP.

(We don't have Windows 8 anymore.)

 

So I think the problems might be local?

If you happen to have one of the phone-answering Internet Service Providers, then please give them a call.

Or check their web pages for outage or delay reports.

 

I also tried to check for internet outages across the US, but it is difficult to get up-to-date info. 

You could try putting your ISP url into DownDetector or Is It Down Right Now.

https://downdetector.com  (only for larger companies)

https://www.isitdownrightnow.com  (works for any url)

 

[Reboot your router? Clean up browser history & caches? Reboot laptop or PC?]

 

My last suggestion for the evening --

if you are familiar with the command line,

then run "traceroute www.ultravioletphotography.com".

That is the mac/unix version. I don't know what it is called on windows, but I'll go look it up.

For windows, run "tracert www.ultravioletphotography.com".

[Andrea B.]

BTW, windows 8?? I thought that was obsolete? No more security patches?

[Andrea B.]

Øyvind, I ran a ping on www.uaf.edu. I got one hit and then a series of failures. So I think the problem is somewhere in Alaska.

 

 

[Andrea B.]

OK, the problem is definitely in Alaska.

I ran a traceroute on www.uaf.edu. It hit Santa Fe, Albuquerque, Los Angeles, Santa Clara, Seattle and finally hit Alaska Communications. But there it stopped at internal.alaska.net.

 

However, I don't know whether that means that the signal is stuck inside Alaska Communications and cannot get out or whether the signal leaves Alaska Communications, but cannot go anywhere.

(By "signal", I mean packets, etc.)

 

I think the signal is stuck in Anchorage. So it is never getting to Fairbanks. 

 

Here is the traceroute.

--- www.uaf.edu ping statistics ---

13 packets transmitted, 0 packets received, 100.0% packet loss

annedi@Annedis-MacBook-Pro16 ~ % traceroute www.uaf.edu

traceroute to www.uaf.edu (137.229.114.150), 64 hops max, 52 byte packets

1  192.168.0.1 (192.168.0.1)  7.936 ms  1.599 ms  1.470 ms

2  96.120.1.225 (96.120.1.225)  11.467 ms  12.233 ms  13.567 ms

3  po-301-1204-rur02.santafe.nm.albuq.comcast.net (69.139.177.65)  12.157 ms  12.976 ms  11.578 ms

4  be-2-ar02.albuquerque.nm.albuq.comcast.net (68.86.182.221)  38.255 ms  38.502 ms  40.487 ms

5  be-36842-cs04.losangeles.ca.ibone.comcast.net (96.110.45.253)  58.775 ms  58.851 ms

    be-36822-cs02.losangeles.ca.ibone.comcast.net (96.110.45.245)  59.990 ms

6  be-2311-pe11.losangeles.ca.ibone.comcast.net (96.110.33.10)  59.102 ms

    be-2111-pe11.losangeles.ca.ibone.comcast.net (96.110.33.2)  57.934 ms

    be-2211-pe11.losangeles.ca.ibone.comcast.net (96.110.33.6)  59.104 ms

7  ix-ae-16-0.tcore1.lvw-losangeles.as6453.net (66.110.59.249)  59.996 ms  61.080 ms  60.604 ms

8  if-ae-8-3.tcore1.sv1-santaclara.as6453.net (63.243.250.58)  69.845 ms  71.424 ms

    if-ae-60-2.tcore1.sv1-santaclara.as6453.net (63.243.250.54)  69.269 ms

9  if-ae-20-2.tcore1.00s-seattle.as6453.net (64.86.123.94)  68.163 ms

    if-ae-45-2.tcore1.00s-seattle.as6453.net (64.86.123.26)  68.119 ms  66.860 ms

10  64.86.123.135 (64.86.123.135)  67.390 ms  68.153 ms  67.918 ms

11  ae9-r2.nwc.acsalaska.net (63.140.116.224)  117.748 ms

    xe-0-0-0-r2.cwc.acsalaska.net (63.140.116.72)  110.205 ms

    ae9-r2.nwc.acsalaska.net (63.140.116.224)  110.534 ms

12  xe-2-1-0-mx1.grn.acsalaska.net (63.140.116.147)  110.311 ms

    ae0-mx1.grn.acsalaska.net (63.140.116.69)  108.260 ms  110.820 ms

13  209-193-62-49.internal.acsalaska.net (209.193.62.49)  109.651 ms

    209-193-62-51.internal.acsalaska.net (209.193.62.51)  109.407 ms

    209-193-62-49.internal.acsalaska.net (209.193.62.49)  108.083 ms

14  * * *

15  * * *

16  * * *

...and it continued to produce nothing until I killed the command.

[Andrea B.]

Now I can access both U. of A. sites. Too crazy !!

 

I must stop for tonight. The commands are best run with firewall off, and I don't like to have it turned off for too long.

 

I hope things clear up. Intermittent hangs can be quite frustrating.

[otoien]

Hi Andrea,  Thanks so much for your efforts and happy new year! During these problems I have not been on the University of Alaska network, but on my local provider's (GCI's) network. However after my last message, there has not been any problem with UVP, so I have not been able to test for problems. We have had power outs due to ice storms and loads of snow (but not myself or UAF this time) and unpassable roads, so if there have been server problems at UAF it is not surprising that no-one were able to get in to fix it. Many roads were cleared yesterday, so that could have improved situation at UAF. My own connection to the outside world has otherwise worked fine, with the exception that there was a similar hang-up at Nikongear a few hours ago when I tried to make a post. Strangely the hung-ups seem to be on an unsecure connection even if the site I try to connect to is  secure. So the problem might be one of these services that are one the way to the server one try to connect to. There is the Log4j vulnerability that might be tried exposited by hackers these days; perhaps hang-ups could be due to some kind of DoS attacks on these intermediate network services.

[otoien]

Then the problems started to appear again both with UVP and NG shortly after my last post . In both cases it happened when trying to post. It seems to be stuck on "Waiting for ssl/goggleanalytics.com". For NG while stuck on completing a post I could still connect to the site and display different threads. But for UVP there seems to be more use of these intermediate services, as I also had problems connecting to the site. I also was stuck on "Waiting for Logx/optimizely.com".

When stuck UVP shows an unsecure heading.

 

But when it successfully connects it shows

 

Again, I am not so sure that this has anything to do either with my local network or that of the UVP server itself. The intermittent nature of it makes it hard to test.

 

[Andrea B.]

Thank you for this information. I'm not completely sure what it means, but I'll look into it.

 

 

[otoien]

Now that I got into problem mode again, I was experimenting with the VPN client to the UAF network. This time I was able to show that problems only happened when connected though my local provider, not though the UAF network. The university network connects though different paths than GCI. However even when I had problems connecting to UVP, I could ping the server, and pinging connectivity to the server was good in both cases:

Quote

:

Pinging ultravioletphotography.com [143.95.108.235] with 32 bytes of data:
Reply from 143.95.108.235: bytes=32 time=106ms TTL=48
Reply from 143.95.108.235: bytes=32 time=100ms TTL=48
Reply from 143.95.108.235: bytes=32 time=100ms TTL=48
Reply from 143.95.108.235: bytes=32 time=100ms TTL=48

Ping statistics for 143.95.108.235:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 100ms, Maximum = 106ms, Average = 101ms

 

Quote

Pinging ultravioletphotography.com [143.95.108.235] with 32 bytes of data:
Reply from 143.95.108.235: bytes=32 time=102ms TTL=48
Reply from 143.95.108.235: bytes=32 time=100ms TTL=48
Reply from 143.95.108.235: bytes=32 time=99ms TTL=48
Reply from 143.95.108.235: bytes=32 time=101ms TTL=48

Ping statistics for 143.95.108.235:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 99ms, Maximum = 102ms, Average = 100ms

 

[Andrea B.]

You can get a browser extension or add-on which blocks Google Analytics.

Check your browsers home page to find out more.

[Andrea B.]

In response to pinging the UVP server:  our host server has not had any recent problems. So yes, your ping worked. "-)

 

 

[Andrea B.]

I am *not* using Optimizely.com. So I don't really know where that is coming from. Would GCI use it perhaps?

[otoien]

That is quite possible. I tried blocking googleanalytics.com (see url for instruction below) and that wait message goes away, but it does not connect unless I am on the UAF VPN client. So there might be something else in between not showing and responding. My guess is that the logging performed by these kind of services are the ones targeted with respect to the Log4j vulnerability. I think next step is to contact GCI technical support since the problem seems to be somewhere in that path.

Quote

https://www.infopackets.com/news/9959/how-fix-disable-google-analytics-firefox-chrome-ie

 

[otoien]

Strangely I discovered that connecting with an incognito window on the GCI network worked, but not with a standard window. I checked the cookies and noticed that the incognito window did not have the cookie that starts with www. So I deleted that from the standard window, and so far (..... ) I can connect. 

 

[Andrea B.]

Øyvind, is that our cookie you are referring to?

 

[otoien]

Yes, it is the allowed Chrome cookies for the UVP site.  It was the second one below that was missing in the incognito window, and I deleted both of them. They were re-created after logging in again. I have not encountered any problems after this.

 

(Right click the lock icon and select cookies to get to this)