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