Lots of hosts do not respond for my internet connection
meeuw opened this issue · comments
Hi,
Thanks for this list, this is going to be super useful for my little project to find out what port ranges are used for cgnat!
I noticed that I don't get any response for lots of hosts in the hourly updated valid_ipv4s.txt using my own script pystun, I tried to validate this by running "run.sh" on Fedora 35 but that's even worse (all hosts seem to fail):
OK 0 , DNS failure 78 , p/Timeout 0 , Timeout 508 , Incorrect 47
I guess there could be a difference in connectivity depending on the Internet connection, it would also be very helpful if the capabilities of the stun servers are available.
Hi @meeuw, thanks for opening the issue. I just ran your script against all valid_ipv4s.txt and virtually all hosts responded correctly.
It seems to me that your firewall/network provider might be blocking UDP traffic. Could you check if this is the case?
Thank you for your reply (as well as the suggestions for pystun).
I've ran your modified script on my internet connection and from an EC2 instance (VPS on AWS) and about 15 hosts don't respond, maybe I'm geo blocked? Anway, many hosts do respond, I might have too high expectations from "always online", it's still very useful.
@meeuw All right, thanks for confirming.
15 unresponsive hosts seem quite high (I get 2-3 when I run your script locally running on a WiFi and behind a CG-NAT) so it might be the case that some of the listed providers block AWS/Azure/GCP IP ranges.
However, I take your point that you expect all hosts from the list to respond. Unfortunately, most of these STUN servers aren't ran with any uptime or quality of service guarantees, so some can always be down even if they were operational at the hourly check time.
One idea that springs to mind would be to use the past checks (e.g. in a "sliding-window" fashion) to find the most reliable services, and publish them in a separate list. It should be fairly straightforward as each check is recorded as a separate commit, and there is a few months' worth of data now in the repository.
If I were to implement this, would you be able to re-run your script in a few different environments to see if there is any improvement?
If I were to implement this, would you be able to re-run your script in a few different environments to see if there is any improvement?
Sorry for the delay, yes most definitely!
Like I said, maybe I'm geoblocked, I haven't thoroughly checked but it seemed the same hosts were not responding everytime I tried.
This is the list ATM, will try again tomorrow:
Response from 13.250.110.196:3478 -> Timeout or other error
Response from 18.141.235.117:3478 -> Timeout or other error
Response from 23.21.199.62:3478 -> Timeout or other error
Response from 31.13.72.3:3478 -> Timeout or other error
Response from 62.157.116.5:3478 -> Timeout or other error
Response from 66.228.54.23:3478 -> Timeout or other error
Response from 78.111.79.151:3478 -> Timeout or other error
Response from 83.64.250.246:3478 -> Timeout or other error
Response from 88.198.151.128:3478 -> Timeout or other error
Response from 106.55.202.232:3478 -> Timeout or other error
Response from 109.224.232.102:3478 -> Timeout or other error
Response from 124.64.206.224:8800 -> Timeout or other error
Response from 178.63.107.149:3478 -> Timeout or other error
Response from 188.64.120.28:3478 -> Timeout or other error
Response from 212.211.179.42:3478 -> Timeout or other error
Response from 213.157.4.53:3478 -> Timeout or other error
Response from 217.119.210.45:3478 -> Timeout or other error
List as of today, looks familiar:
Response from 13.250.110.196:3478 -> Timeout or other error
Response from 18.141.235.117:3478 -> Timeout or other error
Response from 23.21.199.62:3478 -> Timeout or other error
Response from 31.13.72.3:3478 -> Timeout or other error
Response from 62.157.116.5:3478 -> Timeout or other error
Response from 66.228.54.23:3478 -> Timeout or other error
Response from 78.111.79.151:3478 -> Timeout or other error
Response from 83.64.250.246:3478 -> Timeout or other error
Response from 88.198.151.128:3478 -> Timeout or other error
Response from 124.64.206.224:8800 -> Timeout or other error
Response from 178.63.107.149:3478 -> Timeout or other error
Response from 188.64.120.28:3478 -> Timeout or other error
Response from 212.211.179.42:3478 -> Timeout or other error
Response from 213.157.4.53:3478 -> Timeout or other error
Response from 217.119.210.45:3478 -> Timeout or other error
Thanks for this. It's indeed very strange that these hosts don't work for you repeatedly. I'll take a look into this next week
@meeuw Wait, how do you actually check if they are "unavailable"? Do you "ping" them? Because as by my tests, all of those don't respond to "ping" / ICMP requests -> timeout, while they work very well when "treated right": via https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
For example:
Hi @kyr0 ! I'm using the script linked in this issue:
https://gist.github.com/meeuw/d25665c2ab8d68ecee7bd65a71ed365b