[Dxspider-support] Spider Client login - Port 23 revisited

Kelly Jones kjones at sullivan1.com
Fri Feb 7 02:22:51 GMT 2003


HI Dirk, et al...

See my comments below:

>Good, tick, see me afterwards for extra homework :-)

Only if it's extra credit.  ;-)  Otherwise I'll go run and hide. :-o

>The practical one is: Microsoft (in particular) does not observe the
>rules itself when it comes to its telnet client implementation (neither
>for port 23 nor for 'other' ports). It flatly refuses to negotiate
>(which is what the protocol does) the various editing, line discipline
>and echoing options that a telnetd offers and the defaults are not
>really what you necessarily want to use for the node.

Having run DX-Central now for nearly 4 years, I can tell you that a lot of 
people still use the default M$ installed telnet client.  I found that hard 
to believe and still surprises me, but at least once a week a get an email 
from so-n-so asking why they can't log in or see anything they type when 
they click the link from the web page.  So I politely explain how that 
client is junk and offer some suggestions.

>I will see if I can ignore the protocol safely for all clients that I
>have access to. If that is the case then I will issue an update. But I
>have to say that I have a nasty feeling that when I did this originally
>I could not make it work correctly for both M$ *and* unix clients on
>port 23 using their default settings.

That would be great!  I'll be happy to test with the clients I have 
available as well.  Just say when!

>Another philosophical (and practical) point: In order to use port 23 you
>either have to run the node as 'root' (or with supervisory privs). This
>is expressly forbidden in the documentation. The way round it is to do
>as you are, which is to use (x)inetd. This however (for any quantity of
>users) is really very wasteful of resources because you will have an
>extra process and another two sockets per user.

Currently the telnet box is not providing any additional services so I 
don't think this would be an issue, in my situation anyway.

>Is there anyway at all you could see yourself arranging for a small
>shell script to run which puts up a message to say: please login to
>telnet://xx.yy.com:7300 (insert URL+port here) and then use the internal
>listener to deal with incoming connections?

Actually I tried this once and it didn't work.  Here's the problem.  Since 
DX-Central has been around for about 4 years, it seems that the cluster 
address has been included in many ham related software packages.  When I 
first opened up a telnet cluster I used port 6904.  My reasoning was that 
it was such an oddball port nobody would mess with it.  I had port 23 
disabled at the time for security purposes.

After the telnet cluster started to become more popular, I ran into 
instances where people could not set the port number in their software 
packages, it was either port 23 or nothing.  Begrudgingly, I opened port 23 
as a way for the "non-configurable software" to connect to the cluster.  I 
have since tried twice to kill port 6904 and it appears about 1/2 of the 
users are *still* using that original port!

4222 came along the 2nd time I tried killing 6904.  It was intended for 
node-node connections.  I actually had two boxes running at that time, one 
using 6904/23 and a "node only" box on 4222.  My attempt was to try and 
separate some of the load by splitting the traffic and processing.  I 
somewhat quickly decided that the "two box" setup didn't make much 
difference and moved everything back to a single node.

Bottom line is that when I try to close a port, 1/2 of the users disappear 
and I start getting emails complaining that they can no longer connect.  So 
rather than having to deal with that headache, I would prefer to just leave 
status quo and open the ports to Spider.

<rant>
I'm amazed at the lack of knowledge when it comes to computers amoung our 
ranks.  Most can figure things out when they can't connect, but there seems 
to be a large percentage that are clueless when it comes to changing a 
simple script or port change.  So in an effort to make things easier on 
myself, I try not to rock the boat too much.  ;-)

The main issue (as I see it) is that DX-Central has been around long enough 
that it's been included in numerous software packages - which I think is 
great, BTW.  But when I change things on my end, it tends to upset some of 
the troops.  That's one of the reasons I've let CLX run for as long as it 
has.  Within the last week, the opportunity presented itself to make the 
switch, so I bit the bullet and ran with it (although install in Slackware 
can test one's patience ;-o ).

I think you have a great product Dirk.  Don't get me wrong, no complaints 
here.  I've been watching the list for well over a year.  I'm just trying 
to find a "fix" so I can keep the campers happy.  ;-)
</rant>

Thanks for all of your hard work!
Kelly - KE9KD








More information about the Dxspider-support mailing list