[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