Is there any utility available to have a robot function working to allow a response to PING and TRACE(route) ?
I would like to test this and try, but I do not see a real reference in
Husky
Is there any utility available to have a robot function working to allow
a response to PING and TRACE(route) ?
anyone with hints/tips/scripts?
I downloaded Deon George's fidohub source once upon a time which
contained a modified version of pong.pl. I butchered it up a bit to
add a few things and change some others.
You're welcome to give it a try:
https://nrbbs.net/pong.pl.txt
This one accepts ping messages addressed in either case (e.g: Ping,
ping, PING or even PiNg) and kills the original incoming message once processed. It also handles the kludges a bit differently.
I'm not a programmer or anything, so this may not be the best or even
the correct way to do any of this. It seems to work here well enough
but if it breaks, you get to keep both pieces. If anyone has any suggestions or modifications I'd be happy to see them.
Jay
I downloaded Deon George's fidohub source once upon a time which
contained a modified version of pong.pl. I butchered it up a bit to
add a few things and change some others.
You're welcome to give it a try:
https://nrbbs.net/pong.pl.txt
This one accepts ping messages addressed in either case (e.g: Ping,
ping, PING or even PiNg) and kills the original incoming message once processed. It also handles the kludges a bit differently.
I'm not a programmer or anything, so this may not be the best or even
the correct way to do any of this. It seems to work here well enough
but if it breaks, you get to keep both pieces. If anyone has any suggestions or modifications I'd be happy to see them.
Jay
You're welcome to give it a try:
https://nrbbs.net/pong.pl.txt
I'm not a programmer or anything, so this may not be the best or even
the correct way to do any of this. It seems to work here well enough
but if it breaks, you get to keep both pieces. If anyone has any suggestions or modifications I'd be happy to see them.
You're welcome to give it a try:
https://nrbbs.net/pong.pl.txt
Worked wonderful. I have seen the ping and reply from Wilfred
I had to change it very little to have it correctly working on my system
https://github.com/aroundmyroom/fidonet-pingpong
I have put it on my repository ..
Although I am no coder I do like to share my amateur work 😉
Seems to be a bit better than the original. ;-)
I replaced the old one with this here at 2:221/0 aka 2:221/1. Seems
that it also responds with a correct aka. :)
Seems to be a bit better than the original. ;-)
LOL .. I did not change that much *yet*
the trace functionallity has been tested as well ..
You're welcome to give it a try:
https://nrbbs.net/pong.pl.txt
Worked wonderful. I have seen the ping and reply from Wilfred
I had to change it very little to have it correctly working on my
system
Actually I was comparing it to this one:
https://github.com/huskyproject/hpt/blob/master/misc/pong.pl
Or whatever hack of that I was running before. ;)
But the extra code is 100% credits to:
Modified by Jay Harris (1:229/664) with thanks to Deon George
(3:633/509). ;)
I hadn't really looked at this script in awhile & made a couple of changes. I'm really not sure why I was using "while" to get $fromzone
& $myzone.
I've incorporated your changes in my script for (fidian)
https://github.com/aroundmyroom/fidonet-pingpong
https://github.com/aroundmyroom/fidonet-pingpong
Did you mean to add the closing curly bracket on line 55?
But that was after I posted to this echo. And it took me an kuch.. an
hour to fix. ;)
making your script available made it possible that 2 new nodes have the PING and TRACE flag in the nodelist ;)
Just made one last change, basically just moved:
if ( length($area) == 0 && uc($toname) eq "PING" && uc($fromname) ne "PING" )
if ( length($area) == 0 && uc($toname) eq "PING" && uc($fromname) ne "PING" )
If I read that correctly... There is a use case to allow the from name
in the received message to be "PING" !
If I read that correctly... There is a use case to allow the from
name in the received message to be "PING" !
That line appears in the original here:
https://github.com/huskyproject/hpt/blob/master/misc/pong.pl
So I left it as it.
http://ftsc.org/docs/fts-5001.006 does say under 5.10. Robot flags:
WARNING: the sender's name (in either direction) must *NEVER* be "PING".
Should that line in FTS-5001 be removed or modified?
if ( length($area) == 0 && uc($toname) eq "PING" && uc($fromname)
ne "PING" )
If I read that correctly... There is a use case to allow the from name
in the received message to be "PING" !
Just make the from name in the reply not "PING" otherwise messages
could keep bouncing back and forth...
I think it can be improved. I agree with the wording for the reply direction. But for the original send direction it could be softened to "should not" instead of "must *NEVER*". It's not normal operation but
I have done some tests where I wanted to sent from "PING", so it would trigger another response when the PONG arrived, as a way to test my
own robot. With this wording it isn't necessary for the robot to check
for anything in the from field.
if ( length($area) == 0 && uc($toname) eq "PING" && uc($fromname)
ne "PING" )
If I read that correctly... There is a use case to allow the from name
in the received message to be "PING" !
Just make the from name in the reply not "PING" otherwise messages
could keep bouncing back and forth...
I think the line prevents that.
My system will not send a reply to your system if your name is ping,
the mail is than sitting in my netmail area ..
you can always try (and you will probably) ;)
I think it can be improved. I agree with the wording for the reply
direction. But for the original send direction it could be softened
to "should not" instead of "must *NEVER*". It's not normal operation
but I have done some tests where I wanted to sent from "PING", so it
would trigger another response when the PONG arrived, as a way to
test my own robot. With this wording it isn't necessary for the robot
to check for anything in the from field.
So if I read your comment you would like to accept a ping from ping but do not
reply with ping as from
correct?
So if I read your comment you would like to accept a ping from ping but not reply with ping as from
Yes, that last restriction is (very) important, otherwise PONG messages could "bounce" back and forth indefinitly...
So if I read your comment you would like to accept a ping fromping DS> but not reply with ping as from
Yes, that last restriction is (very) important, otherwise PONG messages
could "bounce" back and forth indefinitly...
my $myname = 'Ping Robot'; # From: name in PONG reply. Cannot be 'PING' [...]
# Do not set $myname to 'PING'
if ( uc($myname) eq "PING" ) { die "ERROR: \$myname cannot be PING"; }
# Check if message is netmail & addressed to PING (case insensitive)
if ( length($area) == 0 && uc($toname) eq "PING" ) {
[...]
I think this would do that.
It would accept a netmail addressed to "Ping" and also from "Ping".
If someone tried setting $myname to "Ping" the script would exit with
an error.
The reply would be from "Ping Robot" to "Ping" which (if the remote
system has a ping robot) would trigger a response from that system,
e.g: From: Ping Robot & To: Ping Robot.
| Sysop: | fluid |
|---|---|
| Location: | wickliffe, ohio |
| Users: | 5 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 216:54:06 |
| Calls: | 50 |
| Files: | 15,838 |
| Messages: | 50,907 |