How do you block a single annoying Node?
Hack the rc.updatenodelist script...$EGREP for offending node, take out
of downloaded list as you write to temp file, then copy temp node file
over to active nodelist.
At least that's how we do it out here. If you want, I can send you our
script directly, and you can take a look...
···
On 6/14/2011 7:36 PM, Bob Bunter wrote:
How do you block a single annoying Node?
Add it to the nodes stanza in rpt.conf with a bogus IP (127.0.0.1 works)
Also you could probably use the extnodefile option to do the same thing using a standalone file.
The only problem is the annoying node could still connect via another node that is not blocked.
Steve
···
On 6/14/2011 17:30, Bryan D. Boyle wrote:
On 6/14/2011 7:36 PM, Bob Bunter wrote:
How do you block a single annoying Node?
Hack the rc.updatenodelist script...$EGREP for offending node, take out
of downloaded list as you write to temp file, then copy temp node file
over to active nodelist.At least that's how we do it out here. If you want, I can send you our
script directly, and you can take a look..._______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
ohnosec.org
Yeah...can't totally prevent a determined LID from causing trouble...had an issue with a well-known miscreant on the bands interrupting our sunday night net a few weeks ago...tracked him down (it wasn't hard), and Jim took care of the Allstar registration quite smartly...Echo, well, that took a bit of convincing (why? I don't know...but it did...had to send logs, etc. but what it comes down to is that system operators have the rights, under Part 97, to forbid ANY operator from using our systems...) to disable the individual's login.
If they're determined, they WILL get in, but, with the cooperation of the community here...it won't last for very long.
That has me thinking...we allow connections from registered nodes...a 'white list' if you will...should we also have a 'black list' of those who, for whatever reason, have violated or abused the terms of use of the Allstar system that are validated against when they log in and try and connect?
I know, more paperwork, right?
···
On 6/14/11 11:48 PM, Steve Passmore wrote:
The only problem is the annoying node could still connect via another node that is not blocked.
Steve
--
Bryan
In this world, you must be oh so smart or oh so pleasant.
Well, for years I was smart. I recommend pleasant.
You may quote me.
The only problem is the annoying node could still connect via another node that is not blocked.
Steve
Yeah...can't totally prevent a determined LID from causing trouble...had an issue with a well-known miscreant on the bands interrupting our sunday night net a few weeks ago...tracked him down (it wasn't hard), and Jim took care of the Allstar registration quite smartly...Echo, well, that took a bit of convincing (why? I don't know...but it did...had to send logs, etc. but what it comes down to is that system operators have the rights, under Part 97, to forbid ANY operator from using our systems...) to disable the individual's login.
If they're determined, they WILL get in, but, with the cooperation of the community here...it won't last for very long.
That has me thinking...we allow connections from registered nodes...a 'white list' if you will...should we also have a 'black list' of those who, for whatever reason, have violated or abused the terms of use of the Allstar system that are validated against when they log in and try and connect?
I know, more paperwork, right?
It would be nice to have whitelist and a blacklist capability on nodes. One of the things that app_rpt appears to be lacking is management capabilities such as this. We're forced to use kludges, an example being the ability to monitor what node active at any particular moment. Currently we're basically tailing the log file that is created with the audio archive feature. It works but it would be nice to have a more direct approach, possibly with more data such as knowing what node further away than 1 hop is active, although I don't think this data is present for the node to know.
Come to think of it, if a node is fooled into thinking the offending node number was connected it would prevent the actual offending node from connecting even through another node. I've run into a similar situation with private node numbers, two Allstarlink nodes that had a different node numbered 1000 connected to them wouldn't connect because it thought a loop could be created.
Steve