[Dxspider-support] Connection Closed by Foreign Host

[Dave Trainor]

Thank you Dirk.  I believe that is the issue, being on port 23 is what is
causing this because the Linux telnet in this case wants to do as you say
and speak telnet.
While I am not at a security risk, there is still a catch I was unaware of
just by the fact I was using 23, and my thought was that it would be
easier and I would not have to explain to my non computer savvy users what
a port number is and how to telnet to a port other than 23. Obviously that
was faulty thinking.

I will simply create another publishing rule for 7300 and then advise them
to use that 
port, while leaving 23 in place for a short time for those currently
connecting just fine.

So I created this issue myself, usually works that way.

Thanks for your help, learn something new every day.

73 - Dave N8ZFM






On 1/29/15, 11:24 AM, "Dirk Koopman" <djk at tobit.co.uk> wrote:

>On 29/01/15 15:24, Dave Trainor wrote:
>> Its actually not on port 23, my firewall rule is.  The box itself is
>> listening on 27753 and I have a firewall port forwarding rule that
>>listens
>> on the assigned IP address and port forwards port 23 to 27753 on the
>> actual box.    So its really not on port 23, this keeps the box safe as
>> all other ports are not accessible.  I know this rule is working fine
>> since I have many other users, its only this one.
>>
>
>Ok. However, that still leaves the telnet protocol problem, because any
>telnet program that connects to port 23 will be expecting the node to
>speak telnet protocol and, frankly, DXSpider doesn't. Port 23 isn't
>simply the "well known port" for telnet, there is always some behind the
>scenes chitchat that the user never sees. This *only* occurs when a
>telnet program connects to port 23. If the same program connects to any
>other port, it's just a straight through connection with no added
>protocol.
>
>It is perfectly normal for all characters to be echoed for all logins.
>It will not affect anything. Try connecting to gb7djk.dxcluster.net port
>7300 with telnet to see what I mean. What is more relevant is which
>telnet client is he using? Native windows telnet programs are
>notoriously buggy, has he tried putty (or puttytel)?
>
>Alternatively you could establish another listener on (say) port 7300 or
>allow people to come in direct on port 27753 and see whether that has
>any effect.
>
>Dirk
>
>
>_______________________________________________
>Dxspider-support mailing list
>Dxspider-support at dxcluster.org
>http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>--
>This message was scanned by ESVA and is believed to be clean.
>Click here to report this message as spam.
>http://h0stname/cgi-bin/learn-msg.cgi?id=496D828C65.882A4
>
>