Maintenance recommendations (II)
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
Hi Kin, You are investing a lot of personal time and effort to produce these reports and provide recommendations. It must be important. But I honestly do not understand the impact of sending or not sending PC92 traffic. Impact in terms of ability to send or receive spots. To make this concrete- N2WQ-73 is a true DXS node and sends and receives PC92 frames. N2WQ-77 is the cluster node I developed that receives (and immediately dumps), but does not send PC92 frames. The two of the communicate just fine and exchange spots. And of course N2WQ-1 and VE3EID-1, both CCC, don't send PC92, but work just fine. So what functionality is broken when a node does not send PC92? If spots are flowing in both directions, what is not? I need help understanding the practical implications. Rudy N2WQ On Tuesday, February 3, 2026 at 10:35:44 AM EST, Kin via Dxspider-support <dxspider-support@dxcluster.org> wrote: 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 _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org
I’m going to write an agent that, whenever I receive an email from DX Spider, responds with “Can someone get me off this list? And yes, I used the unsubscribe link but it doesn’t work”. 😆 On Tue, 3 Feb 2026 at 17:35, Rudy Bakalov via Dxspider-support < dxspider-support@dxcluster.org> wrote:
Hi Kin,
You are investing a lot of personal time and effort to produce these reports and provide recommendations. It must be important. But I honestly do not understand the impact of sending or not sending PC92 traffic. Impact in terms of ability to send or receive spots.
To make this concrete- N2WQ-73 is a true DXS node and sends and receives PC92 frames. N2WQ-77 is the cluster node I developed that receives (and immediately dumps), but does not send PC92 frames. The two of the communicate just fine and exchange spots. And of course N2WQ-1 and VE3EID-1, both CCC, don't send PC92, but work just fine.
So what functionality is broken when a node does not send PC92? If spots are flowing in both directions, what is not? I need help understanding the practical implications.
Rudy N2WQ
On Tuesday, February 3, 2026 at 10:35:44 AM EST, Kin via Dxspider-support < dxspider-support@dxcluster.org> wrote:
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
_______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org
Sending an email from ton@machielsen.net to dxspider-support-leave@dxcluster.org is all you need to do. 73, Chris - G1FEF
On 3 Feb 2026, at 16:57, Ton Machielsen via Dxspider-support <dxspider-support@dxcluster.org> wrote:
I’m going to write an agent that, whenever I receive an email from DX Spider, responds with “Can someone get me off this list? And yes, I used the unsubscribe link but it doesn’t work”. 😆
On Tue, 3 Feb 2026 at 17:35, Rudy Bakalov via Dxspider-support <dxspider-support@dxcluster.org> wrote: Hi Kin,
You are investing a lot of personal time and effort to produce these reports and provide recommendations. It must be important. But I honestly do not understand the impact of sending or not sending PC92 traffic. Impact in terms of ability to send or receive spots.
To make this concrete- N2WQ-73 is a true DXS node and sends and receives PC92 frames. N2WQ-77 is the cluster node I developed that receives (and immediately dumps), but does not send PC92 frames. The two of the communicate just fine and exchange spots. And of course N2WQ-1 and VE3EID-1, both CCC, don't send PC92, but work just fine.
So what functionality is broken when a node does not send PC92? If spots are flowing in both directions, what is not? I need help understanding the practical implications.
Rudy N2WQ
On Tuesday, February 3, 2026 at 10:35:44 AM EST, Kin via Dxspider-support <dxspider-support@dxcluster.org> wrote:
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 _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org
Check the last sentence in my text. On Tue, 3 Feb 2026 at 18:13, Chris via Dxspider-support < dxspider-support@dxcluster.org> wrote:
Sending an email from ton@machielsen.net to dxspider-support-leave@dxcluster.org is all you need to do.
73, Chris - G1FEF
On 3 Feb 2026, at 16:57, Ton Machielsen via Dxspider-support < dxspider-support@dxcluster.org> wrote:
I’m going to write an agent that, whenever I receive an email from DX Spider, responds with “Can someone get me off this list? And yes, I used the unsubscribe link but it doesn’t work”. 😆
On Tue, 3 Feb 2026 at 17:35, Rudy Bakalov via Dxspider-support < dxspider-support@dxcluster.org> wrote: Hi Kin,
You are investing a lot of personal time and effort to produce these reports and provide recommendations. It must be important. But I honestly do not understand the impact of sending or not sending PC92 traffic. Impact in terms of ability to send or receive spots.
To make this concrete- N2WQ-73 is a true DXS node and sends and receives PC92 frames. N2WQ-77 is the cluster node I developed that receives (and immediately dumps), but does not send PC92 frames. The two of the communicate just fine and exchange spots. And of course N2WQ-1 and VE3EID-1, both CCC, don't send PC92, but work just fine.
So what functionality is broken when a node does not send PC92? If spots are flowing in both directions, what is not? I need help understanding the practical implications.
Rudy N2WQ
On Tuesday, February 3, 2026 at 10:35:44 AM EST, Kin via Dxspider-support <dxspider-support@dxcluster.org> wrote:
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 _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org
_______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org
Hi Rudy, Thank you for laying out the concrete examples so clearly; they really help distinguish between what works and what the network can actually understand about a node. I agree that, from a purely operational standpoint, a node that does not send PC92 can still exchange spots and appear to function correctly. Your examples show that clearly: the network does not stop, and data continues to flow. However, the emphasis on PC92 is not about immediate spot delivery, but about the need for a network that is diagnosable, maintainable, and defensible over time. When a node does not send PC92: * The network loses a standard signal that helps diagnose malfunctions, partial failures, or abnormal behavior. * It becomes harder to detect misconfigured, degraded, or abusive nodes, including attacks or garbage injection. * Other nodes cannot reliably distinguish between an intentional limitation, a software defect, or a node operating outside expected parameters. Like any distributed network, ours does not maintain itself. It requires ongoing care from each node operator. If that maintenance is neglected, the result is not an immediate failure, but a gradual degradation: more noise, less traceability, and increasing difficulty in isolating real problems. In this context, PC92 acts as a network hygiene mechanism. It is not strictly required for spots to flow today, but it is essential if we want to: * analyze incidents, * filter and eliminate garbage, * identify problematic nodes, * and maintain a reasonable level of trust and quality across the network. My intent in emphasizing this point is not to question specific implementations, but to avoid a situation where “everything seems to work” until it doesn’t — and at that point, we no longer have standard tools to understand why. Otherwise, we risk ending up with a fragmented network of isolated implementations, each working on its own terms, but without shared visibility or collective resilience. Kin EA3CV -----Mensaje original----- De: Ton <dxspider-support@dxcluster.org> Para: DXSpider <dxspider-support@dxcluster.org> CC: ton <ton@machielsen.net>; Chris <chris@g1fef.co.uk>; Ton <ton.machielsen@gmail.com> Fecha: martes, 3 de febrero de 2026 18:34 CET Asunto: [Dxspider-support] Re: Maintenance recommendations (II) Check the last sentence in my text. On Tue, 3 Feb 2026 at 18:13, Chris via Dxspider-support <dxspider-support@dxcluster.org> wrote: Sending an email from ton@machielsen.net to dxspider-support-leave@dxcluster.org is all you need to do. 73, Chris - G1FEF
On 3 Feb 2026, at 16:57, Ton Machielsen via Dxspider-support <dxspider-support@dxcluster.org> wrote:
I’m going to write an agent that, whenever I receive an email from DX Spider, responds with “Can someone get me off this list? And yes, I used the unsubscribe link but it doesn’t work”. 😆
On Tue, 3 Feb 2026 at 17:35, Rudy Bakalov via Dxspider-support <dxspider-support@dxcluster.org> wrote: Hi Kin,
You are investing a lot of personal time and effort to produce these reports and provide recommendations. It must be important. But I honestly do not understand the impact of sending or not sending PC92 traffic. Impact in terms of ability to send or receive spots.
To make this concrete- N2WQ-73 is a true DXS node and sends and receives PC92 frames. N2WQ-77 is the cluster node I developed that receives (and immediately dumps), but does not send PC92 frames. The two of the communicate just fine and exchange spots. And of course N2WQ-1 and VE3EID-1, both CCC, don't send PC92, but work just fine.
So what functionality is broken when a node does not send PC92? If spots are flowing in both directions, what is not? I need help understanding the practical implications.
Rudy N2WQ
On Tuesday, February 3, 2026 at 10:35:44 AM EST, Kin via Dxspider-support <dxspider-support@dxcluster.org> wrote:
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 _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org _______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org
_______________________________________________ Dxspider-support mailing list -- dxspider-support@dxcluster.org To unsubscribe send an email to dxspider-support-leave@dxcluster.org
participants (4)
-
Chris -
Kin -
Rudy Bakalov -
Ton Machielsen