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

[Dirk Koopman]

On Thu, 2003-02-06 at 23:36, Kelly Jones wrote:
> Hello everyone,
> 
> I have done some poking around with the client.c source and found the 
> following....
> 
> If I attempt to login to port 4222 or 6904 everything appears to work 
> correctly.  However, when using port 23 I get unpredictable results.
> 
> Login attempts with both KE9KD and KE9KD-8 result in "invalid callsign".  I 
> modified the C code slightly to see where the hangup was.  Below is the 
> modified code.
> 
>                  case WAITLOGIN:
>                          for (i = 0; i < mp->size; ++i) {
>                                  UC ch = mp->data[i];
>                                  if (i < MAXCALLSIGN) {
>                                          if (isalpha(ch))
>                                                  ++hasa;
>                                          if (isdigit(ch))
>                                                  ++hasn;
>                                      if (isalnum(ch) || ch == '-')
>                                                  callsign[i] = ch;
>                                          else
>                                                  die("invalid 
> callsign");  <---- Appears to fail validation here
>                                  } else
>                                          die("Invalid Callsign");
> 
> 
> I'm not a C coder, so I'm not really sure what I'm looking at.  I looks 
> like a test for Alpha and Digits in the callsign, but not sure exactly what 
> it's doing.

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

There is an issue with port 23 which the client doesn't address, which
is that there is actually something called 'telnet protocol'. This
should be used on port 23 and must not be used on other ports. Now to
cut a whole load of squit short, I should probably handle this better.
My problem with this I suppose is on the one hand philosophical and, on
the other, practical.

The philosophical one is: should you use port 23 for what is, after all,
not a telnetd (ie a program that starts a shell on the target computer)
and doesn't implement the specified protocol.

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. 

This whole area is a compromise. It was a subject of much debate and
experiment in the early days and this is frankly the first time that
this has come up for a very long time. 

I think what I will do is try to fix (or to be more exact: kludge) the
basic issue.  It is now unlikely that the client is ever going to handle
binary data (this was one  of the issues that caused me concern).

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.

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. 

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?

Dirk G1TLH
-- 
Please Note: Some Quantum Physics Theories Suggest That When the
Consumer Is Not Directly Observing This Product, It May Cease to
Exist or Will Exist Only in a Vague and Undetermined State.