Hi,
Below is some data that may help identify issues between nodes.
A value of "1" indicates that the node has reported an active connection with its peer.
A value of "0" means that there was either no response from the node or that it reported a disconnection.
"U" indicates the total number of connections.
"D" indicates the total number of disconnections.
Nodes that do not appear here are not necessarily operating correctly; these are simply the accumulated values at the time the data was read.
All of this data comes from the analysis of PC92 frames transmitted on the network.
Interconnections between nodes that do not use PC92 will never appear here — for the network, they effectively do not exist.
There are nodes, such as ARC, that never emit PC92 frames.
Some CCC nodes emit them, but most do not, and they do not behave in the same way as DXSpider nodes.
Additionally, some DXSpider nodes do not use PC92 either because it is disabled or because they are running obsolete versions.
In any case, this data indicates a problem between nodes, either because the link is not being established correctly or because the nodes are not fully compatible.
Please note that the callsigns of the nodes shown in the list are those reported by the peer node.
It is quite common to see nodes appearing with a different callsign (with or without SSID, or with a different SSID). This is usually a clear indication of configuration problems on the link.
Some nodes shown in the list have not been properly defined, either because they are not defined as nodes at all or because they are defined with an incorrect node type. This will prevent the link from being established.
The most common and correct configuration should include definitions such as:
* set/spider
* set/ccluster
* set/node
If the callsign of a peer node is incorrect, it must be corrected using the commands above and/or by verifying the connection configuration file.
A typical and expected connection file should look like this:
timeout 15
connect telnet <hostname or IP> <port>
'login: ' '<our node callsign>'
'assword:' '<password, if required>'
In some cases, the login field does not contain the node’s actual callsign, but a different one. This is a common source of problems and should be corrected.
If a sysop believes that they do not have an active link with one of the nodes shown in the list, the usual and recommended action is to inform the peer sysop and ask them to remove any pending or repeated connection attempts from their crontab.
I hope this information helps clarify and resolve the issue.
Please see the attached file.
Kin EA3CV
