eQSL.cc Forum

eQSL.cc Forum
Help!

eQSL.cc Home

Forums Home

Authors

Recent Posts

About

Contact

Joined:	Feb 18, 2018 01:35 PM
Last Post:	Apr 17, 2022 12:50 AM
Last Visit:	Apr 17, 2022 05:33 PM
Website:
Location:
Interests:
Favorite Bands:
Favorite Modes:

Send Private Message

Post Statistics

VK3VM Steve Ireland has contributed to 8 posts out of 11636 total posts (0.07%) in 2,259 days (0.00 posts per day).

20 Most recent posts:

Support - English speaking » Changed QTH - Issue with 2 Records Apr 17, 2022 12:50 AM (Total replies: 1)

Hi Folks,

I have tried EVERYTHING to fix this:

Please check your Callsign/QTH Start Date and End Date in My Profile
You are currently set to only allow QSOs between 11-Apr-2022 06:16 and 31-Dec-2030 23:59
You have 2 eQSLs in your OutBox with QSO Dates outside your current Callsign/QTH start and end dates!
If you do not correct this, you will not be able to send or receive eQSLs properly!
The first one is YD6HLG on 11-Apr-2022 03:54
The last one is YC9LAG on 11-Apr-2022 05:12

Can someone with admin rights please just manually delete these eQSL's for me - that is perhaps the easiest way?

Changing QTH's is NOT an easy process....

73

Steve I
VK3VM/VK3SIR

VK3VM Steve Ireland

General web site suggestions » Recommendation: SWL Tag for Registered HAMs Aug 21, 2021 02:57 PM (Total replies: 0)

Hi,

I am noting that I am rejecting quite a number of QSO's. On reiview and after A LOT OF RESEARCH I have found that many of these are are rejections from HAMs that are reporting as SWL's.

Can facilities please be added so that SWL contacts rather than Actual 2-way contacts can be identified?

I reiterate that I HATE rejecting contacts that I cannot find in the log.

73

Steve I
VK3VM / VK3SIR

VK3VM Steve Ireland

Support - English speaking » Possible Issue: Uploading from DXKeeper Jul 9, 2021 12:43 AM (Total replies: 3)

Further Update

When Proxy Firewalls are bypassed (i.e. Using a Cisco 2821 in NAT-mode) the software uploads appear to complete.

When connected to a security suite that it Suricata based using emergingthreats.net rulesets packet analysis has identified that "responses" appear to be received intermittently. The theory is that responses from eQSL to uploads from DXKeeper appear to be filtered by Suricata-based IPS systems (and its not limited to the IPFIRE system that I am using here from experiments conducted).

It could also be just a bug in Suricata. As to the exact rule from emergingthreats.net I cannot at this stage report back further if it is a rule as examining this issue now becomes low priority.

Yet the primary issue in that DXKeeper just "hangs" when a response is not received and does not time out is still there. Records submitted before a hang should be tagged as submitted in DXKeeper - whihcould be considered a considerable flaw

VK3VM Steve Ireland

Support - English speaking » Possible Issue: Uploading from DXKeeper Jul 5, 2021 07:07 AM (Total replies: 3)

Folks,

Dave is no longer responding to my communication.

More comments supporting issues that I have raised (i.e. it stops dead during eQSL uploads) to the DXLab Forum would support a fix.

Under no circumstances be bullied nor accept bullying from anybody or accept derogatory comments about your competence - especially when issues have been clearly identified.

If this software was in the public domain then may be we could fix this ourselves !

73

Steve I

VK3VM Steve Ireland

Support - English speaking » eqsl to LotW? Jul 2, 2021 11:55 PM (Total replies: 1)

Jille,

Yes.

Download the ADIF log from eQSL of all records:

--> https://www.eqsl.cc/qslcard/OutBoxSelector.cfm and select link "Download log in ADIF format"

Then you can use TQSL to submit this log to LOTW:

--> Sign a log and upload it automatically to LOTW.

BUT... I would not do it directly like this (second step that is) as you may have errors and SWL entries. It is perhaps best to go through a third-party app to get things right first.

I would upload the eQSL ADIF log to a program such as DXLab's DXKEEPER (i.e. http://dxlabsuite.com/ ). With the right configuration set for LOTW uploads you can then submit the entire log directly through DXKeeper to LOTW. See their instructions for getting this right.

73

Steve i
Vk3VM / VK3SIR

VK3VM Steve Ireland

Support - English speaking » Possible Issue: Uploading from DXKeeper Jul 2, 2021 10:51 PM (Total replies: 3)

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

Support - English speaking » Possible Issue: Uploading from DXKeeper Jul 2, 2021 04:31 PM (Total replies: 3)

Hi Folks,

Since the "upload duplicate checking" facilities appear to have been implemented I have experienced intermittent issues uploading single and multiple log entries from DXLab's DXKeeper.

Basically what appers to happen is that a record uploads, and an acknowledgement is not returned confirming that its ok to send the next record ... and this places DXKeeper into an endless loop.

I have made requests for Dave AA6YQ to look at the issue (especially DXKeeper implementing a timeout).

Can SysOps please monitor data coming in from me?

Can SysOps please investigate the issue at their end? Look for log uploads where I have had to delete records and then upload in small clusters or individual records again.

This issue is DEFINITELY NOT my configuration as I am no newbie to any of this and it has only become evident since changes to duplicate checnking and uploads have occurred at the eQSL end.

73

Steve I
VK3VM / VK3SIR

VK3VM Steve Ireland