Good morning. I have been using the DXlabs suit for a? while now to control my Icom IC7300. I like it very much. Main use is doing data modes, FT8 PSK31 etc. It has been working well controlling JTDX via Commander. Just lately I have been getting an error message from JTDX saying its lost control, rig error, I click on retry and starts working again. The other thing I noticed is when the transmit period starts the rig isn't being keyed until about 5 or 6 seconds into the cycle. I did initially think it may be RF getting in, but then noticed this error always happened during RX. So, I shut down Commander, reconfigured JTDX to control the rig directly, and all works fine again. So I am assuming theres suddenly and issue between JTDX and Commander?. BTW Commander also works ok standaloan. Any ideas?

73 Nigel G0CQZ

NOD32, no fear and you forget it.

73 de
Salvatore (I4FYV)

As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti Virus / Anti Malware solutions (MS Defender in this case) have reached a new rhetorical level in regards to DXLab applications / exe's. (based on the number of posts)

First off, I'm not suggesting Dave AA6YQ change anything at this point because the effort would be rather high and the migration of currently installed application exe's to the proper location for a modern day operating system bring a level of complexity along with the change... installer changes and proper use of User Access Control (UAC) would be required along with changes to the installer code used by DXLab (digital signing of exe code etc...).? So I'm happy with the way things are and I know that I need to exclude the directory where DXLab applications are installed in my Anti Virus software.? So let me make that clear, I'm not complaining or suggesting that Dave do anything to address why this topic keeps coming up over and over and over and over and over again. Well, other than repeating the current solution and referring users to how you need to exclude the DXLab installation path from your anti-virus / anti-malware solution. The bitching and complaining about controls that are put in place to protect you and other users in what is in effect a shared network (the Internet) is rather comical at this point.

If you want to know why DXLab executables are getting identified as having problems, the problem is not Windows Defender or any other anti-virus / malware solution.? Identifying Defender as the problem, just exposes your ignorance around this topic. In a nut shell, the problem is where the exe's (any any other executable code like dll's) for DXLab are getting installed along with the fact that the exe's are not digitally signed.? If you don't agree, ask a software engineer who has been coding and helping release commercial Windows exe based (rich client) applications for over 30 years.? And it helps if the engineer you are asking has had extensive experience related to using industry standard practices which are designed to help users keep their computers safe. Your lack of understanding about bad actors out there that are trying to exploit executable code and at what OS level this code can execute, is not helpful to the discussion.? Stop acting like you are a 'safe computing expert' when you are not one... especially when you are disparaging solutions that have been put in place to protect you and others despite your own stupidity.?

So for DXLab users at this stage of the game... which I am one of them and very happy with the amazing job Dave has and continues to do an amazing job with this free software offering!? I'm perfectly happy excluding the default directory location where DXLab exe's are installed from my anti-virus software solution as an exclusion.? I'm trusting Dave to not deliver exe based code that is malicious.?And even if it pains me so, I'm letting the DXLab installation process install this executable code (that is not digitally signed) in a read/write location.

If you are happy with what you have and have excluded your DXLab installation path from your anti-virus / malware solution's scans, then you can stop reading now... or you probably never made it this far anyway.? If you want more of the details as to what the industry standard has been for decades now, keep reading.? DXLab has been around so long, it may be hard for Dave to justify a big change (and personal expense to digitally sign things) at this point.? I total get that as I have stated above. However, when other users spew out fear, uncertainty and doubt regarding this topic, they should be corrected and their ignorance should be exposed.?

Solutions like Windows Defender (a darn good free solution) are designed to protect you despite your, ignorance and laziness.? You can give someone a Twenty Dollar Bill for free and then based on their ignorance, they will complain that you didn't give them two Ten Dollar Bills.

For decades now, the industry and creators of commercial operating systems in use in business and at home have tried and tried to make commercial and home computing safer. Linux / Unix based OS's and even MS Windows (make your silly evil sounds and wiggle your fingers in the air), have been trying to get software developers to locate executable code in a OS level protected directory structure.? i.e. for Linux it would be /bin, or /usr/bin etc... for Windows it would be?C:\Program Files (x86) for 32bit executables, and or?C:\Program Files for 64bit executables.? Constrains are put in place to protect the executable code in these directories using an OS level of User Access Control to keep code from executing at a 'root' level or administrator level (in the case of windows) where bad / malicious code could do all kinds of bad things... install key loggers to steal you passwords, or execute code to encrypt all your data and hold you hostage to ransomware schemes.? Or just help use your computing power and network bandwidth to jump start other evil bad things without you even knowing day after day and week after week.

For the above reasons and many others not even listed, modern OS's and their designers do all they can to try and get software installed into protected areas of the file system and to only be run at levels where other bad code can't do bad things without you knowing.? Is it perfect?? nope but it's better than nothing and it's better than just burying your head in the sand and turning off all the protection.

So what is a Mother to do?? The best practices which have been in place for decades now (and are not enforced with a draconian solution yet) are to install executable code in protected directories like, you guessed it:?C:\Program Files etc... AND to locate application down a path specific to data like c:\Documents\YourUserName where read write access to data is based on user privilege's.? ?AND in the case of executable data you digitally sign your executable code with a signature that can be verified by a known good certificate authority. (do a google search on PKI infrastructure if you want to learn more)? this is what virus scanning software is looking at when it scan for issues.? If the exe code of application A is properly signed and in the proper directories, then it's less likely to report a false positive. (yes a pretty simple description of what is going on)

Older software that has been around for a long time gets a bit of a pass on the above, but users are still required to know what is going on when they trust this software.? DXLab applications fall into this category.? Exclude the installation paths from virus scan's / malware scans.? It's just the way it is right now, and only Dave can decide if the effort and cost is worth it to revamp the install locations and incur the cost of executable code signing into his build routines of the VB application in question, not to mention move all the read/write data to User/Document paths and deal with UAC.? The arm flailing and weeping and wailing and gnashing of teeth from existing users of an amazing and free application, would reach an exponential level if they had to move their data around etc.... even if automated in the installer.? I shudder at the flood of questions if this change were made and I'm guessing Dave would fear the same thing on the groups.io list here.? I certainly don't speak for Dave at all.

An example of another amazing and free Ham related application that has adopted most if not all of the above standards is N1MM Logger+.? Multiple developers in this case are coding on the N1MM project. N1MM Logger+ exe's are signed (see the link at the end of this post) and N1MM's installer tries to get you to install the exe's down the proper path in a Windows operating system.? However, as we all know... you can override all of this and in effect disable all the efforts to try and protect you from yourself.? But there is a cost here... time, money and laborious education.? And this requires dealing with a new set of questions from uninformed users.

So, at the end of the day... DXLab users need to understand the current state of how DXLab is coded and how and where it is installed and understand that the exe's are not signed.? It's okay if you understand that Dave clearly isn't out to deliver malicious code, but DXLab, like many other older exe based applications install into a directory structure that violates current best practices in the software industry.? It's just the nature of the technical debt incurred with an older application that has been around for a long time. Again, I'm not suggesting Dave stop the train and crack this nut.? We get the benefit of using DXLab which is an amazing suite of applications written by one super human developer and we just need to understand that the legacy nature of the installation and location of the data and exe's will make it suspect for industry standard virus scanning / malware scanning / bad actor detection software. Stop blaming Windows and modern virus / malware scanning / detection solutions and start understanding and why things were created they way they are.

In the ending of this massive diatribe of mine, executable code on a modern OS needs to be installed in OS / UAC locations and the exe code needs to be signed.? Data needs to be installed in OS / UAC controlled locations where read/write is possible for the processes that need access to this data.? And all executable code should be signed with a known digital certificate that is trusted by a known certificate authority so you a user knows where the code comes from in the first place.? Is it all 100% fool proof?? Nope, but it's better to understand how things work rather than spewing out the continued FUD around this ongoing topic.




Max NG7M??

?

/g/DXLab/message/192460

Worked for me.? Second section.

Don
WB6BEE

开云体育

Just restore the file defender checks and save on the reinstall

开云体育

As of Friday it seems my window defender doesn’t like DXKeeper running on my machine.? I have had to reinstall it three times and every time I do the defender pops up and says that the infected files are being removed.? After getting my backup of the database and re-installing it, it does the same thing.? It starts with 71.9 Archive then installed update 15.4.9.

?

I stopped the real time protection and it stays installed.

?

Am I missing something, this has been working flawlessly for a couple years on this machine.

?

Thanks

?

Bob K4HA

Bob,

you are missing the numerous posts here about recent Windows Defender actions on some DX Lab Suite applications. The minimum you should do is to open Defender, go to History, view quarantined items, select the entry for DXKeeper, and restore it.

You can also make an exception in Defender to exclude the directory where you have DX Lab Suite applications installed. This is optional depending on how you feel about limiting the actions of your AV product.

--
73

Bill

G4WJS.

开云体育

I've been getting the "the connection with ClubLog terminated before the upload completed" message when trying to upload to Clublog. Is this normal until the Clublog servers get back to normal from doing the CoVID-19 research?

From the ErrorLog.txt

I fixed my problem with Propview accessing data by??

• Opening Windows Defender Firewall
• Click Allow an app or feature through Windows Defender Firewall
• Change Settings
• Allow another App...
• Enter your path to Propview

Reboot the computer.

+ AA6YQ comments below

开云体育

开云体育

+ AA6YQ comments below

Thanks for your reply Iain. The reason I brought it up is that I think in past years if you had what was thought to be a high risk Q and it was later confirmed by LOTW the H was changed to an L and the high risk total was reduced by one in the CQ Marathon report.

+ The only automation that DXKeeper has offered in this area (and continues to offer) is the "Marathon Submission" panel's "Confirmed QSOs are low risk". With this option enabled, a QSO whose "Marathon Risk" item is unspecified will be considered low risk if it is confirmed via QSL card, LoTW, or eQSL AG.

<>

+ No version of DXKeeper has ever autonomously altered a logged QSO's "Marathon Risk" item.

73,

Dave, AA6YQ

Thanks for your reply Iain. The reason I brought it up is that I think in past years if you had what was thought to be a high risk Q and it was later confirmed by LOTW the H was changed to an L and the high risk total was reduced by one in the CQ Marathon report.

Julio

On Sat, Apr 11, 2020 at 1:00 PM Julio Peralta via groups.io
<jperalta4@...> wrote:

Today I worked a station I needed for CQ Marathon. I wasn’t 100% sure it was a completed contact because of QRM. I logged the contact and placed an H in the Country Risk block in DXKeeper. Then uploaded the Q to LOTW.

About an hour later I received a LOTW conformation for that Q and now both blocks are showing Y’s. I then did a CQ Marathon Progress Report and find that the QSO for that call and country are still showing H even though conformation for the entry is showing Y.

I also note that in the High Risk CQ Country section of the report the total for countries has not dropped back by one unit.

Shouldn’t the high Risk Country Total have been reduced by one when the conformation was received via LOTW?

I don't think so. Why would you think that? A QSO may be high risk for
some other reason (e.g. there's some question about the validity of
the operation). If you no longer believe your QSO to be high risk, I
think you should adjust your log accordingly.

73,

~iain / N6ML

开云体育

+ AA6YQ comments below

开云体育