New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
With Globalping at least it will just timeout:
(Onidel blocks outgoing 22 by default)
I don't think there are many ways for Globalping to know if the port is blocked internally by the VM or by some country firewall, which defeats one of the main purposes of a probe network
That's why I'd rather cancel all my servers with justhost before dropping port 22 or stopping my probes.
@jimaek Are there any tests Globalping does to determine if a probe should be considered eligible for use to connect to a specific port? Could you perhaps add a feature that would allow probes to send back a list of ports it can or cannot connect to, similarly to the way a Tor exit policy works?
Oh nevermind, they use AbuseIPDB right now, auto suspend for any bogus report, very cool!
what a shitshow 😂
That's bad. There are some services that incorrectly auto-flag Tor middle relays, e.g. xmission.
That account should be banned from AbuseIPDB, gotta say.
I'm actually in correspondence with their support. They said a few weeks ago (after a short back-and-forth where they kept assuring me that they do not own the abuseipdb.com domain before realizing what I was talking about and confirming that they owned the xmission account there) that they would escalate the matter to see what could be done. I just sent a follow-up now requesting an update.
At the very least, I hope for them to whitelist relays' address:ORPort tuple and not report them. I have some hope because they are a very pro-privacy ISP in Utah, and they aren't so massive that support is
/dev/null.Belgrade Location?
We have no special logic related to ports. We pass the port directly to the utility to run the test and return the results as is.
So if a probe has to disable, say, port 22, that's bad for the network due to the skewed results?
Technically yes but I don't like the alternative of port scanning. Our quality control focuses more on packet loss rather than port availability
Not scanning, but allowing probes to voluntarily provide a whitelist or blacklist of their abilities via the API. So for example, zGato's probes could return that they don't support TCP/22, and then any requests to connect to TCP/22 simply wouldn't be routed to any of his probes.
It might even be feasible client-side by having the probe return a refusal over the API rather than return false results (like a connection timeout). Essentially telling the API "I'm alive and I received the request, but I can't satisfy it".
I understand, yes that sounds doable, I'll add it to the backlog
@antonpa I'm receiving more false abuse complaints. This time three duplicates for a single incorrect AbuseIPDB entry (somehow your system is triple-reporting the same report). Looking at it again, it's another false positive to port 9001 (Tor).
Please be aware that anyone can create an AbuseIPDB entry. It is not authoritative.