[Dxspider-support] An update about HamAward.

Lorenzo IU1NSA iu1nsa at haminnovation.com
Wed Mar 19 15:59:53 GMT 2025


Good morning everyone,

First of all, I want to thank Keith for making this mediation possible.
On our side as well, we prefer to spend our time collaborating rather 
than engaging in pointless conflict.
We're happy that we can finally all be on the same wavelength.

As Keith explained, any form of spot re-sending has been completely 
removed.
Spots that do not make it onto the cluster network will only appear on 
our web pages, alongside the others.

Regarding the comments: to prevent users from writing arbitrary content, 
they are not allowed to modify the comment field. The comment is fixed 
for each ongoing award, and the only optional addition is the operating 
mode (if they wish to include it).

We also decided to increase the minimum wait time between consecutive 
spots by the same activator to 15 minutes.
This is mainly because we verified that DXSpider's dupe-check system, 
when set to 10 minutes, could in reality behave differently due to time 
granularity. In the worst-case scenario, the actual minimum interval is 
11 minutes and 1 second. To avoid confusion and misleading users by 
stating “11 minutes,” we opted to round it up to a clean 15-minute 
window.

As for the sendverify check, we discovered a bug in DXSpider.
After reconfiguring the IW1FRU-74 node, we noticed that the first spot 
sent by a newly connected user was being flagged as not logged in, and 
therefore rejected. However, all subsequent spots from the same session 
were accepted.

After analyzing the code in depth, I found the exact cause of the issue.
In the file DXCommandmode.pm, when a client connects, the system tries 
to send the PC92 A message with this line:

$main::me->route_pc92a($main::mycall, undef, $main::routeroot, $ref) 
unless $DXProt::pc92_slug_changes || ! $DXProt::pc92_ad_enable;

The problem is a simple typo: the variable name pc92_ad_enable is 
incorrect — it's missing the final “d”. The correct variable, as defined 
in DXProt.pm, is pc92_ad_enabled.
Because of this mismatch, the check fails silently, and the PC92 A 
message is not sent when a user connects — it's only triggered after the 
first spot, which is too late for validation purposes.

To fix this, we corrected the typo in the code by replacing:

$DXProt::pc92_ad_enable

with:

$DXProt::pc92_ad_enabled

Alternatively, we also tested disabling the slugging feature entirely by 
setting:

$DXProt::pc92_slug_changes = 0;

in the DXSpider node configuration.
After applying these changes, the first spots are now correctly accepted 
as well.

To be fully transparent, we've also added a banner visible when 
connecting to cluster.haminnovation.com 7300 via Telnet, which outlines 
the platform's configuration.
The node IP is static and correctly resolves to our domain even in 
reverse DNS lookups.

As for potential solutions regarding webclusters, I believe that could 
be discussed in a separate topic.

Lastly, for reference, the main contacts for HamAward are:
- Technical representative: myself, Lorenzo IU1NSA 
(iu1nsa at haminnovation.com / lorenzo.santina at gmail.com)
- Administrative representative: Max IW1FRU (info at haminnovation.com / 
iw1fru at gmail.com)

Best 73,
Lorenzo IU1NSA



More information about the Dxspider-support mailing list