telnet server

[venkatesh457]

how i will write my own telnet server insted of existing one.please give me the path for telnet.c file in the linux kernel

[Brain_Dead]

Why do you want to write your own telnet server?
What distro are you using?

[marksj]

Unless you have an isolated (from the internet) network, I would not advise using any version of telnet. If you are interested in writing code, try an ssh server.

[Rubberman]

I did a complete implementation of telnet, both server and client, about 18-20 years ago for a real-time system. It is not a trivial piece of work. I did it from the DOD White Book specifications, not using any code from anywhere else. I don't remember exactly, but it was probably 10-20kloc. FYI, FTP and telnet share protocols.

[burschik]

how i will write my own telnet server insted of existing one.please give me the path for telnet.c file in the linux kernel

Last time I checked, there was no in-kernel telnet server.

[unlimitedscolobb]

how i will write my own telnet server insted of existing one.please give me the path for telnet.c file in the linux kernel

Well, you generally have to start off with sockets and the simplest possible couple of a client and a server application which basically exchange strings or just buffers. BSD Sockets: A Quick And Dirty Primer -- this tutorial may be a good start for you. Then you may find it useful to just read the source code of a telnet server (and there are several, as I understand it).

By the way, are you sure this is not a homework question? (Sorry for being that paranoic: I've just finished a course in which I had a similar task; no offense meant).

burschik, I don't know of in-kernel telnet servers either. I guess having an in-kernel telnet server would be a waste of kernel resources

[Rubberman]

Telnet is a user-space application, although the telnet server (started by inetd or xinetd) has to use kernel resources as it needs to create a pseudo-tty device for user I/O. Most of my work on the real-time OS implementation of telnet was taken up with writing the telnet tty device driver. Honestly, I don't know what would be required to provide the same services on Linux. Other than that, there were two areas that required significant work. One was the handling of capabilities. This is where the client and server communicate and agree upon a set of functions that both support. Not all telnet functions must be supported on both ends, but both ends have to agree on which ones are. The second area was the terminal emulation capabilities of the client. At the least, it should support ANSI/VT-100 escape/formatting codes (escape sequences) so that applications that utilize termcap, curses, or ncurses libraries can properly format the display.

[unlimitedscolobb]

Telnet is a user-space application, although the telnet server (started by inetd or xinetd) has to use kernel resources as it needs to create a pseudo-tty device for user I/O.

Hm. Quite recently, I wrote a simple server listening to a BSD socket on some port and connected to this server via telnet 127.0.0.1:<someport>. Does this mean I wasn't actually using the telnet protocol? I thought that starting from this point developing a telnet server would be as simple as implementing the support for commands arriving at the server socket... Could you please tell where exactly one needs the pseudo-tty device?

[Rubberman]

From Volume 2, DDN Protocol Handbook, RFC 854, Telnet Protocol Specification:

The TELNET Protocol is built upon three main ideas: first, the concept of a "Network Virtual Terminal"; second, the principle of negotiated options; and third, a symmetric view of terminals and processes.

1. When a TELNET connection is first established, each end is assumed to originate and terminate at a "Network Virtual Terminal", or NVT. An NVT is an imaginary device which provides a standard, network-wide, intermediate representation of a cononical terminal. This eliminates the need for "server" and "user" hosts to keep information about the characteristics of each other's terminals and terminal handling conventions. All hosts, both user and server, map their local device characteristics and conventions so as to appear to be dealing with an NVT over the network, and each can assume a similar mapping by the other party. The NVT is intended to strike a balance between being overly restricted (not priving hosts a right enough vocabulary for mapping into their local character sets), and being overly inclusive (penalizing users with modest terminals).
.
.
.
2. The principle of negotiated options takes cognizance of the fact that many hosts will wish to provide additional services over and above those available within an NVT, and many users will have sophisticated terminals and would like to have elegant, rather than minimal, services. Independent of, but structured within the TELNET Protocol are various "options" that will be sanctioned and may be used with the "DO, DON'T, WILL, WON'T" structure to allow a user and server to agree to use a more elaborate (or perhaps just different) set of conventions for their TELNET connection. Such options could include changing the character set, the echo mode, etc.
.
.
.
3. The symmetry of the negotiation syntax can potentially lead to nonterminating acknowledgment loops -- each party seeing the incoming commands not as acknowledgments but as new requests which must be acknowledged. To prevent such loops, the following rules prevail:
.
.
.

and so it goes on for 160+ pages.

[Rubberman]

FYI, TELNET commands from client to server (and vice versa - they are orthogonal, like the negotiating protocols) are encapsulated in "escape" sequences. In effect, it is its own language and rules of syntax at the least have to be adhered to. It took me about 3 months to complete the implementation of the entire protocol, client and server, so that it would communicate with any known system. To do this, I had to implement very sophisticated finite-state-machine drivers as well as the rules to drive the state machine. In any caes, just to do the client-side of the protocol is a significant bit of work, at least to do correctly.