[Dxspider-support] telnet echo

[Mike McCarthy, W1NR]

Well, it's been 20 years since I worked on the actual protocol but
telnet is supposed to do "negotiations" as to the state of echo, line
mode, end of line, terminal type, etc.  Many of the client/server
combinations do not handle it properly and, if there is a negotiation
problem, usually defaults to the "wrong" method.

In the case of DXSpider, the telnet server is provided by the perl
libraries.  As Dirk pointed out, there is a difference if you use port 
23 or something else.  If you connect to dx.w1nr.net port 23, both the
Windows and SuSE Linux clients fail to negotiate linemode (crlf) and you
end up with a <RETURN> key that is not recognized properly.  However,
connecting to dx.w1nr.net port 7300 and now it works as expected.  My
node listens on 7300 and uses the Linux firewall to redirect port 23. 
This points to a client issue.  In Linux, forcing linemode with the
.telnetrc file can fix this and the echo issues.

PuTTY, WriteLog, DX Lab Suite and XMlog telnet clients all seem to do
the right thing without modification with the exception of echo.  One of
the things I do is use a different ssid, W1NR-2 as the connection from
my logging programs.  This user has it's own set of filters and has echo
turned off in DXSpider.

Maybe someday I'll have the time to dig into the perl library and take a
look at the negotiations as the connection is made and find out what the
"real" reason is behind it all.

Mike, W1NR


Paul Pescitelli wrote:
> Dirk, et all....
>
> I am extremely curious about the telnet echo problem from client
> windows machines. I also see a slight problem when telnetting from Mac
> OSX in that the carriage returns do not accept properly.
>
> Is the current status for the telnet connections to just get by with
> the weirdness? Where does the issue come from?
>
> I am fairly new to DX Spider and would like to better understand the
> history and is it viewed as a problem that needs to be fixed ?
>
> regards,
> Paul K4UJ
>