search

jMonkeyEngine / jmonkeyengine-website

jmonkeyengine.org website
https://jmonkeyengine.org
BSD 3-Clause "New" or "Revised" License
25 stars 6 forks source link

Unresponsiveness issue #25

Closed pavly-gerges closed 4 months ago

pavly-gerges commented 1 year ago

I have been experiencing an issue loading jmonkeyengine.org and its domains (the wiki and the community hub) for some days.

The ping test shows 0 received packets, the ping test is conducted on both my desktop Linux machine and my android device on wlan and cellular network:

┌─[✗]─[pavl-machine@pavl-machine]─[~]
└──╼ $ping hub.jmonkeyengine.org
PING hub.jmonkeyengine.org (104.21.87.39) 56(84) bytes of data.
^C
--- hub.jmonkeyengine.org ping statistics ---
289 packets transmitted, 0 received, 100% packet loss, time 294904ms

This is the javascript error log:

image

riccardobl commented 1 year ago

Mhh, weird, can you try to run traceroute hub.jmonkeyengine.org ? The IP in your log is correct and belongs to cloudflare and appears to be online from here

PING 104.21.87.39 (104.21.87.39) 56(84) bytes of data.
64 bytes from 104.21.87.39: icmp_seq=1 ttl=58 time=19.1 ms

I've checked the cloudflare status page but it seems there isn't anything relevant there.

pavly-gerges commented 1 year ago

Here is a traceroute, I suspect this is a timeout issue: 

┌─[✗]─[pavl-machine@pavl-machine]─[~]
└──╼ $sudo traceroute -dIT -4 jmonkeyengine.org
[sudo] password for pavl-machine: 
traceroute to jmonkeyengine.org (172.67.140.141), 30 hops max, 60 byte packets
 1  home (192.168.1.1)  1.489 ms  1.500 ms  2.247 ms
 2  100.89.0.1 (100.89.0.1)  4.771 ms  5.977 ms  5.964 ms
 3  10.45.16.124 (10.45.16.124)  7.037 ms  6.920 ms  7.014 ms
 4  10.38.83.226 (10.38.83.226)  6.002 ms * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
MeFisto94 commented 1 year ago

Without knowing the exact devices in your (or your providers) infrastructure, it seems that the packets are never leaving private infrastructure (as denoted by the 10.X and 192.168.X) IP spaces. I guess 100.89.0.1 is some router, but then some firewall seems to block all connectivity, but that's hard to tell for us.

You can try to traceroute other services, such as google, and compare the route they take.

pavly-gerges commented 1 year ago

You can try to traceroute other services, such as google, and compare the route they take.

I tried and it works fine.

┌─[pavl-machine@pavl-machine]─[~]
└──╼ $traceroute github.com
traceroute to github.com (140.82.121.3), 30 hops max, 60 byte packets
 1  home (192.168.1.1)  1.276 ms  1.473 ms  3.350 ms
 2  100.89.0.1 (100.89.0.1)  5.141 ms  5.199 ms  5.324 ms
 3  10.45.16.126 (10.45.16.126)  5.737 ms 10.45.16.124 (10.45.16.124)  9.031 ms 10.45.16.126 (10.45.16.126)  8.249 ms
 4  10.38.83.226 (10.38.83.226)  8.566 ms *  8.533 ms
 5  * 60-60-60-42.rev.home.ne.jp (60.60.60.42)  14.453 ms *
 6  * * *
 7  ae21.cr2-fra6.ip4.gtt.net (213.200.116.225)  113.500 ms  82.156 ms *
 8  * * *
 9  * * *
10  * * *
MeFisto94 commented 1 year ago

So, whatever 10.38.83.226 is, it's blocking your access further. It's a bit weird you said that a VPN doesn't help, because I'd have expected it to do so. Can you maybe try again and ensure it's used for that connection? (should also show in traceroute).

But then, you said cellular network also has this problem, very weird.

riccardobl commented 1 year ago

Mhh you are in Egypt, right? If that's the case, then image and https://community.cloudflare.com/t/problem-with-cloudflare-ip-for-my-domain/502063

Either an issue on their side or the government or some big provider banning some of their ips by mistake, i suppose.

We can figure out a workaround i suppose, or disable cloudflare for the time being. Do you know how long it has been this way? I mean, are we talking about 24-48 hours or more a week?

pavly-gerges commented 1 year ago

Mhh you are in Egypt, right?

Yep.

Either an issue on their side or the government or some big provider banning some of their ips by mistake, i suppose.

I am a commuter student, and last week, the jMonkeyEngine website domains were working fine, but they became slow to load over the last month (taking a lot of time to respond), once responded, chrome caches it and everything runs just fine.

This week, I am back home and using my home gateway the 192.168.1.1 and it's not working, however, it was working fine before 5 months or so, I tried cellular network and the issue persists.

I have tried with a VPN directed to the United States, I am not experiencing the timeout error but it keeps loading in a busy loop, maybe we could try further on this.

pavly-gerges commented 1 year ago

Can you maybe try again and ensure it's used for that connection? (should also show in traceroute).

I used the hola-vpn website vpn for this as a fast vpn test, however, if we want to investigate further into this, I could try to prepare an open-vpn configuration to test this.

riccardobl commented 1 year ago

I've disabled cloudflare for https://jmonkeyengine.org https://wiki.jmonkeyengine.org and https://javadoc.jmonkeyengine.org

You can see if they work for you now.

Regarding the hub, i will look into a workaround tomorrow, since we need cloudflare there, contrary to the other domains that had cloudflare enabled only to provide https from a long time ago when gh pages didn't support it for custom domains.

riccardobl commented 1 year ago

I used the hola-vpn website vpn for this as a fast vpn test, however, if we want to investigate further into this, I could try to prepare an open-vpn configuration to test this.

You can try the free tier of protonvpn, actually, if you are familiar with docker you can get the ovpn file from protonvpn and run

USER="user"
PASS="XXXXXX"
docker run --name protonvpn -dit --restart=always --device=/dev/net/tun --cap-add=NET_ADMIN \
    -v /srv/protonvpn:/vpn:ro -e OPENVPN_CONFIG=/vpn/vpn.ovpn \
    -p 1080:1080 \
    -e SOCKS5_USER="${USER}" \
    -e SOCKS5_PASS="${PASS}" \
    ghcr.io/riccardobl/docker-openvpn-socks5:master

this is a container that runs openvpn and exposes it as a local socks5 proxy that you can use with a pattern that enables it only for certain websites, in addons like foxyproxy for firefox

pavly-gerges commented 1 year ago

I've disabled cloudflare for https://jmonkeyengine.org https://wiki.jmonkeyengine.org and https://javadoc.jmonkeyengine.org

Yes, running fine now, thank you.

Regarding the hub, i will look into a workaround tomorrow, since we need cloudflare there, contrary to the other domains that had cloudflare enabled only to provide https from a long time ago when gh pages didn't support it for custom domains.

Let me know in case you need to test something.

pavly-gerges commented 1 year ago

I found this: https://community.cloudflare.com/t/ip-range-188-114-97-not-serving-in-egypt/420677/33

It seems the problem is with the ISP in Egypt in general as @MeFisto94 suspected, some users report changing their local DNS that is automatically assigned for the cloudflare reolves the problem, but can we do this via a script or something?

riccardobl commented 1 year ago

I found this: https://community.cloudflare.com/t/ip-range-188-114-97-not-serving-in-egypt/420677/33

It seems the problem is with the ISP in Egypt in general as @MeFisto94 suspected, some users report changing their local DNS that is automatically assigned for the cloudflare reolves the problem, but can we do this via a script or something?

Can you ping other cloudflare ips eg. 172.67.133.56 ?

pavly-gerges commented 1 year ago

I will try.

riccardobl commented 1 year ago

I've deployed a reverse proxy as possible workaround, you can try it here and see if it works https://hub.eg.jmonkeyengine.org https://eg.jmonkeyengine.org https://wiki.eg.jmonkeyengine.org basically, if you are from egypt, replacing jmonkeyengine.org with .eg.jmonkeyengine.org on any of our domains will route the traffic through the reverse proxy. If it works i will add an automatic redirect for egyptian IPs.

pavly-gerges commented 1 year ago

I've deployed a reverse proxy as possible workaround, you can try it here and see if it works https://hub.eg.jmonkeyengine.org https://eg.jmonkeyengine.org https://wiki.eg.jmonkeyengine.org basically, if you are from egypt, replacing jmonkeyengine.org with .eg.jmonkeyengine.org on any of our domains will route the traffic through the reverse proxy. If it works i will add an automatic redirect for egyptian IPs.

It works fine thanks😀, but trying to resign in with different account seems to be redirecting the page again to the original blocked domain.

riccardobl commented 1 year ago

Mhh i suppose you are logging in with google, facebook or github.. they redirect back to the original (blocked) domain so that's why, i don't know if i can work around that, i will look into it. For now you can add this line to your /etc/hosts (on linux) 78.46.197.35 hub.jmonkeyengine.org this will resolve the domain to our server and bypass cf entirely

pavly-gerges commented 1 year ago

For now you can add this line to your /etc/hosts (on linux) 78.46.197.35 hub.jmonkeyengine.org this will resolve the domain to our server and bypass cf entirely

Perfect!

This is a traceroute test with 78.46.197.35 hub.jmonkeyengine.org (in case this may help), this is my gateway 11.0.0.1, I am back to the University site:

┌─[pavl-machine@pavl-machine]─[~]
└──╼ $sudo traceroute -I -4 hub.jmonkeyengine.org
traceroute to hub.jmonkeyengine.org (78.46.197.35), 30 hops max, 60 byte packets
 1  11.0.0.1 (11.0.0.1)  8.136 ms  8.112 ms  8.105 ms
 2  192.168.240.1 (192.168.240.1)  8.097 ms  8.090 ms  10.688 ms
 3  172.17.63.13 (172.17.63.13)  10.681 ms  10.675 ms  10.668 ms
 4  10.39.52.210 (10.39.52.210)  10.794 ms  10.788 ms  10.781 ms
 5  10.39.212.165 (10.39.212.165)  10.640 ms  10.633 ms  10.998 ms
 6  10.39.11.237 (10.39.11.237)  12.851 ms  7.465 ms  10.110 ms
 7  10.39.15.209 (10.39.15.209)  10.088 ms  10.071 ms  10.055 ms
 8  10.39.16.61 (10.39.16.61)  11.463 ms  11.399 ms  11.377 ms
 9  et-1-0-25.cr5-mil3.ip4.gtt.net (212.222.6.229)  133.178 ms  133.162 ms  133.146 ms
10  ae10.cr6-fra2.ip4.gtt.net (141.136.107.233)  133.128 ms  133.111 ms  133.093 ms
11  ip4.gtt.net (154.14.78.154)  133.073 ms  133.056 ms  102.102 ms
12  core24.fsn1.hetzner.com (213.239.224.85)  102.063 ms  102.054 ms  102.046 ms
13  spine3.cloud2.fsn1.hetzner.com (213.239.239.134)  102.038 ms  151.954 ms  151.899 ms
14  et-1-16.rs3k5.rz4.hetzner.de (213.239.239.38)  151.876 ms  95.910 ms  95.880 ms
15  * * *
16  20244.your-cloud.host (159.69.99.61)  96.671 ms  96.665 ms  96.659 ms
17  hub.jmonkeyengine.org (78.46.197.35)  95.832 ms  95.825 ms *
pavly-gerges commented 1 year ago

I've deployed a reverse proxy as possible workaround, you can try it here and see if it works https://hub.eg.jmonkeyengine.org

I am getting this exception when trying to log in: 

Wrapper.mjs:206 Uncaught (in promise) DOMException: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing.
    at https://hub.jmonkeyengine.org/javascripts/workbox/workbox-core.prod.js:1:3581
    at new Promise (<anonymous>)
    at x.transaction (https://hub.jmonkeyengine.org/javascripts/workbox/workbox-core.prod.js:1:3546)
    at async x.u (https://hub.jmonkeyengine.org/javascripts/workbox/workbox-core.prod.js:1:3700)
    at async x.put (https://hub.jmonkeyengine.org/javascripts/workbox/workbox-core.prod.js:1:4133)
    at async o.setTimestamp (https://hub.jmonkeyengine.org/javascripts/workbox/workbox-expiration.prod.js:1:562)
    at async u.updateTimestamp (https://hub.jmonkeyengine.org/javascripts/workbox/workbox-expiration.prod.js:1:1532)
    at async Object.cacheDidUpdate (https://hub.jmonkeyengine.org/javascripts/workbox/workbox-expiration.prod.js:1:2563)
    at async Object.put (https://hub.jmonkeyengine.org/javascripts/workbox/workbox-core.prod.js:1:2191)
(

image

riccardobl commented 1 year ago

My guess is that you are using the .eg domain and the /etc/hosts workaround together, correct? You should use the regular https://hub.jmonkeyengine.org/ instead of the .eg domain when using the /etc/hosts workaround. Do you confirm that if you use https://hub.jmonkeyengine.org it works as expected or are we looking at another problem?

I am considering the various options here, but it seems we can either

pavly-gerges commented 1 year ago

My guess is that you are using the .eg domain and the /etc/hosts workaround together, correct?

Yes, as a matter of testing the workaround.

  • Tell them to add the /etc/hosts line if they are affected. This is obviously bad UX, but supposedly this issues is affecting a lot of sites and they will unban the ip range eventually (i hope).

The domain ip workaround on the /etc/hosts works fully normally on hub.jmonkeyengine.org and it seems that Chrome also caches it for my phone, too, so now I can use hub.jmonkeyengine.org on my laptop and my phone.

I am considering the various options here, but it seems we can either

I have a good idea that may fix our problem, we can use something like a middle-server that resides between the cf and the client side, the server is any Linux server with the addition of 78.46.197.35 hub.jmonkeyengine.org at /etc/hosts, I don't know if this even possible, but I think GitHub-Pages may help you, it's eventually a Linux server and it will eventually provide a universal solution for the problem if of course the 78.46.197.35 hub.jmonkeyengine.org works across the globe.

riccardobl commented 1 year ago

That would be pretty much like disabling cloudflare for the hub and it would essentially route all traffic through a single European server. While this approach will work, it would mean that all of the heaviest content would be served from that server, rather than from the edge servers closer to the user, as is the case with Cloudflare. My approach was to selectively implement this only for users whose ISPs block Cloudflare IPs.

pavly-gerges commented 1 year ago

My approach was to selectively implement this only for users whose ISPs block Cloudflare IPs.

For me, it works fine, you can add a note for blocked users here on the repo of the jMonkeyEngine hub domain, the note should also cover Windows users.

Btw, there are a lot of other ways that are browser-based to add host IPs, including this Chrome extension.

riccardobl commented 1 year ago

Btw, there are a lot of other ways that are browser-based to add host IPs, including this Chrome extension.

Mh i am not entirely sure this would work for our use case, see this part from the extension page:

Issues

After the redirect, the user is effectively in a different domain that the one they expected. They may notice some functional differences:

  • depending on the server, parts of a web page referring to the site URL (like href and src attributes) could be different from the original
  • window.location has a different value that can potentially throw off JavaScript snippets
  • most Cross-Origin request won't work
riccardobl commented 1 year ago

It seems cloudflare cycled the ip, and the new one doesn't seem to be blocked by egypt image

pavly-gerges commented 1 year ago

I am still getting cuts at some points, it seems this service is not stable here in Egypt: 

└──╼ $traceroute hub.jmonkeyengine.org
traceroute to hub.jmonkeyengine.org (188.114.97.6), 30 hops max, 60 byte packets
 1  11.0.0.1 (11.0.0.1)  27.216 ms  29.832 ms  31.558 ms
 2  192.168.240.1 (192.168.240.1)  31.757 ms  31.706 ms  31.659 ms
 3  172.17.63.13 (172.17.63.13)  34.864 ms  34.819 ms  34.772 ms
 4  10.39.52.210 (10.39.52.210)  34.436 ms  34.392 ms  34.347 ms
 5  10.39.212.161 (10.39.212.161)  34.579 ms 10.39.12.106 (10.39.12.106)  34.495 ms 10.39.212.161 (10.39.212.161)  34.432 ms
 6  10.39.11.237 (10.39.11.237)  34.381 ms  45.680 ms  32.617 ms
 7  10.39.16.9 (10.39.16.9)  35.113 ms 10.39.15.253 (10.39.15.253)  35.090 ms 10.39.16.5 (10.39.16.5)  35.068 ms
 8  10.29.8.2 (10.29.8.2)  35.047 ms 10.29.7.194 (10.29.7.194)  38.543 ms *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
pavly-gerges commented 4 months ago

This issue has been resolved for a while now, it seems to be government/Cloudflare issues.