Ear bot still trying to connect to server after blocking SF explorer.jamulus.io

[rdica]

@mcfnord Per your suggestion here:
https://github.com/orgs/jamulussoftware/discussions/3163#discussioncomment-6858979
I started blocking that explorer instance the following day. This was two weeks ago.
After last night's session I was examining my firewall and found your Ear was still trying to connect.

Chain INPUT (policy ACCEPT 18M packets, 2094M bytes)
 pkts bytes target     prot opt in     out     source               destination         
24800 4763K DROP       udp  --  ens3   *       159.89.140.136       0.0.0.0/0            udp dpt:22124 /* Jamulus live Ear */

If my servers are no longer visible to your site, why would your bot still be trying to connect since there's no server to display hence no need to join and record?

[mcfnord]

Would you say this only happened in the last 15 hours? 15 hours ago there was some kind of storm at peak (happens once a month or so), and I switched to Tony's original servers.php instance. This is the failover scenario I mentioned. I just tried switching back, but the degradation may be ongoing, so I'm still using jamulus.softins.co.uk.

To complicate things, one directory is still using the SF instance, because Tony's instance was struggling with it.

A virtual IP wouldn't fix this because the servers.php instances would still identify by their outbound static IPs.

If you also block the second IP address, you'd still appear using the third one on Jamulus Explorer's drop-down. I believe the third one is the AWS instance. That's not a great answer, because these service degradations apply equally to Jamulus Explorer, but it might work for now.

[rdica]

Yes, that time frame seems to match the occurrence, thanks for the explanation.

While blocking more explorer.jamulus.io instances may solve an issue temporarily, reducing visibility on explorer.jamulus.io is not a viable long term solution in order to be invisible to jamulus live.

I submit you should supply a means to be removed from the live site without having to also block another site not pertinent to yours. It appears your data collection method has issues, and reliance on it to make a server invisible to the live site and bot activity could be better served by utilizing a blacklist of IPs.
A blacklist you maintain based on verifiable operator submitted IPs can be utilized by all your bots and website, and any additional features you wish to implement. You could even have that blacklist available via git and propose forks/PRs for additions, as one means of verification for those inclined to use git.
I would be more than willing to help you test the blacklist.
None of this would impact the per-individual features you'd like to implement, or utilization of server welcome message metadata (where servers are not in the blacklist).

That way issues that interfere with your data collection from the directories won't impact continued invisibility on your live site, cause your bots to join servers they're not wanted on, nor will it reduce visibility on explorer.jamulus.io.

Total win-win for everybody.

[ann0see]

@rdica the source of jamulus.live is available even though without clear license. So If @mcfnord is ok with it, you can both work on a solution on the repo of the site.

[mcfnord]

I use git all day and night, but don't you see an authentication problem using it as you've described? I'm not a big fan of welcome message metadata, but it has that one inherent advantage of being the operator's authentic settings. How do "verifiable operator submitted IPs" work in your plan? How do I verify them?

I maintain a blocklist of servers at https://jamulus.live/cannot-dock.txt. This stops both bots from visiting. I also publish IP addresses a firewall can block to stop both bots. Add the per-user granularity features I've already implemented, and I'm not sure I understand what the fuss is about. Not about bots. If a server reported a block bots checkbox off client instances, we'd again solve that pesky authentication problem, at a per-individual level, and I'd get to throw some code away and do less "verifying".

I am pleased to hear IP-blocking the servers.php instance worked. To be completely unlisted from my website, use IP blocking. If bleedover into Tony's website is a serious issue, run an instance of servers.php. I've already invited to help you set it up. Then convince Tony to default to it in the dropdown. When I started running an instance, I was surprised that he put it in his dropdown. I guess it makes sense. If you ran an instance, he'd certainly add yours, and you could also prevent my main server from reaching it.

But the real fix here is fixing this particular bug in servers.php. Or re-implementing it by extending gojam. That would be huge. It would detect levels and mute states. Almost revolutionary!

[rdica]

Closing, no longer required.