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.

[rafael2k]

Now we have OW creating executables for Elks, I can more easily resume this by using the same watcom Makefile, but changing to ewcc and ewlink, and then change the network calls, right?

[ghaerr]

Yes, although the ewcc and ewlink may not exactly support (i.e. pass through) various options correctly, so you might possibly have to edit some of the options.

When you say "network calls", you mean the network system calls, like connect, accept, etc? Yes, they will need to be added. I've been meaning to do that, so when you get link errors with undefined system calls, let me know and I can add them to the ELKS OW C system call library, unless you'd like to.

[rafael2k]

Ha. Just realized that. I'll commit the new CFAGS to my forked repo (https://github.com/rafael2k/SSH2DOS). Btw, I see the libc compiles with owcc. Should I use owcc or wcc?

[ghaerr]

I see the libc compiles with owcc. Should I use owcc or wcc?

We're using owcc now in ewcc and ewlink, because its options are easier to understand for Linux folks not used to OWC. Note that owcc is just a wrapper that calls wcc anyways. You probably ought to stay with using ewcc instead of owcc or wcc directly as there are a number of options that have to be included in order to generate the right code to run on ELKS. The same goes for header files - the OWC runtime DOS (or OS/2) libraries are generally not compatible with ELKS or the ELKS C library.

[rafael2k]

Got it.
Indeed. I realized that header mixing was a problem, for example OW <io.h> has definitions for read() and write()! And of course many symbol clashes now I'm starting to port OW DOS software to Elks. Even more fun!
: )

[rafael2k]

Found some other option very interesting:
https://github.com/Oryx-Embedded/CycloneSSH
https://www.oryx-embedded.com/doc/files.html

[rafael2k]

Now a ssh server which is small enough I think could be ported to ELKS too:
https://github.com/janmojzis/tinyssh

[ghaerr]

Your list is getting longer!!

TinySSH doesn't use dynamic memory allocation and code size is already almost 64K so I'd assume you'd need to use OWC in order to compile it in one of its models after figuring out how much data segment size is actually needed.

Did you ever take a pass at compiling SSH2DOS after we got OWC working with ELKS?

[rafael2k]

I started the work (with OWC, yes!), but it is some way to go. I would even consider another option, as SSH2DOS would need to have included newer algorithms to properly work.