[WT-support] Problem with wtDxTelnet V2.0

[Dave Zeph]

Sorry I didn't reply right away, Larry.  The xyl and I went down the
mountain to look at other cabins for next year.  The owners of the place
where we stay are going to start coming up for October's beginning next
year.  It's hard to find a place that will allow out Labrador Retriever -
and which is oriented the correct direction for HDTV reception!

My answers are below ...

To answer a question from your previous message, I changed the Security
Permissions on the C:\Program Files\Win-Test and C:\Program Files\DLPortIO
Folder to grant Users FULL CONTROL.  I also did this to Desktop Startup
Shortcuts, to the C:\Documents and Settings\Contest_User Folder, the
C:\Docuements and Settings\All Uses\Start Menu\Programs, and the
C:\Windows\System32\Drivers Folder where DLPortIO.SYS is located.



73 ---> Dave, W9ZRX






-----Original Message-----
From: support-bounces at win-test.com [mailto:support-bounces at win-test.com] On
Behalf Of Laurent HAAS - F6FVY
Sent: Thursday, 02 November, 2006 17:04
To: support at win-test.com
Subject: Re: [WT-support] Problem with wtDxTelnet V2.0

Hi Dave

Olivier F5MZN a écrit :

> - Did you try to enter commands in wtDxtelnet itself?

Yes, I tried entering commands into the Command Area at the bottom of the
wtDxTelnet Window.  I did not see them transfer to the upper Window, and pf
course there was no response from the Cluster

> 
> - Did you try to enter commands in WT from the 160 multiplier station 
> (same computer wtDxTelnet was running on)?

I tried entering Cluster Commands via the ALT-T Window on the 160 Multiplier
PC, and other Band-Position PC's as well.  I also tried the SH/DX "Button."
When OUTBOUND communication was lost, no Commands could be sent to the
Cluster.

> 
> - Was the QSO and GAB received by WT on the 160m multiplier station when 
> wtDxTelnet was in default?

The 160M Multiplier station continue to operate normally.  QSO's were being
recorded as they were made by the other positions, and GAB never failed.
Out "GAB" file must be HUGE!!

- Does the "internal" WinXP firewall engaged on the 160m PC ?

The Windows-XP Firewall is engaged on all of the LAN PC's.  Exceptions have
been made for specific Ports and/or Programs.  The exceptions are for:

1) Remote Administrator
2) AVG AntiVirus
3) Win-Test
3) wtDxTelnet

- Any other third-party FW enabled ?

1) AVG AntiVirus
2) Remote Administrator
3) DLPortIO
4) HamCap / Ionoprobe (was not restarted after the first restart of 160Mult)
5) Diskeeper V10
6) Adobe Acrobat Reader Quick-Start (loads via STARTUP)
7) All, except for HamCap / Ionoprobe run as Services

And as I said above, HamCap & Ionoprobe were manually started after Win-Test
was loaded - and were not reloaded on to the 160M PC after the first time
where I logged the CONTEST_USER OFF and back ON.

- Have you tried other DX-cluster, different of N3RA ?

Yes and no.  Initially we had a Multi-Cluster Spot Sucker running on the
1Ghz STATUS PC.  This used K1TTT's WintelnetX program.  To interface with
wtDxTelnet, the output of the Spot Sucker was routed within WinTelnetX to
it's internal Telnet Server.  wtDxTelnet then connected to this Telnet
Server.  This HAS EXACTLY THE SAME PROBLEM.  Not knowing if this was causing
the problem, I turned off the Spot Sucket, turned off wtDxtelnet on the
STATUS PC, and ran wtDxtelnet on the 160 Multipler PC connecting to just a
SINGLE CLUSTER - and we had the same problem.

- I guess you set static IP addresses for every machine ? What class is 
your network and what subnet mask and broadcast address are you using ? 
Check all data are consistent across the network and for both apps (WT 
and wtDxTelnet).

All of the PC's have manually Assigned Static IP Addresses in the
192.168.1.x subnet.  The STATUS PC is 192.168.1.2.  The remaining 12 PC's
have addresses starting at 192.168.11, and going to 192.168.1.22.  There is
also another PC, located away from the shack, that is available for WEB
Browsing / WEBMain - 192.168.1.3.

The Subnet Mask on all PC's is 255.255.255.0

The Broadcast Address is 192.168.1.255 - Port 9871.  I rather doubt this can
be a problem because the Internal Network Functions (Logging, Gab, Frequency
Status, and etc. worked without any problem.

APPLICATION ID - TELNET

DISABLE COMMUNICATIONS WITH WIN-TEST is NOT CHECKED


The only problem we had is that wtDxtelnet's OUTBOUND communication would
"quit."



73

Larry - F6FVY

_______________________________________________
Support mailing list
Support at win-test.com
http://www.f5mzn.org/cgi-bin/mailman/listinfo/support