Is there a way of blocking nodes via DTMF over RF? We have nodes that get connected, then also connect to hubs that end up flooding our repeater. We invite visitors, but we can’t handle the whole world invited by an individual playing with indiscriminate connects, or that connect without disconnecting when finished. Thanks,
Bob
K6ECM
Yes, there are 3 ways:
First, with inxlat. See Rpt.conf - AllStarLink Wiki
For example a default inxlat would look like inxlat= *,#,0123456789ABCD
You could change it to something like inxlat= *543,#,0123456789ABCD
In that case a user would have to use *543 prefix rather than just a * prefix for any command.
Secondly, you could use [controlstates] to disable user functions. See Rpt.conf - AllStarLink Wiki
Specifically ufdis (user functions disable) Rpt.conf - AllStarLink Wiki
The final alternative would be cop,18 Rpt.conf - AllStarLink Wiki
The above answers assume you have bad actors on your repeater playing DTMF. If inbound links are the problem you could do a whitelist or blacklist. See Blacklist or whitelist - AllStarLink Wiki
Or you could use the controlstates or cop commands to disable linking.
1 Like
Thanks, I’ll give it a go.
Bob
I’m not clear on how any of the suggested solutions would prevent the initially described scenario:
We have nodes that get connected, then also connect to hubs that end up flooding our repeater.
If I’ve understood correctly it sounds as though the OP still wants to allow inbound connections, but not if those inbound connections come with baggage, e.g. @Bob_Pyke wants to allow my node to connect to his repeater unless I’m also connected (directly or indirectly) to X other nodes. It’s a very good question indeed.
1 Like
I wasn’t sure what he wanted but I think if you carefully review my post I think you see I addressed the concern you mentioned, specifically the black/white list capability.
Bob, here is a suggestion… not only for you but all Allstar users
NR9V (David) created the Allscan function for us to use. In his program is the ability to monitor favorite/listed nodes etc. His listing includes the monitored nodes connection status and shows the number of active connections attached to any listed node. Since all that connection information is available from the Allstar Status site. There is no reason a script can’t be created to trap incoming calls and check if they are dragging other connected nodes with them prior to allowing a connect.
Since David NR9V is excellent at what he does. If contacted, he already has the connection check function working in Allscan , He might assist you/everyone with a script to check for existing connections prior to allowing the actual connections.
That is one of the great things about Asterisk… It’s So flexible.
Larry - N7FM
1 Like
Thanks for the mention Larry, Asterisk could indeed call a script and do conditional checks eg. “if connect request, run local script (to get count of nodes connected to a node), and only allow connection if that count is < X.” So that is one question: How can the rpt.conf file (or some other file) be set up to make inbound connect requests conditional on a script return value? Alternatively the blacklist/whitelist configuration Tim linked to looks like it has some ability to do logic/function macros (eg. “GotoIf()”), which might allow a script to be called to check the stats link count and consider any node with a linkedNodes count > X as blacklisted. The script to then get the node’s ASL stats linkedNodes count is simple, though due to current ASL stats API limitations this would show only the count of nodes directly connected to that node, which is not much help if some other indirectly connected node then has 100 other connected nodes. Thus a significant number of API calls could be required and the script could take awhile (minutes) to parse the full network graph of all connected nodes.
The script would also need to periodically recheck the connected node count of each connected node, as checking only on initial connect would not be helpful if a user later connected to a bunch of other nodes. Sure you can manually blacklist a user when that happens but that is not a general solution. Thus this gets to a fundamental issue where repeater owners/admins have to constantly monitor their systems to manually prevent these issues. There is no perfect solution because there are many use cases and legitimate cases eg. where a user has a few friends connected to their node and then connects to a repeater. But with adequate data and some basic logic probably 98% of the not-legitimate cases could be prevented, with no manual intervention required.
Thus by parsing the network graph of each connected node, not only during a connect but periodically also when a node or its connected nodes key up or every few minutes, then some common sense limits can be defined, whereby if the total number of connected nodes associated with a node was > X then disconnect the node.
The “All reporting nodes” ASL Stats API (https://stats.allstarlink.org/api/stats/) returns connected link data for all nodes - but this does not provide the connected node count or node#s, unlike the “Individual reporting node” API (eg. https://stats.allstarlink.org/api/stats/2021) which provides all directly connected node#s for a specific node (but no data on indirectly connected nodes). If the ASL stats API for all nodes could be extended to also provide a list of connected node#s (eg. stats->linkedNodesList = “2345,45678, 56789…”) that would be only a small amount of additional data but would add a huge amount of value as the entire network graph could then be determined. @Tim_Sawyer Is there any way to do that now, or could such an extra field be added to that API relatively easily?
Not all nodes report stats so relying on stats may not be a perfect solution but in my experience the vast majority of nodes do seem to report stats - or at least the nodes that are used on hubs/repeaters are more likely to, which are the main concern because essentially we don’t want users connecting these nodes to other hubs/repeaters.
A more optimal solution might be in Asterisk itself, which should have some awareness of the connected node graph. I think it does at least have some ability to know if a connection would result in a loop, and on what nodes to route Tx audio packets to, but it may not go any further than that. So the other question is does Asterisk have some way to determine anything about the node graph ie. topology associated with a remote node? If so, where is this code and does it currently have any way to return data about the connections of a specific remote node? Asterisk probably has its limits, it would not seem to be practical for it to be sending IAX packets to every possible connected node, maybe it instead prevents loops by keeping track of IAX packet header IDs and not forwarding anything it already saw before. Not sure, but it would be great to know more about these fundamental details.
I believe all the tools are there to do just about anything you wanted for custom blocking
via
‘On Event Programming’
https://wiki.allstarlink.org/wiki/Event_Management
Used in combination with a shell script, and “rpt stats”, you could even customize who and when as well as the total limit of nodes even scheduled automatic changes for your purposes.
One can also limit the time of connected node a number of ways.
But, as @Bob_Pyke asked, there are plenty of methods and @wd6awp pretty much covered them+.
As I have blocked nodes under MY RULE that is you do not connect to me while also connected to wider networks that are not yours. (I believe that was Bob’s point) And that should be a given. But often people act without thinking of the implications. The black list works fine for bad actors. When they want to change or inquire of their black-listed status, they can receive appropriate tongue lashing.
https://wiki.allstarlink.org/wiki/Blacklist_or_whitelist
The WIN system and the WAN had this issue to each other as well as many other nodes by folks not thinking of their implications of multiple connects.
Are you familiar with asterisk -rx "do whatever here"? You could put that in a response script.
Take a look at rpt xnode 1234. I think it gives you a list of all connected nodes in rpt_links as well as the number of connections. For example.
Murdoch*CLI> rpt xnode 2510
47050 137.25.252.85 0 IN 61:50:29 ESTABLISHED ~2530 104.153.109.212 0 OUT 66:53:45 ESTABLISHED ~2520 127.0.0.1 0 OUT 66:53:45 ESTABLISHED ~25333 127.0.0.1 0 OUT 66:53:44 ESTABLISHED ~2528 76.95.70.226 1 IN 66:53:42 ESTABLISHED ~2509 47.157.241.28 0 IN 58:10:27 ESTABLISHED ~2508 104.207.154.177 0 IN 48:06:55 ESTABLISHED ~25335 104.207.154.177 0 IN 48:06:25 ESTABLISHED ~
T2501, T2508, T2509, T2520, T2521, T2523, T2525, T2526, T2528, T2530, T25333, T25335, T2554, T27439, T28020, T28021, T28022, T28023, T28025, C28026, T28028, T28029, T47050, T481470
RPT_TXKEYED=0
RPT_NUMLINKS=24
RPT_LINKS=24,T47050,T25335,T2508,T2509,T2528,T25333,T2520,T2530,T481470,T2554,T28020,C28026,T28029,T28025,T28028,T28022,T28023,T28021,T2501,T27439,T2525,T2526,T2523,T2521
RPT_NUMALINKS=8
RPT_ALINKS=8,47050TU,25335TU,2508TU,2509TU,2528TU,25333TU,2520TU,2530TU
RPT_ETXKEYED=0
RPT_AUTOPATCHUP=0
RPT_RXKEYED=0
parrot_ena=0
sys_ena=1
tot_ena=1
link_ena=1
patch_ena=1
patch_state=4
sch_ena=1
user_funs=1
tail_type=0
iconns=1
tot_state=2
ider_state=2
tel_mode=2
Re. rpt xnode, Looks like that is helpful to get the full list of nodes currently connected to the local node, however I don’t see that this would be useful in returning any data about any remote node, or in achieving the OP’s goal of preventing other nodes from connecting or remaining connected if they have too many nodes connected.
To clarify the goal, there is a general desire among numerous repeater system owners to prevent cases where a user connects who then also connects to one or more other hubs or repeater systems. eg. let’s say a user 56789 connects to 2510, and then decides to connect to the WIN System, PAPA System, East Coast Reflector, etc., without first disconnecting from 2510. Now 2510 has 100+ nodes connected and if you were having a net or QSO they are now going to be interrupted by / rebroadcast to 100’s of other nodes and/or whole other repeater systems.
Currently it seems this can only be prevented manually, ie. you’d have to be monitoring your node and go in and manually disconnect or blacklist a node each time someone (intentionally or unintentionally) connects too many nodes together. (And this is an easy mistake for newer users to make because most of the older connection monitoring and control tools including DTMF commands, AllMon and SuperMon do not do an automatic disconnect before connect by default. These older tools were created more from the perspective of sysadmins than users.)
Many repeater/hub owners would like to be able to automatically prevent users from connecting their systems to other large systems, and it would be easy to do this automatically if there was an available source of the full network node graph, ie. of all nodes not just of the local node, such that the graph could be parsed and all connections to or from any specific node can be determined. (Note that my use of the term “graph” refers to a data-structure (eg. JSON) representing all node connections, not a bitmap graphic.) The ASL stats DB contains this data, but it does not currently provide the connected nodes list for each node in the “All reporting nodes” ASL Stats API response. If that API could be extended, or another API call provided that returned just the list of directly connected node#s for all nodes, we would then have a data structure that could be easily parsed in PHP or JS to provide a complete node graph for any or all remote node(s).
I tried the rpt xnode command in Asterisk CLI and it only works for the local node #. It returns nothing for remote nodes. So if someone makes a connect request I do not think that will be of any use in being able to determine how many connections that remote node has. As a test I also tried connecting to a remote node and then running rpt xnode on that remote node#, and it returned nothing. Thus rpt xnode seems to work only for the local node.
Re. using asterisk -rx "do whatever here" in a response script, yes that’s a great a way to execute Asterisk commands without going through AMI, but I do not see that in itself being helpful to achieve the above goal.
I think what we want to do is check periodically if a remote node has an excessive number of connections. If it does it’s easy to then disconnect that node. I could put together a script fairly easily that would periodically do an API call to get this count and disconnect any nodes that have > X connections, the only missing piece however is the API call(s) that will tell us how many total connections a remote node has to other nodes. Does anyone know of any other way to get that from Asterisk? If not, then we’d need to get this data from the ASL Stats DB. The data is definitely there in the ASL Stats DB, because that’s what ASL generates Bubble Charts from. Thus it would be great if the node graph data structure used by the ASL Stats server could be made available through an API. This should be a simple change as only one field would need to be added to the existing “All reporting nodes” API: A list of directly connected node numbers eg. stats->linkedNodesList = “2345, 45678, 56789…”.
The “Individual reporting node” API does provide a list of directly connected nodes, so that would work, however if a repeater system node has a large number of connected nodes, some of which have other nodes connected, numerous calls would then be required to traverse the connected node graph of each remote node. This could easily reach 30+ API calls needed which would then be over the ASL stats rate limit per minute. Would work fine for < ~10-20 connected nodes, but ideally at some point the ASL stats could be enhanced to make this data available in a single API call either in the “All reporting nodes” API or in a new API (that would only need to return a list of directly connected node #s for all nodes or for a list of passed in node#s), or if there is a way to get this data directly from Asterisk (for any remote node) that would be even better.
I would be happy to put a script together to do what @Bob_Pyke is requesting, as this could be very useful for many other repeater owners, and could finally provide an effective fix for this longstanding issue, which is in fact a big reason why many repeater owners are using only IRLP and not yet integrating AllStar, because IRLP has stricter controls that prevent random users from being able to connect multiple systems together. If we could solve this issue it would give repeater owners automatic, granular control over what nodes can connect to their systems. They can then for example say that if any node has > 5 other connected nodes, then do not allow that connection / disconnect that node. Thus a node who has maybe just a couple friends connected to his/her node can connect just fine, but if some other node is connected to a hub with 50+ users then they get disconnected automatically. Bob, we would just need to figure out the best way to setup the script on your node, could be a cron job that runs ~once per minute that checks all connected nodes and disconnects any that have more than X connections, or could be triggered by DTMF commands, or could be set up as something that would run in a web browser. Feel free to post here or send me an email and I’d be happy to help set that up.
Hi Mike, to add to my previous comment, it appears the Event Programming stuff has access only to local node variables and thus would not be of any use. But if you know a way to get a list of all nodes that are connected to a remote node, that would be great to know.
@NR9V I think you might be missing the key values in xnode. If I go to any connected node it shows me all connections. Look for
RPT_NUMLINKS=37
RPT_LINKS=37,T2530,T2510,T47050,T25335,T2508,T2509,T2528,T25333,T2520,T2546,T29275,T53567,T48324,T600,T1003,T1017,T1015,T1013,T1012,T1011,T1005,T53466,T481470,T2554,T28020,C28026,C28029,T28025,T28028,T28022,T28023,T28021,T27439,T2525,T2526,T2523,T2521
I’m not saying no to your idea of having an API provide this information. It could prevent a connection from occurring in the first place. That would be a good thing. On the other hand if a station was not reporting their stats, do we always know they are connected? I think we do with xnode.
Hi Tim,
In the testing I’ve done, rpt xnode will only show data for your own local node(s). It will not tell you anything about what nodes other users’ nodes are connected to. eg. if 56789 connects to 2510, and then later connects to East Coast Reflector (27339), rpt xnode will indeed show that your node 2510 is now in fact connected to 56789 and to 100 other nodes associated with 27339, but it does not give you any useful information about the actual network topology ie. which specific node it was that connected to 27339 or which node you need to disconnect to get your repeater system back to a reasonable number of connections. So from what I see in my testing, rpt xnode gives only a simple list of connections to your own node(s), but zero information about any nodes that are not yours.
If you can find a way that rpt xnode or another command will tell me something about the total number of connections or list of direct or indirect connections that a remote node (that you are not the owner of) has, let me know.
I see your issue. If someone connects to an another node and that exceed the number of desired connections, how do you know what to disconnect? And you want central control from one node rather than a cooperative effort between all nodes in the net.
Xnode would only work if all the nodes in the network ran the same script and didn’t perform outbound connections that violated the limit.
@NR9V You would need to make and track your own var on last connect node number and using RPT_ALINKS to a asterisk global var before and after the connect to do what you are speaking to.
Perhaps by even counting those in RPT_ALINKS and compare to RPT_NUMLINKS
Not a precise tool. Plenty of room for error.
Or just a limit to the number of links overall. But all that is haphazard since some 3-5 node systems are pretty busy.
–
I deem it more trouble than value… Blacklist works pretty good. If you can’t monitor your own node, find a helper. You should know what is going on in your system, it bears your call. You are responsible for it.
This truly requires human evaluation and intervention in my opinion.
You can turn off inbound connects if you can’t monitor your system and it is a problem.
But I would never discourage anyone from not trying to make a utility. That is how stuff gets done and you learn how to do the next big thing.
Having said that,
If you have a habitual user(s) bringing unwanted ‘Wide Area’ connections with them,
Blacklist the wide area node should do the job.
I do believe there is a check (for loopback protection) of the connectee’s nodes. Blacklisted wide node should fix that and refuse the connection.
Admittedly, I have not tested that. Just a theory.
If it does not work, I would say this is the method you would need to add to the software.
Loopback-check-plus ‘a manual list’ by filelist. Simple and straightforward.
And then you have a ability to send yourself a email if RPT_NUMLINKS exceeds a given number, provided you setup your server to sendmail .
I can only say, I will not spend any time with this until I need such a critter. And I can’t see that.
I will add this, I finally found the info for…
https://stats.allstarlink.org/api/stats/2530 Individual reporting node. Rate limited to 30 requests per minute.
Part of the ASL API
https://wiki.allstarlink.org/wiki/Public_APIs
You should be able to get the info needed for a potential conectee’s current links for scripting.
There is one way I can think of how this could be done with only the local node information, which would be if a script can get called by app-rpt on every connect event - both before and after the connect. It could then see the total connected node count before and after and if > X then disconnect the last node that connected. That should be pretty reliable, only possible issue would be if 2 connect requests came in at the same time there could be a timing issue but that would be a rare outlier case if an issue at all. So in this case the process would look like:
- Get an event notification (call to a local php script) from app-rpt when a connect request is received but before asterisk actually accepts the connection. (Not sure if this possible or if app-rpt would only give you an event after accepting a connection?)
- Script then gets the xnode stats and event details (remote node# requesting the connect), and then somehow signals app-rpt that it’s OK to now accept the connection.
- Script then gets called again after the connection is completed, and then requests the xnode stats again, and if the new total connected node count minus the previous count is > X, then disconnect the remote node# that just connected.
It does look like the Events Management should have the ability to detect any variable changing state and call a script, so it’s just a question of if there is some variable that could be checked that would change state when a connect request is received but before the connection is accepted, such that a script would actually have time to read the NUMALINKS counts prior to them being updated. If anyone has any idea how to do that LMK. Alternatively the script could just read these vars ~once per second and then look for sudden increases in connected node count after each connect request completes, but this might not be as precise if multiple connect requests came in close together. Otherwise it may be simpler to use the stats API, though that will not necessarily be reliable either if a remote node is not properly reporting stats.
But in general any of the above approaches should handle the majority of cases very well and free the owners of larger systems from having to constantly babysit their nodes. AllStar is software, and the whole point of software generally is to make things easier for humans and automate simple repetitive tasks when practical thereby making that software a little more intelligent and useful : )
connpgm = /etc/asterisk/myscripts/48230connect.sh
discpgm = /etc/asterisk/myscripts/48230disconnect.sh
On the other, you need to take the var from the system and declare a global var in asterisk to carry it anywhere. That allows for more complete flexibility.
I don’t see anyway to manage it from a central point. Seems to me that all nodes would have to cooperate. Each would monitor their own inbound and outbound connections and prevent or disconnect as warranted.