Elks SSH client

[rafael2k]

Hi there! Is there any ssh client for Elks?
I realized there is SSH2DOS, which does support real-mode and 8086 natively:
https://sshdos.sourceforge.net/history2.txt

[rafael2k]

It is an Open Wattcom project (DJGPP support removed around version 0.1), with realmode-8086 project target:
https://github.com/AnttiTakala/SSH2DOS

It uses the large memory mode for compilation.

[ghaerr]

We don't have an SSH client for ELKS.

The SSH2DOS project looks interesting, but there's lots of work to use it for ELKS. A quick look shows the following issues which would need to be handled somehow:

• large executable: the ELKS compiler doesn't support large model (=far code/far data), only far code with a limit of 128kb. This means the programs may not actually link if they're too large, and each source file may have to be modified to include __far to support far pointers, along with new memory management routines for allocations and possibly far libc routines.
• 32-bit int default: some source looks like it requires 32-bit int as default. All cases would have to be looked at and long substituted instead in each source file.
• watcom TCP: the programs use a non-standard DOS-based TCP/IP instead of Berkeley sockets. Most of the lower level networking routines need to be rewritten for ELKS (Berkeley) sockets.
• testing: deep knowledge of SSH is likely required to get this all working, given the above.

[Oichkatzelesfrettschen]

My understanding is right only 12% of the time. But here are some of the issues I'm trying to imagine to expand upon your list and then just sort of dream-scribble some ideas based on "what I know." :

• ELKS supports only far code up to 128KB.
• Would need to refactor the code to use __far pointers ... (annotate data structures and functions with __far) ... and implement new memory management routines of some kind.
• Split large functions into smaller segments if they exceed 128KB
• Replace 32-bit ints with long types in all relevant source files... search for int declarations and replace with long where 32-bit is assumed...
• Adapt tcp_connect to use socket, connect from ELKS.
• Replace tcp_send, tcp_receive with send, recv calls.
• Replace net_init with ELKS network initialization stuffs
• Adapt net_close to clean up ELKS socket resources properly.

So tcp_connect would be:

int sockfd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in server_addr;
// Set up server_addr with IP and port
connect(sockfd, (struct sockaddr *)&server_addr, sizeof(server_addr));

Send and receive:

int bytes_sent = send(sockfd, buffer, length, 0);
int bytes_received = recv(sockfd, buffer, length, 0);

Then the magical task of initializing the ELKS network stack...

net_init(); // Ensure ELKS network stack is initialized

And saying goodbye...

close(sockfd); // Close the socket using ELKS API

Easy peasy, right? Eeeeep.

[ghaerr]

Hello @Oichkatzelesfrettschen,

Yes, you're pretty much correct overall in your assumptions when using the ia16-elf-gcc compiler and linker, along with the current ELKS kernel. More specifically though, the 128k code size is the limit for all functions combined, not just one function. Using __far pointers can work, but even their use is limited to an array or object that's 64k or less. Much more reengineering would be required if a program needs access to a larger object from a single far pointer.

Finally, send and receive aren't actually implemented, only read and write and only TCP, no UDP functionality or IP layer access. This probably isn't a problem, but it'd be a show-stopper if the application required special flags or UDP.

I have just learned more about the possibilities of using Watcom C for ELKS applications, which could help greatly. See my comment below.

[rafael2k]

Thanks @ghaerr ! Got it. I imagined it would be a bit more than a recompilation.
: )
Concerning the large model, would it be possible to use the Wattcom compiler to create the elks executable? I understand the libc would also need some work, as well code adaptation to match the correct semantic of the int size.
Changing watcom tcp calls to berkeley sockets would be the fun part I think. Anyway, I'll also take a look in other implementations to check if there is any better option.

[ghaerr]

Using Watcom could be a neat idea, but the wlink linker would have to be modified to emit an ELKS-compatible a.out format executable, rather than DOS-compatible .exe format. Other options would be a post-processor for .exe files to convert to a.out, or having ELKS load .exe files directly. All would be potentially a lot of work.

[rafael2k]

I have a feeling better I focus on compiling in gcc-ia16 and strip the wattcom tcp stack and see what I get.

[ghaerr]

If you're serious about trying to get this to work the first step would be attempting a compile/link just to see whether the code size is < 128k, as that's a hard limit. I checked the DOS .exe and its 143k so it could be close, depending on the amount of initialized data. It would be worth continuing to check around for small SSH implementations.

[ghaerr]

Hello @rafael2k,

It is an Open Wattcom project, with realmode-8086 project target
https://github.com/AnttiTakala/SSH2DOS

better I focus on compiling in gcc-ia16 and strip the wattcom tcp stack and see what I get.

I have found an interesting possibility of using the OpenWatcom C compiler and linker that could, although with lots of work, allow large model (large code and data) programs to run on ELKS. The owtarget16 Project has completed a proof of concept allowing C programs compiled with OpenWatcom to run on ELKS. Still lots to do, as there is as yet no C library for it, and large model may require kernel enhancements. See my comment here for more details about the potential issues.

Another very interesting project by the same author @pts minilibc686 contains a utility omf2elf which converts OpenWatcom (or other MS compiler) .OBJ files into ELF .o files. This could be then used in similar fashion but using the ELKS ia16-elf-ld.gold linker along with the ELKS C library to produce an executable compiled from Watcom C. In this case, there would still be a 128k code limit but large model far data might be more easily supported. I'm looking into both solutions.

Nonetheless, if SSH2DOS actually runs on 16-bit DOS and compiles with OpenWatcom C, that same source would probably be a good start for an ELKS port, for someone interested in really digging into it.

[rafael2k]

The code will fit in 128kB. The binary distributed is large because it includes the whole Wattcom TCP/IP stack. Even dropbear ssh server and client code compiled and linked is less than 100kB [1] on 32bit OSes.

[1] https://github.com/mkj/dropbear

[rafael2k]

Source mentions "Waterloo TCP/IP":
https://github.com/open-watcom/open-watcom-v2/tree/master/bld/wattcp

[ghaerr]

Wow! The Open Watcom C source is filled with good stuff. I've been studying it lately and have managed to get the entire toolchain up and running on macOS, including its C library (although the system calls aren't compatible with ELKS which is a whole 'nother project). The compiler then builds all its libraries and I can see now that it has built them all, including TCP/IP on my system for 8086 real mode DOS. That's kind of amazing. The more I'm learning about Watcom C the more I'm realizing the amount of work that went into it and that its a truly professional compiler toolchain and set of libraries running on many platforms.

[rafael2k]

Indeed we need to take our hat off, especially for them open-sourcing all their code!
: )

[tyama501]

OpenWatcom is the main compiler of the FreeDOS kernel.
Wattcp is included in FreeDOS distribution, although mtcp may be used.

[ghaerr]

I also notice looking at OpenWatcom's C library source that the BIOS support routines for IBM PC are also supported specially for PC-98. There appears to be a Japanese GUI version of OWC as well. It appears the OWC source tree is a treasure trove of useful information and routines that could be used to enhance ELKS, given OWC's massive support for 16-bit systems.