At the upper stack levels uIP brings some protocol and application support. weAutSys adapted and uses some of those (DHCP, ARP, DNS) as well as implementing some other protocols (like Telnet, NTP client).
weAutSys' Telnet server implementation exposes the system and (optionally) user software command line interpreter to the Ethernet. This can free the UART (also usable for CLI) for other purposes. Up to the common maximum connection number multiple CLI clients — plus one at the UART — could be served.
In favour of the embedded controller's resources and communication load this Telnet server assumes respectively insists on (kludge) line mode. So, not much is done on mode negotiation and nothing for special client side terminals.
For the same reasons this Telnet server does nothing on encryption or authentication. This is justified by the assumed configuration having a separated private LAN segment for all automation modules plus their supporting central servers and HMI stations. Should one of these servers bridge the automation LAN to the outside world it must take the security burden.
To find Telnet clients that could handle the said simple line mode without causing any troubles or complications proved surprisingly difficult for a variety of platforms. Using the Frame4J tool ClientLil by
java ClientLil -telnet 192.168.89.343 -v
on any (Windows, Linux etc.) platform with a standard JDK/JRE (1.6.0 or higher) with Frame4J ( jar 1.07.02 or higher) as installed extension.
Files | |
file | telnet.h |
weAutSys' system calls, services and types for the Telnet server | |
Defines for Telnet command, state and options | |
This is a subset of the command and option codes defined for the Telnet protocol. The use of the others not put here is discouraged. | |
#define | IAC |
Telnet: interpret as command (IAC) | |
#define | DONT 254 |
Telnet: option negotiation command respectively answer. | |
#define | DO 253 |
Telnet: option negotiation command respectively answer. | |
#define | WONT 252 |
Telnet: option negotiation command respectively answer. | |
#define | WILL 251 |
Telnet: option negotiation command respectively answer. | |
#define | LINEMODE 34 |
Telnet option code. | |
#define | SUPPRESS_GA 3 |
Telnet option suppress go ahead. | |
#define | TEL_SB 250 |
Telnet command opening brace SB. | |
#define | TEL_SE 240 |
Telnet command closing brace SE. | |
Functions | |
ptfnct_t | telnetAppcall (void) |
Handle Telnet server events. | |
void | telnetInit (void) |
Initialise the Telnet (server) |
#define IAC |
Telnet: interpret as command (IAC)
All Telnet commands consist of a sequence of at least a two bytes:
The commands dealing with option negotiation are three byte sequences:
Sub-negotiation are at least five bytes long and are structured as:
IAC SB information byte(s) IAC SE
The value of IAC is 255 or 0xFF.
The value will also be used as (Telnet command interpreter) state.
If 0xFF
is part of the data it has to be escaped (by doubling it). I.e. IAC IAC does not act as command but as normal data byte 0xFF
.
#define DONT 254 |
Telnet: option negotiation command respectively answer.
DONT
demands (other) no longer to perform indicated option. The positive acknowledge is a corresponding WONT command.
The value will also be used as (Telnet command interpreter) state.
#define DO 253 |
#define WONT 252 |
Telnet: option negotiation command respectively answer.
WONT
refuses (to continue) the indicated optiond. The positive acknowledge is a corresponding DONT command.
The value will also be used as (Telnet command interpreter) state.
#define WILL 251 |
#define TEL_SB 250 |
#define TEL_SE 240 |
void telnetInit | ( | void | ) |
Initialise the Telnet (server)
This function initialises the Telnet server. It is (indirectly) called whenever the Ethernet link goes up and hence usually after reset.
At present the implementation does nothing, but that may change in future releases.
ptfnct_t telnetAppcall | ( | void | ) |
Handle Telnet server events.
This function handles all Telnet events. And it is a as a protothread (part of) the Telnet server state machine.
This Telnet server implements the basic communication, a CLI (command line interpreter) and a log buffer consumer. The appstate part of the connection state hence is thread data of type thr_data_t in the cliThr_data_t variant.
The current appstate.flag usage is:
Bit 0 (1): command interpreter active
Bit 1 (2): prompt output (after last output) pending
Bit 3 (4): consume and send the pending bufLogStreams output (before prompt).