[ECOS] Re: telnet

Bart Veer bartv@redhat.com
Mon Aug 21 05:57:00 GMT 2000


>>>>> "Joerg" == Joerg Troeger <jtroeger@nortelnetworks.com> writes:

    Joerg> From: Gary Thomas <gthomas@redhat.com>
    >> On 21-Aug-2000 Joerg Troeger wrote:
    >> > Is there a hope for getting telnet access also in the short future?
    >> 
    >> Exactly what would you use 'telnet' access for? Since telnet is
    >> used for interactive connections to a "host", it doesn't seem
    >> to have a lot of application here.

    Joerg> Gary,

    Joerg> our embedded system will be the "host".

    Joerg> In our embedded system we need:
    Joerg> - TCP/IP access for the application
    Joerg> - DHCP for diskless system comeup/software verification and
    Joerg> update mechanism
    Joerg> - SNMP for management support from the customers network
    Joerg> admin and
    Joerg> - telnet access for special vendor configuration, debug &
    Joerg> support purposes.

    Joerg> Our lab-system has a serial interface, which offers some
    Joerg> special powerful builtin "shell commands". This serial
    Joerg> interface will vanish in the release system, therefore
    Joerg> thecommands should be available via telnet also. It gives
    Joerg> us the opportunity to have a close look at our system via
    Joerg> remote access. "Telnet access" means network files for
    Joerg> stdin & stdout, a network tty or something else.

    Joerg> This sort of telnet access seems to be widely spread to
    Joerg> network-aware embedded systems.

    Joerg> Should we spent effort in implement telnet support by
    Joerg> ourselves (this seems stupid if redhat is doing the same)?

I think the confusion here is because of the term "telnet". This
implies a telnetd running under eCos (possibly inetd as well), pseudo
terminals, fork()'ing and exec()'ing a shell, and having the shell
fork and exec commands loaded of a disk somewhere. That sort of
functionality is not appropriate for eCos.

However, having a dedicated interpreter (Tcl, Python, hand-crafted,
whatever) embedded into your application, accepting connections on a
specific socket and responding to selected commands on that socket,
would be a reasonable approach for many applications. Having
pseudo-tty support may or may not be appropriate: it might make things
a bit easier for the interpreter, but there is a risk that a lot of
the pseudo-tty functionality would never be used yet still consume
code and data space.

AFAIK Red Hat is not currently working on anything along these lines.

Bart Veer // eCos net maintainer


More information about the Ecos-discuss mailing list