Fwd: Re: [Dxspider-support] Spider Client login - Port 23 revisited

Kelly Jones kjones at sullivan1.com
Fri Feb 7 15:01:38 GMT 2003


Not sure if this made it though the list last night or not.  I didn't a 
copy back, so I'm sending again just in case.

Kelly - KE9KD


>Date: Thu, 06 Feb 2003 19:22:51 -0700
>To: dxspider-support at dxcluster.org
>From: Kelly Jones <kjones at sullivan1.com>
>Subject: Re: [Dxspider-support] Spider Client login - Port 23 revisited
>
>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