Any way to stop crossing to specific nodes?
Howdy all, I had an incident that occurred several nights ago where one user unbenounced to him cross connected the WINSYSTEM and VOIPWX net together in the middle of the night. No matter how many times I try to explain this caution to users, they still on occasion make the error as one of the distant node might be connected to another network and it is not readily visible to the user of another node. I would like to know if there are any provisions to help prevent this from happening. For example a rule that would that if 2560 is connected, no connections to 2135 and or 3007203 (echolink node) would be allowed to be connected if there is any presence from any of the nodes tied in. I am just trying to proactively stop this from happening at least with the nodes I allow public access to. Thanks Lu Ka4EPS
At 04:03 AM 8/30/2011, Lu Vencl wrote:
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CC6654.7AA98DC0" Content-Language: en-us
Howdy all, I had an incident that occurred several nights ago where one user unbenounced to him cross connected the WINSYSTEM and VOIPWX net together in the middle of the night. No matter how many times I try to explain this caution to users, they still on occasion make the error as one of the distant node might be connected to another network and it is not readily visible to the user of another node. I would like to know if there are any provisions to help prevent this from happening. For example a rule that would that if 2560 is connected, no connections to 2135 and or 3007203 (echolink node) would be allowed to be connected if there is any presence from any of the nodes tied in. I am just trying to proactively stop this from happening at least with the nodes I allow public access to.
Is it possible to have the Echolink "CONF" flag set when connected to Echolink and some other system, or more than one Echolink node at the same time? This will at least allow Echolink conferences with anti-conferencing measures to disconnect such accidental cross links automatically. The best behaviour would be to emulate the behaviour of the Windows Echolink client in this respect. If connected to one station, the CONF flag is not set, even if the node has the ability to accept other connections. If connected to more than one station, the CONF flag is set, and the node acts as a mini conference server. One thing that would be different to Echolink is the need to recognise non Echolink connections as a "connection" for this purpose. Certainly, something to prevent this happening at the node level is best for the proactive node admin. Reminds me, I must pull my finger out and setup my node. :) 73 de VK3JED / VK3IRL http://vkradio.com
As a newbie who has barely scratched the surface of understanding Allstar, I find it next to impossible to trace every last node that is connected together. I know there is the graphical node link list, and while it shows what the possibilities are I find it too unwieldy for practical, regular use. For example, I view Lu's node status web page and it might show 5 nodes connected. I click on each one of those only to find a couple other connections on each one. There must be an automated way to determine the sum total of all nodes that happen to be connected together to form a network at that instant. I just don't know what it is, if it even exists now. Being able to aggregate this information seems like the first step in developing a watchdog that prevents ring-around-the-rosy loops. That's my 0.000002 cents worth. Bote, W4NUD http://www.botecomm.com/bote/radio – my hobby radio pages http://www.trackstreamer.com – my streaming scanner feeds http://ialerts1.com – hobbyist incident alerting network w/maps
-----Original Message----- From: Tony Langdon, VK3JED Sent: Monday, 29 August, 2011 19:18
At 04:03 AM 8/30/2011, Lu Vencl wrote:
I had an incident that occurred several nights ago where one user unbenounced to him cross connected the WINSYSTEM and VOIPWX net together in the middle of the night. No matter how many times I try to explain this caution to users, they still on occasion make the error as one of the distant node might be connected to another network and it is not readily visible to the user of another node. I would like to know if there are any provisions to help prevent this from happening.
Is it possible to have the Echolink "CONF" flag set when connected to Echolink and some other system, or more than one Echolink node at the same time? This will at least allow Echolink conferences with anti-conferencing measures to disconnect such accidental cross links automatically. The best behaviour would be to emulate the behaviour of the Windows Echolink client in this respect.
73 de VK3JED / VK3IRL http://vkradio.com
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Try this URL. Change the number after the question mark to the node of your interest. http://stats.allstarlink.org/getstatus.cgi?2530 -- Tim :wq On Aug 29, 2011, at 5:15 PM, Bote Man wrote:
As a newbie who has barely scratched the surface of understanding Allstar, I find it next to impossible to trace every last node that is connected together.
I know there is the graphical node link list, and while it shows what the possibilities are I find it too unwieldy for practical, regular use.
For example, I view Lu's node status web page and it might show 5 nodes connected. I click on each one of those only to find a couple other connections on each one. There must be an automated way to determine the sum total of all nodes that happen to be connected together to form a network at that instant. I just don't know what it is, if it even exists now.
Being able to aggregate this information seems like the first step in developing a watchdog that prevents ring-around-the-rosy loops.
That's my 0.000002 cents worth.
Bote, W4NUD http://www.botecomm.com/bote/radio – my hobby radio pages http://www.trackstreamer.com – my streaming scanner feeds http://ialerts1.com – hobbyist incident alerting network w/maps
-----Original Message----- From: Tony Langdon, VK3JED Sent: Monday, 29 August, 2011 19:18
At 04:03 AM 8/30/2011, Lu Vencl wrote:
I had an incident that occurred several nights ago where one user unbenounced to him cross connected the WINSYSTEM and VOIPWX net together in the middle of the night. No matter how many times I try to explain this caution to users, they still on occasion make the error as one of the distant node might be connected to another network and it is not readily visible to the user of another node. I would like to know if there are any provisions to help prevent this from happening.
Is it possible to have the Echolink "CONF" flag set when connected to Echolink and some other system, or more than one Echolink node at the same time? This will at least allow Echolink conferences with anti-conferencing measures to disconnect such accidental cross links automatically. The best behaviour would be to emulate the behaviour of the Windows Echolink client in this respect.
73 de VK3JED / VK3IRL http://vkradio.com
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Thanks Tim. That really helps out lots! -----Original Message----- From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of Tim Sawyer Sent: Monday, August 29, 2011 9:21 PM To: app_rpt list Subject: Re: [App_rpt-users] Any way to stop crossing to specific nodes? Try this URL. Change the number after the question mark to the node of your interest. http://stats.allstarlink.org/getstatus.cgi?2530 -- Tim :wq On Aug 29, 2011, at 5:15 PM, Bote Man wrote:
As a newbie who has barely scratched the surface of understanding Allstar, I find it next to impossible to trace every last node that is connected together.
I know there is the graphical node link list, and while it shows what the possibilities are I find it too unwieldy for practical, regular use.
For example, I view Lu's node status web page and it might show 5 nodes connected. I click on each one of those only to find a couple other connections on each one. There must be an automated way to determine the sum total of all nodes that happen to be connected together to form a network at that instant. I just don't know what it is, if it even exists now.
Being able to aggregate this information seems like the first step in developing a watchdog that prevents ring-around-the-rosy loops.
That's my 0.000002 cents worth.
Bote, W4NUD http://www.botecomm.com/bote/radio - my hobby radio pages http://www.trackstreamer.com - my streaming scanner feeds http://ialerts1.com - hobbyist incident alerting network w/maps
-----Original Message----- From: Tony Langdon, VK3JED Sent: Monday, 29 August, 2011 19:18
At 04:03 AM 8/30/2011, Lu Vencl wrote:
I had an incident that occurred several nights ago where one user unbenounced to him cross connected the WINSYSTEM and VOIPWX net together in the middle of the night. No matter how many times I try to explain this caution to users, they still on occasion make the error as one of the distant node might be connected to another network and it is not readily visible to the user of another node. I would like to know if there are any provisions to help prevent this from happening.
Is it possible to have the Echolink "CONF" flag set when connected to Echolink and some other system, or more than one Echolink node at the same time? This will at least allow Echolink conferences with anti-conferencing measures to disconnect such accidental cross links automatically. The best behaviour would be to emulate the behaviour of the Windows Echolink client in this respect.
73 de VK3JED / VK3IRL http://vkradio.com
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
In the watchdog script you could issue this command : asterisk -r -x "rpt showvars <NODE>" (where <NODE> is you node number of course, and include the quotation marks) Doing this with my node connected to 2135 gives this result: Variable listing for node 27783: RPT_TXKEYED=0 RPT_NUMLINKS=34 RPT_LINKS=34,TW3SBA,T2135,T8701,T27296,T2122,T27356,T27262,T27349,T2121,T27355,T27261,T27348,T2377,T27657,T27658,T27690,T27354,T27258,T27499,T27701,T27572,T27372,T27373,T2341,T27854,T2242,T27653,T27702,T27672,T2300,T27635,T27470,T27665,T27266 RPT_NUMALINKS=2 RPT_ALINKS=2,W3SBATU,2135TU RPT_ETXKEYED=0 RPT_RXKEYED=0 RPT_AUTOPATCHUP=0 -- 8 variables Which could be parsed for the node number that you want to reject. Then within the output of : asterisk -r -x "rpt stats <NODE>" the last DTMF command executed is shown. For example : ************************ NODE 27783 STATISTICS ************************* Selected system state............................: 0 Signal on input..................................: NO System...........................................: ENABLED Parrot Mode......................................: DISABLED Scheduler........................................: ENABLED Tail Time........................................: STANDARD Time out timer...................................: ENABLED Incoming connections.............................: ENABLED Time out timer state.............................: RESET Time outs since system initialization............: 0 Identifier state.................................: CLEAN Kerchunks today..................................: 0 Kerchunks since system initialization............: 0 Keyups today.....................................: 63 Keyups since system initialization...............: 1190 DTMF commands today..............................: 2 DTMF commands since system initialization........: 6 Last DTMF command executed.......................: 32135 TX time today....................................: 00:01:38.292 TX time since system initialization..............: 01:10:31.702 Uptime...........................................: 36:58:08 Nodes currently connected to us..................: W3SBA, 2135 Autopatch........................................: ENABLED Autopatch state..................................: DOWN Autopatch called number..........................: N/A Reverse patch/IAXRPT connected...................: DOWN User linking commands............................: ENABLED User functions...................................: ENABLED Parse and use that line to construct a disconnect command to nullify the last . Then maybe play an "conflicting node" voice announcement. Bob, WB3AWJ Loganville, PA
In fact, it just occurred to me that if the same sort of information was available on a co-located IRLP node, the two nodes could maintain dynamic "lockout" lists. Robert Poff Loganville, Pa Droid X Mobile
Interesting idea.. Thanks! From: app_rpt-users-bounces@ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of Robert A. Poff Sent: Tuesday, August 30, 2011 9:06 AM To: app_rpt list Subject: Re: [App_rpt-users] Any way to stop crossing to specific nodes? In fact, it just occurred to me that if the same sort of information was available on a co-located IRLP node, the two nodes could maintain dynamic "lockout" lists. Robert Poff Loganville, Pa Droid X Mobile
At 11:05 PM 8/30/2011, Robert A. Poff wrote:
In fact, it just occurred to me that if the same sort of information was available on a co-located IRLP node, the two nodes could maintain dynamic "lockout" lists.
Hmm, you guys are really inspiring me to get my nodes back online. Looks like a call to the national frequency coordinator at the WIA is in order, so I can get the RF on air. 73 de VK3JED / VK3IRL http://vkradio.com
participants (6)
-
Bote Man -
Lu Vencl -
Robert A. Poff -
Robert A. Poff WB3AWJ
-
Tim Sawyer -
Tony Langdon, VK3JED