Blocking nodes/marking as connected to specific nodes

Hi,

I’m part of a complex multimode network which includes a number of AllStar nodes. While we haven’t had any issues so far, it’s currently possible to create loops between these nodes, becayse they’re permanently connected by means other than AllStar (for technical reasons).

Does anyone know of a way of blocking connections between these nodes, or better yet, telling the AllStar network they they are (effectively) connected to each other, to avoid or at least reduce the possibility of accidentally creating loops?

Remember that as far as the AllStar network is concerned, the nodes don’t appeared to be connected to each other, the means used is outside the AllStar (or Echolink) network.

The quick answer is yes you can block nodes by number or allow only specific nodes.
See Black List and White List.

If you are using ASL 1.01 or 2 beta 6,
The loopback protection is built-in. It will block a connection anywhere in the chain of connected nodes.
So, for instance, I have already connected the WAN system to my node and I attempt to connect to you, where you already have the WAN connected, The connection will be refused.
This is performed by ‘NODE NUMBER’ checking and includes all nodes in any chain of connection(s).

With the above-mentioned versions, it also blocks 'private nodes as well in loopback protection and is why I advise to not use the example 1999 private node number to avoid some hair pulling troubleshooting as to why you can not connect to node x which if you buddy across the street.

Now the question comes that I can not answer is that what happens when one of them is a hamvoip node. Well I can’t answer that one. Theory tells me that it should block as well as the connected nodes list should propagate the same but I do not know that.

Hopefully, now you have a better understanding to better make a decision on what to do.

On 15/7/22 1:21 pm, Mike via AllStarLink Discussion Groups wrote:

[Mike] Mike
July 15

The quick answer is yes you can block nodes by number or allow only specific nodes.
See Black List and White List.

That’s an option, but does it handle connections made via intermediate nodes? At worst, it will at least prevent some sort of oopses. :slight_smile: I’m not anticipating malicious actors, but it’s easy for someone to make an innocent mistake. Time to read the wiki methinks :slight_smile:

If you are using ASL 1.01 or 2 beta 6,
The loopback protection is built-in. It will block a connection anywhere in the chain of connected nodes.
So, for instance, I have already connected the WAN system to my node and I attempt to connect to you, where you already have the WAN connected, The connection will be refused.
This is performed by NODE NUMBER checking and includes all nodes in any chain of connection(s).

As I explained in my original email, the connections between these specific nodes are not made using AllStar (they are actually interlinked via fixed USRP links). I went to pains to point out that the existing links between nodes was not via AllStar, so node number based loop protection wouldn’t work, unless there was a way for me to tell my node what it’s connected to manually, so it can report to the network, and the loop protection will take those “hidden links” into account.

The network architecture is unique (AFAIK), but there’s other networks what have AllStar nodes interlinked using DMR or some other protocol, which could have similar issues. I haven’t had any issues so far, but I’m just looking at making the system more foolproof, just in case.

There are technical reasons why this architecture is used, it’s to optimise interlinks between multiple modes, not just AllStar, for both voice and (DV mode) metadata. These links are intended to be as permanent as hard wired links.

With the above-mentioned versions, it also blocks 'private nodes as well in loopback protection and is why I advise to not use the example 1999 private node number to avoid some hair pulling troubleshooting as to why you can not connect to node x which if you buddy across the street.

Now the question comes that I can not answer is that what happens when one of them is a hamvoip node. Well I cant answer that one. Theory tells me that it should block as well as the connected nodes list should propagate the same but I do not know that.

Hopefully, now you have a better understanding to better make a decision on what to do.

It’s as I thought. And I’d like to be able to manually insert connection information (and having that show online isn’t a bad thing, if that happens as a side effect). . Anyway, all of the interconnected modes are ASL, running on x86_64 virtual servers in data centres.

3 posts were split to a new topic: Echolink node blocking