The html attachment came up very nice and pretty as a local file just using the browser.That's good to know.
In reply to your much older post about the Wisconsin
University network monitoring, I was browsing and came
across this: https://tools.wiscnet.net/stats/docs/netmap-
bcn.html and thought how amazing it would be to have the
equivalent for FTN!
PS: I reconfigured my echos and messed up the "Real Names"
setting. Should be fixed again now.
https://confluence.wiscnet.net/display/WPKB/WiscNet+Tools
Yes.. it is very interesting. I found out that if I navigate a
little bit up the /levels, I get a screen that tells me there
is an updated (live) resource here:
https://confluence.wiscnet.net/display/WPKB/WiscNet+Tools
It would be very cool indeed to have something similar for FTN
that indicates up/down nodes, connection volumes, echomail
stats, etc in graphical form.
Wilfred van Velzen wrote to August Abolins <=-
This data simply isn't available for fidonet. You would need to have
the cooperation of a large number of sysops, to be able to analyse the incoming pkt files on their system in an uniform way, and send the data to a central place where it could be analysed and visualized on a website... Good luck with that! ;-)
This data simply isn't available for fidonet. You would need to haveIt would be quit simple to impliment. Some sysops however may find a quick ping to their binkd port intrusive, but it really wouldn't be. A responce to the query would be enough to know if the system is up or down. The issue might be with the volume of nodes.
Someone suggested I'm actually writing such a thing but I'm not. I doLOL. It was suggested to me..
John Dovey wrote to Brian Rogers <=-
True. There is all kinds of software out there that will do this in a
net friendly way. IcePing, EchoPing etc come to mind.
Someone suggested I'm actually writing such a thing but I'm not. I do
LOL. It was suggested to me..
Good to know !.
Not a problem. Just a few other things right now are a bit more important to me and my system right now :)
John Dovey wrote to Brian Rogers <=-
Yup. I feel your pain. There are a plethora of moving parts...
This data simply isn't available for fidonet. You would need to have
the cooperation of a large number of sysops, to be able to analyse
the incoming pkt files on their system in an uniform way, and send
the data to a central place where it could be analysed and visualized
on a website... Good luck with that! ;-)
It would be quit simple to impliment. Some sysops however may find a
quick ping to their binkd port intrusive, but it really wouldn't be. A responce to the query would be enough to know if the system is up or
down.
Wilfred van Velzen wrote to Brian Rogers <=-
That would be the only thing you know. You still don't know who
connects where, and display that graphically, as suggested by the websites that were linked to in previous messages in this thread...
That would be the only thing you know. You still don't know who
connects where, and display that graphically, as suggested by the
websites that were linked to in previous messages in this thread...
That would result in many false positives to do that. Sites that do direct crash netmail would falsely report that they do full forwarding with each other when in fact it'd just be netmail not echomail exchanged.
For an NC such as myself, it could be used to determine a node or
point's status and after so many consecutive failures remove that destination from the nodelist... or at least let the NC know that a
node may have decided to drop out.
Wilfred van Velzen wrote to Brian Rogers <=-
If you are only interested in echomail links, you could use messages in pkt files that have an AREA: line?
You could easily deduce that information by looking at your outbound directory. ;)
Hello Wilfred;
Wilfred van Velzen wrote to Brian Rogers <=-
If you are only interested in echomail links, you could use messages in
pkt files that have an AREA: line?
I'd only be interested in who's alive and who's not... and for me personally
those who are within 1:142 only. It's not up to me to police the rest of the
world :)
You could easily deduce that information by looking at your outbound
directory. ;)
That's not good enough. What if a sysop went away on business for a few weeks and shut the power off - and forgot to tell me? Whenever you do any sort of monitoring you must do your best to protect against false positives
or else you're true alarms get naturally ignored.
... Ensign Crusher, here is you Mop and Bucket
Hello Wilfred;
Wilfred van Velzen wrote to Brian Rogers <=-
If you are only interested in echomail links, you could use messages in
pkt files that have an AREA: line?
I'd only be interested in who's alive and who's not... and for me personally
those who are within 1:142 only. It's not up to me to police the rest of the
world :)
You could easily deduce that information by looking at your outbound
directory. ;)
That's not good enough. What if a sysop went away on business for a few weeks and shut the power off - and forgot to tell me? Whenever you do any sort of monitoring you must do your best to protect against false positives
or else you're true alarms get naturally ignored.
... Ensign Crusher, here is you Mop and Bucket
If you are only interested in echomail links, you could use messages
in pkt files that have an AREA: line?
I'd only be interested in who's alive and who's not... and for me personally those who are within 1:142 only. It's not up to me to police the
rest of the world :)
You could easily deduce that information by looking at your outbound
directory. ;)
That's not good enough. What if a sysop went away on business for a few weeks and shut the power off - and forgot to tell me?
Whenever you do any sort of monitoring you must do your best to
protect against false positives or else you're true alarms get
naturally ignored.
John Dovey wrote to Brian Rogers <=-
Something like this for the Zone Hubs, then for the RC within a zone maybe? https://oss.oetiker.ch/smokeping-demo/?target=multi.DNSJ
Wilfred van Velzen wrote to Brian Rogers <=-
You want to check if your downlinks are connectable. And August (I
think) was looking for a nice way to visualize all the connections between fidonet systems. So you could see how echo and netmail flows through the net.
What's the difference between looking at what's in your outbound, and notice there are files for a system that have not been send because
your mailer failed to connect to it; or doing a periodic ping to that system to find out if it's still online?
Hello John;
John Dovey wrote to Brian Rogers <=-
Something like this for the Zone Hubs, then for the RC within a zone
maybe? https://oss.oetiker.ch/smokeping-demo/?target=multi.DNSJ
Let me tell you why that would not work:
I have written a monitoring system for packet nodes using RRDTool which is what your smokeping uses. RRDTool requires MRTG as it's backend... and mrtg
requires SNMP. FTN does not support this. This doesn't mean that each sysop
couldn't allow SNMP to their communication interface however an argument against such would be system security! I would never ask one to do this.
... If you're bad at haggling, you'll end up paying the price.
John Dovey wrote to Brian Rogers <=-
Granted. I did say "something like"...
1) You want to check if your downlinks are connectable.
2) And August (I think) was looking for a nice way to visualize all
the connections between fidonet systems. So you could see how echo
and netmail flows through the net.
I would consider doing something as such a breach of security.
See my response to John.
There's also way too many nodes to do this efficiently
his data simply isn't available for fidonet. You would need to have
the cooperation of a large number of sysops, to be able to analyse
the incoming pkt files on their system in an uniform way, and send
the data to a central place where it could be analysed and visualized
on a website... Good luck with that! ;-)
even if you were to ignore the security aspect.
What's the difference between looking at what's in your outbound, and
notice there are files for a system that have not been send because
your mailer failed to connect to it; or doing a periodic ping to that
system to find out if it's still online?
Because if I saw a backlog of mail, I'd use another means of communication to see what's going on such as an actual voice call or text. Someting any computerized automation is unable to accomplish. Monitoring "tools" are just that - aids or tools to assist with a specific task.
In Fido or any other FTN, it's simply a hobby not a commercial
enterprise. We need not care about whether a node or point has a full second latency time or a 10 second latency time. That's something more
for your ISP to monitor and be proactive in resolving so you don't
have to open a trouble ticket with them... even though most don't <G>
Wilfred van Velzen wrote to Brian Rogers <=-
1) You want to check if your downlinks are connectable.
2) And August (I think) was looking for a nice way to visualize all
the connections between fidonet systems. So you could see how echo
and netmail flows through the net.
I don't see a security issue in doing 1). And for 2) you need the cooperation of the node.
his data simply isn't available for fidonet. You would need to have
the cooperation of a large number of sysops, to be able to analyse
the incoming pkt files on their system in an uniform way, and send
the data to a central place where it could be analysed and visualized
on a website... Good luck with that! ;-)
What's the difference between looking at what's in your outbound, and
notice there are files for a system that have not been send because
your mailer failed to connect to it; or doing a periodic ping to that
system to find out if it's still online?
My point was, the mailer, because it will do automatic periodic polls when it can't deliver it's mail, is the monitoring tool. You don't need extra software for this to find out a node is offline.
I wasn't talking about latency, that's totally not interesting when it comes to delivering mail to nodes. The only interesting bit is,
wheather it's online or not. And that is easy to find out by looking at the state of your outbound directories.
1) You want to check if your downlinks are connectable.
2) And August (I think) was looking for a nice way to visualize all
the connections between fidonet systems. So you could see how echo
and netmail flows through the net.
The desired example was using RRDTool graphing which requires SNMP. A sysop
not familiar with that could accidentally flag his system as writable and be taken over by a 3rd party.
What's the difference between looking at what's in your outbound,
and notice there are files for a system that have not been send
because your mailer failed to connect to it; or doing a periodic
ping to that system to find out if it's still online?
On linux, a very simple shell script can be used. I would guess in powershell a parallel could be done too... I don't use Windows so I wouldn't know. Just search the contents of your outbound directory for files and if they exist then sites are down. Not rocket science :)
I wasn't talking about latency, that's totally not interesting when
it comes to delivering mail to nodes. The only interesting bit is,
wheather it's online or not. And that is easy to find out by looking
at the state of your outbound directories.
You didn't but someone else did. I don't think that's even necessary as mail will either go through or it won't. I was thinking of using a modified
fping as I use on amateur packet radio. It's worked very well for over 2 decades. It may serve the purpose here.
Wilfred van Velzen wrote to Brian Rogers <=-
That needs cooperation of the sysop to install and open up the SNMP "daemon" to the outside. If they do that they should be aware of the security risks...
If you just check your links by "pinging" if their binkp poort is connectable, there is no security risk.
What's the difference between looking at what's in your outbound,
and notice there are files for a system that have not been send
because your mailer failed to connect to it; or doing a periodic
ping to that system to find out if it's still online?
On linux, a very simple shell script can be used. I would guess in powershell a parallel could be done too... I don't use Windows so I wouldn't know. Just search the contents of your outbound directory for files and if they exist then sites are down. Not rocket science :)
I wasn't asking how to do it, I was asking what the difference was between the two methods. In my opinion both methods can give you the
same information, so you don't need to do a separate ping to know if a system is online or not.
Again: You don't need to ping, just look at what's in your outbound...
;)
I wasn't asking how to do it, I was asking what the difference was
between the two methods. In my opinion both methods can give you the
same information, so you don't need to do a separate ping to know if
a system is online or not.
I did show what the difference was. One method could easily be done via a script. The other would intail more indepth coding.
Again: You don't need to ping, just look at what's in your
outbound... ;)
Wrong my friend. A point who doesn't desire to have crash mail that may poll once a week would show mail stuck in the outbound and read a very false positive.
Now my question is: for what purpose would such a thing serve? Entertainment value?? That's all I can really see this for.
If the goal is to see if a node or point left an FTN that's one thing
and monitoring one's outbound should be more than sufficient, and in reality such a tool should be included in the FTN mailers to auto mail
the sysop "mail for #:###/### has been in your queue for 30 or more
days." Again in the interim this could probably be handled by a shell script that can be cronned that mails the sysadmim/sysop.
Other than that I don't see where someone in 3:###/### for example
would need or want to see my boring stats.
Wilfred van Velzen wrote to Brian Rogers <=-
Looking at your outbound, only needs a set of eyes and fingers, no
other tools required! ;)
Such a point won't be pingable either. So you also need information
about your links, that was implied, and would be something a sysop looking at his outbound would know.
It serves the smooth operation of the network.
Such a tool would make the sysops live a bit easier, but you don't
really need it. You don't need to automate it, the commands provided by your OS (cd/dir/ls) are sufficient to find out if your outbound is full of unsend mail.
I didn't know we were talking about making this information public?
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,049 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 70:23:27 |
| Calls: | 236,054 |
| Calls today: | 2 |
| Files: | 60,364 |
| D/L today: |
46 files (52,542K bytes) |
| Messages: | 289,739 |