[Dxspider-support] The results are in for today (so far)

Kin ea3cv at cronux.net
Thu Feb 13 14:21:15 GMT 2025


Dirk,

If Lee is not using the PC92Cs, why disable them? I guess he will throw them away if he uses them. He only sends A and D. 

Kin


-----Mensaje original-----
De: Dxspider-support <dxspider-support-bounces at tobit.co.uk> En nombre de Dirk Koopman via Dxspider-support
Enviado el: jueves, 13 de febrero de 2025 15:03
Para: Kin via Dxspider-support <dxspider-support at tobit.co.uk>
CC: Dirk Koopman <djk at tobit.co.uk>
Asunto: Re: [Dxspider-support] The results are in for today (so far)

Lee VE7CC-1 seems to have disabled PC92 C records.

Now, in the dim and distant past I think I recall Lee saying that he cannot handle PC92 C records with user/IP addresses from large nodes like WA9PIE-2 with > ~800 users regular users. This is why, I think, the $DXProt::pc92c_ipaddr_enable parameter was set to 0 by default (it was 1 originally). These records (with [especially IPV6] addresses get very large. Not a problem for perl programs but for compiled languages like Visual Basic it is.

In light of this, please set $DXProt::pc92c_ipaddr_enable back to 0 if you have it set 1. Whilst it is useful to have the IP address in the
PC92 C record but this information is also accumulated, over time, in
PC92 A records in the user file.

Also, if you find yourselves in the situation where you are not getting
PC92 records from VE7CC-1 then disconnect him and the problem should resolve.

NOTE: sender verify will only occur with nodes that have sent at least 1
PC92 C record.

If a node can send a PC92 C, but has not yet done so, or your node has just restarted and has not got one yet, then no sender verification is done.

73 Dirk G1TLH

On 13/02/2025 07:49, Kin via Dxspider-support wrote:
> Mike,
>
> Yes, spots originating from VE7CC-1 are validated.
> I can see users associated with VE7CC-1, but only about 10% of the 
> number it claims to have.
>
> One of the fundamental issues with the cluster network is that not all 
> nodes within the network use the same protocols. Even when they do, 
> they are not configured in exactly the same way.
>
> There are CC Cluster and DXSpider nodes that have the capability to 
> use PC92 statements, but not all of them have this feature enabled. 
> Even among those that do, some do not send IP addresses, or the ones 
> they send are not the real ones.
> Other systems, such as AR Cluster, DXNet, and AK1A, do not even 
> implement it.
> Then there are nodes that have not been updated in decades and 
> therefore lack modern functionalities.
>
> This results in a heterogeneous network, making it extremely difficult 
> to orchestrate a reliable mechanism to counteract bad spots and impersonations.
> For this reason, I personally believe in classifying spots based on 
> the reliability of their originating node.
>
> I don’t understand why some sysops are reluctant to enable the 
> transmission of the user’s IP address. It’s as if they think it 
> compromises privacy, but they don’t seem to realise that every time a 
> connection is established over the Internet, an exchange of IPs occurs 
> as dictated by the TCP/IP protocol itself. If that data were not 
> transmitted, the connection simply would not be established.
> Therefore, enabling this feature does not violate any rules or laws.
>
> If we run:
>
> stat/chan ea4ure-2
>         Access Group: local
>             Callsign: EA4URE-2
> 		...
>         Handles PC9x: Yes      <----- *****
>
> We can check whether our node has PC9x enabled or whether any other 
> node uses these statements.
>
> I’d like to take this opportunity to ask everyone to make sure they 
> execute the following commands:
>
> set/var $DXProt::pc92_ad_enabled = 1
> set/var $DXProt::pc92c_ipaddr_enable = 1
>
> This enables the transmission of connection and disconnection 
> information for nodes and users, which is essential in tackling issues 
> related to bad spots and impersonations.
>
> Kin EA3CV
>
>
> -----Mensaje original-----
> De: Dxspider-support <dxspider-support-bounces at tobit.co.uk> En nombre 
> de Mike McCarthy, W1NR via Dxspider-support Enviado el: miércoles, 12 
> de febrero de 2025 21:44
> Para: dxspider-support at tobit.co.uk
> CC: Mike McCarthy, W1NR <lists at w1nr.net>
> Asunto: Re: [Dxspider-support] The results are in for today (so far)
>
> Do ANY VE7CC spots validate? "show/config ve7cc-1" shows no users so 
> there is no way to validate those spots in this manner. He is probably 
> not sending user data out. I also noticed that nearly every node I 
> checked is short a couple calls in my node.
>
> On 2/12/2025 3:11 PM, Erwin Fiten via Dxspider-support wrote:
>> I did a test right now, I have only enabled it for 30mins.
>>
>> VE7CC-1, 55.56%
>> EA4RCH-5, 9.52%
>> AE5E, 7.94%
>> EA6VQ-2, 5.56%
>> NC7J, 5.56%
>> DO5SSB-2, 4.76%
>> DH1TW-2, 3.17%
>> PY1NB-4, 3.17%
>> GB7DXM, 1.59%
>> W3LPL, 1.59%
>> EA4URE-3, 0.79%
>> ON4KST-2, 0.79%
>> Bad spots: 126%
>>
>> Some strange results, VE7CC 55% & Bad Sports : 126% Node has an 
>> uptime of 7 days (running DXSpider V1.57 build 564)
>>
>> Erwin, Sysop ON0NOL-9
>>
>
> --
> 73 de Mike, W1NR
>
> THAT was the equation. EXISTENCE!... SURVIVAL... must cancel out...
> programming!
>
> - Ruk -
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support


_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support




More information about the Dxspider-support mailing list