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.

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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?

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.

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!
: )

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?

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.

@rafael2k, ELKS SLIP works pretty well and with the special serial interrupt handler turned on via CONFIG_FAST_IRQ4 has allowed transfer speeds of 38.4K without UART receive overruns, although a hardware FIFO always helps. That's one of the reasons serial input queues are still set at 1K bytes.

Thanks for the information @ghaerr! Can the tcp/ip stack attach to the SLIP driver without problems? I was also thinking about porting Taylor's UUCP, which could be interesting for copying files in and out, and no encryption overhead.

Wow! Very impressive if you managed to compile it on ELKS!

Here is a very minimal code for a future ssh client. It has to be used against a TLS 1.1. It assumes: MacSSL.h / MacSSL.lib provide the usual MbedTLS-style API: SSL_library_init(), SSL_CTX_new(), SSL_new(), SSL_connect(), SSL_read(), SSL_write(), SSL_shutdown(), SSL_free(), SSL_CTX_free()

/* ssh_minimal.c
 * Minimal SSH client skeleton for ELKS using MacSSL
 * Connects to host:22, initializes MacSSL library
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <conio.h>
#include <dos.h>

#include "MacSSL.h"   // Assuming MacSSL headers are available

#define SERVER "127.0.0.1"
#define PORT 22

int main(void) {
    int sock;
    SSL_CTX *ctx;
    SSL *ssl;

    printf("ELKS SSH minimal client using MacSSL\n");

    /* 1. Initialize MacSSL library */
    if (SSL_library_init() != 1) {
        printf("SSL library initialization failed\n");
        return 1;
    }
    SSL_load_error_strings();
    ctx = SSL_CTX_new(TLS_client_method());
    if (!ctx) {
        printf("Failed to create SSL context\n");
        return 1;
    }

    /* 2. Create TCP connection */
    sock = open_tcp_connection(SERVER, PORT); // you must implement open_tcp_connection() for ELKS
    if (sock < 0) {
        printf("Failed to open TCP connection\n");
        SSL_CTX_free(ctx);
        return 1;
    }

    /* 3. Create SSL object and attach to socket */
    ssl = SSL_new(ctx);
    SSL_set_fd(ssl, sock);

    /* 4. Perform SSL handshake */
    if (SSL_connect(ssl) <= 0) {
        printf("SSL handshake failed\n");
        SSL_free(ssl);
        SSL_CTX_free(ctx);
        close(sock);
        return 1;
    }

    printf("SSL handshake completed\n");

    /* 5. Send SSH protocol version string (example) */
    const char *ssh_hello = "SSH-2.0-ELKS-MacSSL\r\n";
    SSL_write(ssl, ssh_hello, strlen(ssh_hello));

    /* 6. Read server response */
    char buffer[256];
    int n = SSL_read(ssl, buffer, sizeof(buffer)-1);
    if (n > 0) {
        buffer[n] = '\0';
        printf("Server response: %s\n", buffer);
    }

    /* 7. Cleanup */
    SSL_shutdown(ssl);
    SSL_free(ssl);
    SSL_CTX_free(ctx);
    close(sock);

    printf("Connection closed\n");
    return 0;
}

/* Stub for TCP connection on ELKS - you will need to implement using ELKS sockets */
int open_tcp_connection(const char *host, int port) {
    /* Minimal ELKS TCP connect code goes here */
    /* Return socket fd or -1 on error */
    return -1; // placeholder
}

And the open_tcp_connection(), using large memory model.

/*
 * open_tcp_connection()
 * --------------------
 * Minimal TCP connection function for ELKS 16-bit
 * Returns a connected socket descriptor or -1 on error.
 *
 * Parameters:
 *  host - string containing IPv4 address (e.g., "192.168.1.100")
 *  port - port number in host byte order
 *
 * Notes:
 *  - Uses ELKS BSD-style socket API
 *  - Compatible with Open Watcom 16-bit large memory model (-ml)
 *  - Must include <sys/socket.h> and <netinet/in.h> from ELKS
 */

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>    // for close()
#include <string.h>
#include <stdio.h>

int open_tcp_connection(const char *host, int port) {
    int sockfd;
    struct sockaddr_in addr;

    /* 1. Create socket */
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd < 0) {
        printf("socket() failed\n");
        return -1;
    }

    /* 2. Initialize server address */
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(port);

    /* Convert host string to binary address */
    addr.sin_addr.s_addr = inet_addr(host);
    if (addr.sin_addr.s_addr == INADDR_NONE) {
        printf("Invalid host address: %s\n", host);
        close(sockfd);
        return -1;
    }

    /* 3. Connect to server */
    if (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        printf("connect() failed\n");
        close(sockfd);
        return -1;
    }

    /* 4. Return connected socket */
    return sockfd;
}

cleaned up the code a little today, instead of a kludge port. you may take control of this lib if you wish toncho?

ssl lib's are nearly outside of my comfort zone.

i will create a new thread about this, sorry i should not of put this lib here

The current MacSSL shim only gives you a TLS 1.2 client; SSH needs its own key exchange and packet machinery, so you’d still need a full SSH stack libssh2 can target this lib, but would require some hefty figuring out!

so for example TLS 1.2 applies to protocols like HTTPS, FTPS, SMTPS,

but its a step in the direction for elks ssh.

I have only managed to get tls 1.2 working
urgh unfortunately im away for a month long family trip, i do not access to a computer now, only smartphone, much appreciated if you could report your findings, the sample code checks out against all relavent libs, im going to guess its going to segfault, iv literally not tested the code on a running system, just been bored staying away, had access to a computer.

Thanks @parabyte. Cool, having https and others which need tls 1.2 is pretty nice. We could try integrating to httpget.

iv not looked at the code at all, but i wonder how much ram regular wget consumes!?

iv given this its own thread now

we have urlget:
https://github.com/ghaerr/elks/tree/master/elkscmd/inet/urlget

a lib specifically designed for a specific embeded device will have specific code for that specific device. makes it unfeasible to port the code, unless the developer knows that device sdk very well