eQSL.cc Forum

Here is a trail of comms with Dave AA6YQ the DXKeeper Creator.

.........................

Dave,

> What does the "You desktop is currently shared with..." message shown in your screenshots mean?

Google's Browser-based Remote Desktop Service. Garden variety and low impact remote server.

> How long have you been using DXKeeper to upload QSOs to eQSL? When did this behavior first begin?

I have been working FT8 and JT65 for perhaps 5 - 6 years and using DXKeeper most of this time either directly or with JTAlert.

[ Laurie VK3AMA and I have a ZERO relationship ... that is a long story. ]

The behaviour appears to have started when the eQSL people moved to what appears to be a situation where they have actively implemented code to reduce upload duplicates. I would suggest that this is around 12 - 18 months back that the first of these issues arose.

Su yes there are issues I fear at their end... I will provide your last response (as well as this one) to them.

[ I will use the "handshake" here to refer to an anticipated response here ]

But there are also issues I fear at the DXKeeper end as is not handling the non-handshake response nor non-timely response timeout ? When the error situation occurs it is not also registering records that have been sent and handshaken correctly.

I have never discounted an issue somewhere up the line with a caching proxy somewhere (i.e. we have a rather convoluted NBN here in VK and I am in a rural city).

I have also asked a few fellow HAM's about this and my situation may not necessary be unique.

I will reboot the G5 Intel Mac Mini (with Windows 10 as the base OS) now in safe mode with networking and report back results. I will also have a packet sniffer mirroring the connection port on the HP switches that I use before the PC and in the POP loop to see if data is being stopped/filtered somewhere.

Thanks for the time with this. Yet I restate that I can clearly demonstrate that issues I fear that DXKeeper is not handling the eQSL non-handshake responses nor non-timely response timeouts in a fashion that it should? Just the fact that it hangs and stays there (and demonstrated in excess of 3 minutes) should be of concern.

73

Steve I
VK3VM / VK3SIR

-----Original Message-----
From: Dave AA6YQ <aa6yq@ambersoft.com>
Sent: Saturday, 3 July 2021 5:22 AM
To: 'Steve VK3VM' <vk3vm@hotmail.com>
Cc: Dave AA6YQ <aa6yq@ambersoft.com>
Subject: RE: Ongoing issues with eQSL Uploads via DXKeeper and suggestions to mitigate this and future issues

This sequence in the failure case

2021-07-02 17:44:07.340 > eQSL.HandleInetStateChange: icResponseCompleted
2021-07-02 17:44:07.348 > eQSL.HandleInetStateChange

means that response from eQSL contained no data. The "normal case", which occurred earlier in the errorlog, looks like this:

2021-07-02 17:44:06.812 > eQSL.HandleInetStateChange: icResponseCompleted
2021-07-02 17:44:06.812 > theChunk:



<HTML>
<HEAD></HEAD>
<BODY>

Result: 1 out of 1 records added<BR>

Information: From: VK3VM To: JE3JOH Date: 20210702 Time: 1527 Band: 40M Mode: FT8 RST: -21<BR> </CENTER> </BODY> </HTML>

where the data received is an HTML page that conveys the results of the transaction.

So either eQSL is occasionally malfunctioning -- but only for you -- or something is interfering your the network. DXKeeper employs a standard Microsoft component to implement file transfer via TCP/IP.

What does the "You desktop is currently shared with..." message shown in your screenshots mean?

How long have you been using DXKeeper to upload QSOs to eQSL? When did this behavior first begin?

Suggestions:

1. reboot Windows in to "Safe mode with networking" to see if that makes a difference

2. setup a temporary internet connection that bypasses your router, e.g. using a cellphone, to see if that makes a difference

73,

Dave, AA6YQ

-----Original Message-----
From: Steve VK3VM [mailto:vk3vm@hotmail.com]
Sent: Friday, July 02, 2021 1:56 PM
To: Dave AA6YQ
Subject: RE: Ongoing issues with eQSL Uploads via DXKeeper and suggestions to mitigate this and future issues

Dave,

Before performing a "safe mode with networking" restart I just thought that I would test the 60-second timeout.

The issue occurred.

See the log and the two screen prints to verify that the 60-second timeout is not functioning. I have provided the log pre and post aborting DXKeeper.

All firewall facilities on the OS are off. The screen prints will also verify that the only additional non-MS-Standard software running is the relatively inert NMEATime utility (that is a GPS-based time synchroniser). JTDX is the program running in this instance (that should be inconsequential).

73

Steve I

-----Original Message-----
From: Dave AA6YQ <aa6yq@ambersoft.com>
Sent: Saturday, 3 July 2021 3:18 AM
To: 'Steve VK3VM' <vk3vm@hotmail.com>
Cc: Dave AA6YQ <aa6yq@ambersoft.com>
Subject: RE: Ongoing issues with eQSL Uploads via DXKeeper and suggestions to mitigate this and future issues

It was the error log that you first posted that I analyzed.

The current version of DXKeeper does not create an errorlog entry when the eQSL upload timeout expires; the next version does so.

Please try the "boot Windows into safe mode with networking" test when you have time.

73,

Dave, AA6YQ

-----Original Message-----
From: Steve VK3VM [mailto:vk3vm@hotmail.com]
Sent: Friday, July 02, 2021 1:11 PM
To: Dave AA6YQ
Subject: Re: Ongoing issues with eQSL Uploads via DXKeeper and suggestions to mitigate this and future issues

Dave,

Thanks. I have on occasion had the macine sitting overnight. The log supplied was not the same as the deleted one posted that had been sitting for a while.

Thanks also for confirming the timeout :-)

Its a cleanskin Win 10 21H1 deploy with just jtdx, wsjtx, dxlab and laurie AMA's software on it.

I cannot rule out the IPFIRE proxy firewall.

Sent from my Samsung Mobile on the Telstra Mobile Network Get Outlook for Android <https://aka.ms/AAb9ysg> ________________________________

From: Dave AA6YQ <aa6yq@ambersoft.com>
Sent: Saturday, July 3, 2021 2:55:58 AM
To: 'Steve VK3VM' <vk3vm@hotmail.com>
Cc: Dave AA6YQ <aa6yq@ambersoft.com>
Subject: RE: Ongoing issues with eQSL Uploads via DXKeeper and suggestions to mitigate this and future issues

Thanks for the comment re password embedding. Thinking now I was aware but it had slipped my mind.

This is a "facility" that you should write out as you run the ire of this software being reported by someone as a security hazard.

+ There is no security hazard from storing Club Log, eQSL, and LoTW passwords in cleartext.

Back to the issue . Ongoing . with eQSL.

Basically I have had to turn auto-logging from WSJT-X/JTDX through JTAlert to DXKeeper off. Yet when I manually upload a log now (say 10 - 15 records) it gets "stuck" on one (that it has uploaded) and goes around and around in a "circle of death" that DXKeeper cannot recover from. The only solution is to hard-abort DXKeeper.

The log is attached (with the old password not edited out).

The process then becomes messy; all "part-uploaded" log entries need then be deleted from eQSL. Then you upload again in small chunks (i.e. 2 recs at a time) until you hit perhaps another recreod that places DXKeeper into the endless loop of death.

There needs to be a timeout before all further uploads are aborted.

+ There is a 60 second timeout. The errorlog shows that you terminated DXKeeper before this timeout expired.

Perhaps a message needs to be displayed on the timeout-abort to access the eQSL site and manually delete that record where the hang occurs needs to be displayed.

All records processed up to the time of the abort need to be tagged as sent. That is the biggest annoyance.

Nobody else is reporting issues. I do use a commercial-grade proxy firewall - but that has been eliminated as a cause.

+ No one else has ever reported this issue.

I have seen this before . and its only started to occur when the eQSL people implemented technologies to stop duplicates being uploaded.

Yet as I state there are some things that your software, in my opinion, should be performing in order to deal with issues at their end better.

+ There's a 60 second timeout, but at least in the examples you've sent me, you've terminated DXKeeper before it expired.

+ To rule out interference from another application, please reboot
+ Windows into "Safe mode with networking"; then start DXKeeper and
see if the problematic eQSL uploads till occur.

73,

Dave, AA6YQ

VK3VM Steve Ireland