[Dxspider-support] Existing Telnet Connection Forcibly Closed ???

Dave Wilson n4dw at chartertn.net
Wed Jul 15 19:50:50 BST 2015


Hi All,

I am perplexed!

This summer has been a little rough power wise.  Many power outages due 
to weather related events.
A power outage can be a matter of seconds or several hours.

For the past several months occasionally after an outage my internet 
users will have difficulty staying connected, including myself from a 
second pc.
I can best describe what I see on the second pc as the other users are 
all using a variety of software to connect/autoconnect and they possibly 
are not seeing the same errors, just reconnects.

First off, the cluster pc is a Win7 64bit machine that has been running 
almost continuously since at least 2013.
The cluster is DX Spider Cluster version 1.55 (build 0.166 git: 
4868adf[i]) on MSWin32. I use CVS to update somewhat frequently.
The cluster pc connects to the wireless router that is 6 feet above it 
and the router connects CAT5 to the modem and they are less than a foot 
apart.
I normally monitor the cluster activities at this pc from a Command 
Prompt window and connect ==> TELNET localhost 7300.

Next, the shack pc, in a room some 50 feet away on the same floor as the 
cluster is also connected wireless ==> Telnet n4dw.no-ip.org 7300 
normally using N1MM, but can also be from other software individually or 
at the same time using different ssid's.
This pc is also a Win7 64bit machine and has been running since 2011.

My provider is Charter (or whatever name they use this week) and they 
have been a pretty good ISP since the early 2000's.  With DXSpider 
connected 24/7 I am able to hold an IP for extended periods, ie. more 
than 6 months at a time.  I cannot recall Charter ever forcing an IP reset.

And now my problem:
After a power outage and a restart of all devices: modem, router, 
cluster pc, shack pc I begin noting that the shack pc cannot stay 
connected to the cluster and an error window pops up stating "An 
existing connection was forcibly closed by the remote host".

 1. I understand that the existing connection is N1MM connected to the
    cluster via Telnet n4dw.no-ip.org 7300, but what is the "remote host"?
 2. Does that mean that the DXSpider node n4dw-9 has forced the disconnect?
 3. If so how do I determine the reason for the disconnect?
 4. Or is there something else in play?
 5. And why has this just recently been occuring?

My N1MM will auto reconnect using n4dw-1 after about 2 minutes of being 
disconnected.  Total connect time is somewhere between 2 minutes and 10 
minutes before being "forcibly closed" again.

I have shut every device down: modem, router, both pc's.  Let them set 
for a few minutes and restart each in that order, giving each a chance 
to completely boot before starting the next device.  The cluster pc 
needs to be 192.168.1.100, so it is the first pc to be started, then the 
node is started before bringing up the shack pc.

Most often after a few minutes of shack pc being connected to the 
cluster it will be "forcibly closed".  Occasionally, the every device 
shutdown and restart results in no further problem.

At one point I thought that I had a wireless router problem so I changed 
out the long running Linksys WRT54G with a Linksys 1200 and still have 
the same problem.

Then I compared the time in both pc's, even resetting both at near the 
same time using nist or some other time standard.

After fiddling with it for a while, It seemed as if magically the 
problem would go away, then after the next power blurp or outage, again 
comes the "forcibly closed" error.

I do a sh/log <call> for those users that normally connect and they as 
well as I show being connected, disconnected then reconnected ==> again 
and again and again ~~~.

I can usually stumble my way through problems like this, but this one 
has me completely buffaloed.

Any assistance will be gratefully accepted.

TIA,
Dave
N4DW



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20150715/d5347f18/attachment.html>


More information about the Dxspider-support mailing list