E - K ermit — Kermit para incrustar

Source: https://kermitproject.org/ek.html

Anuncio de código abierto: a partir del 30 de marzo de 2011 con la versión 1.6, E-Kermit se publica "tal cual" bajo la licencia BSD revisada de 3 cláusulas .

E-Kermit 1.8 del 26 de mayo de 2021 corrige un error en la versión de demostración de Unix donde se invirtieron los argumentos de la línea de comandos -B y -T (para forzar el modo de transferencia de archivos binario y de texto, respectivamente). Gracias a Todd Markley por informarlo.

27 de mayo de 2021: todos los enlaces FTP de esta página se convirtieron a HTTP/HTTPS porque Chrome, Firefox y quién sabe qué otros navegadores ya no los admiten; detalles aquí .

EK (Embedded Kermit, E-Kermit) es una implementación del protocolo de transferencia de archivos Kermit escrito en ANSI C y diseñado para integrarse en dispositivos o firmware, para uso en aplicaciones en tiempo real o para la construcción de DLL y bibliotecas. EKSW es una nueva versión de E-Kermit que incluye transporte de paquetes con ventanas deslizantes reales. EK y EKSW deberían reconciliarse en una única base de código, pero hasta ahora eso no ha sucedido.

¿Qué hace E-Kermit?

EK realiza sólo dos funciones: enviar archivos y recibir archivos. Es compacto, portátil y totalmente reentrante. En SPARC (RISC), kermit.o es de unos 25K. En Intel (CISC) son unos 15K. Al reducir el tamaño del búfer y eliminar funciones opcionales o no deseadas, se pueden lograr tamaños más pequeños.

Lo que E-Kermit NO hace

EK no incluye funciones cliente/servidor; un lenguaje de programación de comandos o scripts; conversión de juegos de caracteres; cifrado de transporte; o cualquier forma de comunicación o entrada/salida de archivos. No marca módems, no realiza conexiones, no tiene una pila TCP/IP incorporada ni interfaz con una externa. Si necesita estas funciones, debería utilizar un programa Kermit completo, como C-Kermit o Kermit 95 .

EK no es una aplicación en sí misma, es una subrutina a la que se llama desde su aplicación maestra. Es útil sólo para los desarrolladores, quienes deben proporcionar la aplicación maestra o el entorno de llamada, así como las rutinas de E/S de archivos y comunicaciones. El entorno de llamada debe, a su vez, realizar y configurar la conexión de comunicaciones si es necesaria y aún no está abierta. Se proporciona un entorno de llamadas de muestra y soporte de E/S para Unix.

Los clientes han adaptado EK a diversos entornos y plataformas, incluido Palm Pilot, varios tipos de equipos técnicos (por ejemplo, para diagnóstico y mantenimiento de torres de telefonía celular) y, a veces, contribuyen con sus adaptaciones o rutinas de E/S, y podemos ponerlas a disposición. estrictamente tal como está. No podemos admitir ni mantener el código aportado por el cliente; por lo tanto (por ejemplo), si se lanza una nueva versión de EK, los módulos aportados por el cliente no necesariamente se actualizan. El código aportado por el cliente incluye:

Puerto serie y E/S de archivos de Microsoft Windows 9x/ME/NT/2000/XP/Vista/7 para EK 1.3 y posteriores.
Wind River VxWorks para EK 1.1.
EK 1.2 traducido a Java .

EK incluye las siguientes características del Protocolo Kermit:

Paquetes largos
Ventanas deslizantes con recuperación de errores Go-Back-to- N (verdadera repetición selectiva en EKSW).
Compresión de recuento de repeticiones
Prefijo y desprefijo de caracteres de control
Prefijo de 8 bits (para transferir datos de 8 bits en enlaces de 7 bits) (= paridad)
Paquetes de atributos (tipo, tamaño y fecha)
Envío y recepción de archivos únicos o múltiples.
Cambio automático de modo texto/binario por archivo.
Los tres tipos de verificación de bloques (suma de verificación de 6 y 12 bits, CRC de 16 bits).
Informes de estado (estado del protocolo, nombre de archivo, tamaño, marca de tiempo, bytes hasta el momento).
Cancelación de transferencia por cualquiera de las partes.

Las siguientes características del Protocolo Kermit no están implementadas:

Ventanas correderas con retransmisión selectiva (excepto en EKSW)
Conjuntos de caracteres
turnos de bloqueo
Servidor de cliente

Los tiempos de espera serían responsabilidad del programa Kermit en el otro extremo de la conexión o, si fuera necesario en el propio E-Kermit, la rutina de lectura de paquetes dependiente de la plataforma que usted escribiría.

A partir de la versión 1.5, E-Kermit incluye construcciones de preprocesador que le permiten excluir varias funciones, como paquetes largos, ventanas deslizantes y comprobaciones de bloques de orden superior para lograr la menor huella de memoria posible, y también se puede construir en una configuración de solo recepción. .

EL PROGRAMA DE CONTROL

EK está diseñado para funcionar en un entorno cooperativo multitarea, pero no requiere dicho entorno. El programa de control se encarga de la programación. Esto es lo que el programa de control debe (y/o puede) hacer:

Si lo desea, abra el dispositivo de comunicaciones, si lo hubiera.
Si lo desea, ponga el dispositivo de comunicaciones, si lo hubiera, en "modo paquete".
Inicialice la estructura kermit con los parámetros operativos deseados.
Llamar Kermit(K_INIT,...) para que Kermit se inicialice.
Si envía archivos, llame Kermit(K_SEND) para iniciar la transferencia.

(Cuando E-Kermit va a recibir archivos, espera pasivamente el primer paquete del remitente del archivo; por lo tanto, simplemente ingresa al bucle de paquetes). En el bucle de paquetes, E-Kermit:

Obtiene un búfer y lee un paquete entrante en él.
Comprueba si hay interrupción del usuario.
llamadas kermit(K_RUN, ...) para realizar el siguiente paso del protocolo.
Hace todo lo que quiere (por ejemplo, ejecuta otras tareas).
Sale o continúa el ciclo según el Kermit() código de retorno.

Cada vez que el programa de control llama al Kermit() función, esto le otorga permiso para manejar un paquete; por lo tanto, un paquete = un segmento de tiempo. Si el programa de control no tiene nada más que hacer, simplemente procesa paquetes continuamente, como un programa Kermit normal. Mientras está en el circuito de transferencia de datos, cada Kermit() call devuelve una estructura que contiene:

El estado actual del protocolo;
El nombre del archivo actual;
El tamaño del archivo, si se conoce, o -1;
La marca de tiempo del archivo, si se conoce;
El número de bytes transferidos hasta el momento.

Cuando termine, el programa de control:

Restaura y (si lo desea) cierra el dispositivo de comunicaciones.

Los códigos de función que el programa de control puede llamar. Kermit() con son:

K_INIT-- Inicializar estructuras de datos.

K_ENVIAR -- (Sólo envío) -- Iniciar envío.

K_RUN-- Ejecute el protocolo.

K_ESTADO-- Devuelve un informe de estado en la estructura k_response.

K_QUIT-- Salga inmediatamente y en silencio.

K_ERROR-- Envíe el paquete de error y luego salga.

Los códigos de retorno del Kermit() función son:

X_OK-- Bien, protocolo activo.

X_HECHO-- Bien, protocolo completo.

X_ERROR-- Error fatal.

X_ESTADO-- Devolviendo el estado en respuesta a K_STATUS.

(De hecho, el estado se devuelve con cada llamada). Los códigos de estado del protocolo son:

-1-- Error fatal

0-- Receptor (protocolo no ejecutándose)

1-- Receptor esperando paquete S

2-- Receptor esperando paquete F o B

3-- Receptor esperando paquete A o D

4-- Receptor esperando paquete D o Z

10-- Remitente (protocolo no en ejecución)

11-- El remitente envió el paquete S (inicio)

12-- El remitente envió el paquete F (nombre de archivo)

13-- El remitente envió un paquete (atributos)

14-- El remitente envió el paquete D (datos)

15 -- El remitente envió el paquete Z (EOF)

dieciséis -- El remitente envió el paquete B (EOT)

TRANSFERENCIA DE ARCHIVOS

Debido a que EK está diseñado principalmente para incrustar, no utiliza streaming ni (excepto en EKSW) ventanas deslizantes verdaderas (aunque gran parte del código de las ventanas deslizantes está ahí). Esto se debe a las siguientes razones:

El uso del protocolo ACK/NAK normal permite que el programa de control recupere el control después de cada paquete. Esto le permite realizar múltiples tareas, configurar una pantalla gráfica de transferencia de archivos, lo que sea. Las ventanas fluidas o deslizantes podrían dejar fuera de servicio al programa de control durante largos períodos de tiempo.
La transmisión por secuencias o las verdaderas ventanas deslizantes harían que la interfaz entre el programa de control y el Kermit() El módulo es mucho más complicado y, de hecho, enviaría muchos detalles del protocolo al espacio del programa de control, donde no pertenecen.
La transmisión por secuencias solo se puede utilizar en conexiones confiables (como TCP/IP), pero los dispositivos con comunicaciones integradas generalmente usan puertos serie.

La falta de verdaderas ventanas corredizas en EK se compensa haciendo que EK pretenda sostenerlas sin realmente hacerlo. Esto permite a su socio emisor "transmitir" paquetes en lugar de esperar ACK después de cada uno, siempre y cuando no haya un error. Si hay un error, la estrategia de recuperación es "volver a n " (o quizás en algunos casos "eliminar el error") en lugar de "repetir selectivamente". EKSW, un programa separado que no se ha integrado con EK (pero debería integrarse), admite ventanas deslizantes verdaderas con repetición selectiva; es decir, sólo se retransmiten aquellos paquetes que realmente necesitan serlo.

En cualquier caso, dado que EK está destinado principalmente a la integración, se anticipa que los retrasos en los viajes de ida y vuelta no serán un factor importante; Las conexiones generalmente serán locales, cortas, relativamente rápidas y, si la conexión se controla de manera efectiva, estarán libres de errores. Cuando falta un control de flujo eficaz, la velocidad y/o la longitud del paquete y/o el tamaño de la ventana se pueden establecer en una combinación de valores que maximice el rendimiento y minimice la pérdida de datos.

CÓDIGO FUENTE

Los archivos fuente son:

plataforma.h

Archivo de encabezado para cualquier #inclusión o definición necesaria específica de la plataforma. Requerido, incluso si está vacío, porque kermit.c lo incluye.

kermit.h

Archivo de encabezado para todos los módulos. Definicion de k_datos y k_respuesta estructuras.

kermit.c

Este es el motor del protocolo Kermit. Está impulsado completamente por los datos de sus llamadas. Toda la información de estado se guarda en la estructura de datos de kermit, que se pasa por referencia desde el módulo principal y entre todas las funciones del módulo de kermit y de regreso al módulo principal; por lo tanto, debería ser posible que el mismo módulo transfiera varios archivos a la vez en diferentes conexiones. Además, no hay referencias de biblioteca en el módulo kermit, ninguna en absoluto, ni siquiera stdio (excepto cuando la depuración está habilitada), y no /usr/incluir/* Se incluyen archivos de encabezado. Reglas para kermit.c :

Sin variables globales (excepto para depuración) ni buffers.
No hay inicialización de matrices por parte del compilador.
Solo por seguridad, tampoco hay que inicializar escalares automáticos.
Sin llamadas a la biblioteca o al sistema, no #incluir <...> .
Todas las comunicaciones de E/S se realizan mediante funciones definidas en módulos separados.

El único punto de entrada para el kermit.c módulo es el Kermit() función:

int kermit(estructura k_data * k, estructura k_response * r)

La estructura k contiene todos los parámetros operativos, variables, información de estado y buffers; la estructura r mantiene informada a la persona que llama sobre el estado actual del protocolo, el nombre del archivo y la información del archivo, y el progreso de la transferencia (bytes hasta el momento).

C Principal

Programa de control de muestras. En el banco de pruebas de Unix, esto es sólo lo tradicional principal() , que lee los argumentos de la línea de comandos, inicializa el protocolo, luego llama al módulo de protocolo en un bucle controlado por estado hasta que finaliza su trabajo y luego lo limpia. En el entorno integrado, estas funciones se integrarían en el programa de control.

unixio.c

Funciones de E/S para Unix. Sustituya su propio módulo que implemente estas funciones en el entorno de destino y modifique su procedimiento de compilación para vincularlo. Puntos de entrada y convenciones de llamadas que se describen a continuación.

LA VERSIÓN UNIX

El desarrollo de EK se lleva a cabo en una plataforma Unix convencional, como Mac OS, AIX, Solaris, HP-UX, ... o en la actualidad, más probablemente, en alguna variedad de BSD o Linux, en la que EK está construido como un Kermit en modo remoto. Programa de transferencia de archivos, similar a G-Kermit, y probado con un Kermit de escritorio como K95 o C-Kermit. NOTA: La versión Unix funciona sobre stdin/stdout; la "línea" está condicionada de la manera más estúpida posible ( sistema("stty...") ). Esto da resultados variables; por ejemplo, las descargas desde EK en Solaris pueden ejecutarse a 17 Kcps, mientras que las descargas desde Linux en la misma red al mismo PC pueden ejecutarse a 1700 Kcps. No vale la pena preocuparse por esto porque EK no está diseñado para uso de producción en Unix, que ya tiene G-Kermit y C-Kermit para producción.

El archivo MAKE de Unix tiene los siguientes objetivos (es fácil agregar más):

gcc: Construir con gcc (predeterminado).

CC: Construir con cc.

CV: Construido para HP-UX.

gccnd: Compile con gcc, sin depuración.

gprof: Construya con gcc, incluya perfiles.

limpio: Elimine los archivos objeto y principal.

El archivo MAKE crea un ejecutable de Unix llamado "ek" (kermit integrado). La muestra principal() La rutina proporciona una interfaz de línea de comandos sencilla:

$ ./ek-h

Uso: opciones ./ek

Opciones:

-r Recibir archivos

-s archivos Enviar archivos

-p [neoms] Paridad: ninguna, par, impar, marca, espacio

-b [123] Tipo de verificación de bloque: 1, 2 o 3 (predeterminado = 3)

-k Mantener archivos recibidos de forma incompleta

-B Forzar modo binario

-T Forzar modo texto

-R Modo remoto (vs local)

-L Modo local (vs remoto)-Número

E Tasa de error simulada (0-100)

-d Crear registro de depuración

-h Ayuda (este mensaje)

ps

Al enviar archivos, si no especifica Texto o Binario, EK escanea cada archivo y elige el modo texto o binario según su contenido.

El modo Remoto versus Local se usa solo para habilitar la prueba de interrupción del teclado en la transferencia de archivos.

PORTAR A UNA NUEVA PLATAFORMA

La versión 1.0 de EK fue portada a VxWorks por Airvana, Inc, Chelmsford MA. El paquete completo VxWorks EK 1.1 se incluye como ejemplo de un sistema de producción con el permiso de Airvana (tenga en cuenta que la API de EK ha cambiado ligeramente desde entonces, por lo que antes de poder usar el código VxWorks, debe actualizarse). Para migrar a una nueva plataforma:

Agregue una nueva entrada Makefile para su objetivo o escriba su propio procedimiento de compilación.
Crear un plataforma.h archivo para su plataforma. Esto puede incluir cualquier #include o definición que desee, y también se puede usar para anular ciertas definiciones en kermit.h :
#definir NODEBUG para construir sin código de depuración.
#definir HAVE_UCHAR si UCHAR ya está definido o definición de tipo 'd a char sin firmar.
#definir HAVE_ULONG si ULONGO ya está definido o definición de tipo Llevaba mucho tiempo sin firmar.
#definir IBUFLEN para que sea el tamaño deseado para el búfer de entrada del archivo.
#definir OBUFLEN sea el tamaño deseado para el búfer de salida del archivo.
#definir FN_MAX ser la longitud máxima para un nombre de archivo.
#definir P_PKTLEN para anular la longitud máxima predeterminada del paquete.
#definir P_WSLOTS para anular las ranuras de ventana máximas predeterminadas.
Reemplazar la muestra C Principal con su propio programa de control. Utilice los mismos archivos de encabezado y convenciones de llamada que en el ejemplo.
Copiar unixio.c axxx io.c (nombre de su elección), edítelo para que funcione en su plataforma usando exactamente las mismas convenciones de llamada y ajuste su procedimiento de compilación para vincularlo con su nuevoxxx yo módulo en lugar de unixio . Tenga en cuenta que los buffers de entrada y salida de relleno ( i_buf[] y o_buf[] ) debe estar definido en suxxx yo rutina.

A continuación se ofrecen algunos consejos para crear un módulo de E/S:

Se espera que las rutinas de E/S del dispositivo manejen los parámetros de comunicación por sí mismas, incluida la velocidad de la línea de comunicación, la paridad y el control de flujo. En particular, Kermit no se ocupa de la paridad, pero aun así hay que comunicárselo. Esto se hace en la configuración por principal() . Su leer paquete() y datos_tx() las rutinas deben eliminar y agregar paridad, respectivamente, si es necesario. En conexiones en serie, tal vez se pueda programar el UART para hacer esto.

Cambio de API entre EK 1.1 y 1.2: las convenciones de llamada (listas de argumentos de función y valores de retorno) se cambiaron entre la versión 1.1 a 1.2, principalmente para brindar a todas las rutinas acceso a la estructura k de manera consistente y también para brindar una mejor retroalimentación a la persona que llama. . En cada caso en el que se realizó un cambio, se muestran tanto el formato antiguo como el nuevo.

Las funciones de E/S del dispositivo son:

int

devopen(char * dispositivo)

Abre el dispositivo de comunicaciones proporcionado. También podría ser un servidor de red, lo que sea. Devuelve 0 en caso de error, 1 en caso de éxito.

int

devsettings(char * configuración)

Este realiza cualquier configuración necesaria para el dispositivo, como el control de velocidad y flujo para un dispositivo en serie. Como no hay forma de saber cuáles son los parámetros relevantes, esta rutina simplemente toma una cadena, que puede tener cualquier formato, por ejemplo, " 9600;8N1 " o " velocidad=57600;flujo=rts/cts "; la rutina devsettings tendrá que analizar la cadena. Devuelve 0 en caso de error, 1 en caso de éxito.

int

devrestore(nulo)

Si lo desea, vuelva a colocar el dispositivo en su lugar. configuración de desarrollo() lo encontró, por ejemplo, justo antes de cerrarlo.

int

devclose(vacío)

Cierra el dispositivo de comunicaciones.

int

readpkt(UCHAR * buffer, estructura k_data * k) (1.1)

readpkt(struct k_data * k, UCHAR * buffer, longitud int) (1.2)

Esta rutina debe hacer exactamente lo que hace la muestra: buscar el inicio del paquete, luego copiar todos los caracteres hasta (pero sin incluir) el final del paquete en el búfer de paquetes cuya dirección se proporciona. Querrá codificar esto de la forma más eficiente posible, utilizando todos los trucos que tenga a su disposición: lecturas almacenadas en búfer sin bloqueo, etc. Si desea que su programa Kermit expire, aquí es donde colocaría el código. NOTA: Los tiempos de espera no son necesarios, ya que las posibilidades de que el socio Kermit de ek no pueda vencer el tiempo de espera son aproximadamente 0. El formato EK 1.2 coloca k como el primer argumento para mantener la coherencia con otras rutinas y agrega un argumento de longitud del búfer.

Tenga en cuenta la característica F_CTRLC. Esto está habilitado por defecto. Permite sacar a EK del modo paquete enviándole tres Ctrl-C consecutivos en el flujo de datos. Normalmente no sería necesario desactivar esto ya que, incluso si el remitente está "desprefijando" Ctrl-C, tres de ellos seguidos normalmente se colapsarían en una secuencia de conteo de repeticiones.

int

tx_data(UCHAR * datos, longitud int, paridad corta) (1.1)

tx_data(struct k_data * k, UCHAR * datos, longitud int) (1.2)

Aquí nuevamente, debe agregar paridad (si el dispositivo de comunicación o el controlador no lo hace automáticamente). Esta rutina debe ser eficiente y sólida. Se supone que debe transmitir toda la cadena de datos o fallará. Ver el unixio.c muestra de lo que quiero decir con "robusto". En EK 1.2 y posteriores, la configuración de paridad se recoge de la estructura k .

Las funciones de E/S de archivos son las siguientes; por supuesto, pueden usarse para leer o escribir cualquier cosa, no sólo archivos: memoria, cintas, tarjetas, rayos láser, controladores de instrumentos, lo que sea. No importa cómo llame a estas rutinas, pero la lista de argumentos y el tipo de retorno deben ser como se muestran; Además, si les das nombres diferentes, tendrás que cambiar los prototipos en kermit.h :

int

openfile(UCHAR * nombre de archivo, modo int, estructura k_date * k) (1.1)

openfile(struct k_date * k, UCHAR * nombre de archivo, modo int) (1.2)

Abre el archivo nombrado en el modo indicado (1 = leer, 2 = escribir, 3 = agregar). Devuelve X_OK en caso de éxito, X_ERROR en caso de error.

ULONG

fileinfo(UCHAR * nombre de archivo, UCHAR * buf, int buflen, tipo corto *, modo corto) (1.1)

fileinfo(struct k_data * k,UCHAR * nombre de archivo,UCHAR * buf,int buflen,short * tipo,modo corto) (1.2)

Obtiene información sobre el archivo local existente especificado: tamaño, fecha y, si modo == 0, el tipo de archivo (texto o binario). buf y buflen se aplican a la cadena de fecha/hora del archivo. Devuelve X_OK o X_ERROR.

int

archivo de lectura (estructura k_data *)

Lee un búfer del archivo de entrada y, si la transferencia se realiza en modo texto, convierte el formato de registro al Kermit Stream CRLF estándar. Devuelve X_OK o X_ERROR.

int

writefile(struct k_data *, CHAR * buffer, int longitud)

Escribe un búfer en el archivo de salida y, si la transferencia se realiza en modo texto, también convierte el formato de registro CRLF estándar de Kermit Stream a lo que se requiera localmente. Devuelve X_OK o X_ERROR.

En t

closefile(struct k_data *, código UCHAR, modo int)

Cierra el archivo. Para los archivos de salida, por supuesto, esto vacía todos los buffers pendientes en el archivo antes de cerrarlo; luego verifica si el Kermit emisor canceló la transferencia del archivo antes de que finalizara (código == 'D'), en cuyo caso descarta el archivo parcial en lugar de conservarlo. El modo indica si se trata de un archivo de entrada o de salida, por lo que los archivos recibidos de forma incompleta se pueden eliminar si se desea. Devuelve X_OK o X_ERROR.

Las convenciones de llamadas precisas se muestran en la unixio.c archivo.

DEPURACIÓN

Si EK se creó sin NODEBUG definido, entonces si incluye el -d opción en la línea de comando, la versión de muestra basada en Unix de EK crea un registro de depuración archivo en su directorio actual. En la versión de producción, agregaría -DNODEBUG al compilador de C CFLAGS para eliminar el código de depuración. Los tamaños que se muestran arriba incluyen la depuración. Puede implementar la función de depuración de la forma que desee en el módulo de E/S específico de su plataforma.

HISTORIAL DE PUBLICACIONES

Versión	Fecha	Descripción
1.1	2002/10/07	Versión inicial. La versión de VxWorks aún está en este nivel.
1.2	28/01/2003	API mejorada, puerto Java (que todavía está en este nivel).
1.3	2004/03/04	Repare la transferencia de archivos con HyperTerminal.
1.4	2004/03/20	Corregir la recepción de archivos vacíos.
1.5	2004/04/10	Solucione el problema con los paquetes A, permita configuraciones súper pequeñas y/o de solo recepción.
1,51	23/09/2004	Adaptarse a Philips XAG30 (John Dunlap)
EKSW 0,94	24/06/2010	Verdaderas ventanas correderas con retransmisión selectiva ( John Dunlap )
1.6	2011/03/30	Publicado y publicado bajo la licencia BSD revisada de 3 cláusulas .
1.7	2011/06/06	Protocolo FORCE-3, funciona junto con C-Kermit 9.0 (explicado aquí )
1.8	2021/06/26	Solucionar el problema con los argumentos de línea de comandos -B y -T (solo demostración de Unix)

DESCARGAR

Varias implementaciones diferentes de E-Kermit están disponibles para descargar. El propio E-Kermit, versión 1.8, es el principal. La versión 1.7 sigue disponible. Las demás son adaptaciones a diferentes plataformas o lenguajes que se realizaron durante lanzamientos anteriores de E-Kermit, como se indicó en el apartado anterior; en otras palabras, las correcciones encontradas en E-Kermit 1.3, 1.4 y 1.5 no están en las versiones VxWorks o Java, y la versión VxWorks usa la API E-Kermit 1.1 en lugar de la versión 1.2 mejorada. EKSW tiene algunas modificaciones en la API y otras inconsistencias que deben corregirse antes de poder integrarse con EK 1.6, pero es perfectamente utilizable por sí solo. De hecho, esta es la versión que corre en la nueva generación de flotadores oceánicos Apex-EM.y ha sido probado más exhaustivamente en condiciones más adversas que posiblemente cualquier otra implementación del protocolo Kermit. Dando origen a la versión 1.7, que implementa el nuevo protocolo de paquetes de comprobación de errores Force-3 . (EKSW también debería recibir esto en algún momento).

Nombre	Descripción	Alquitrán *	Cremallera	Archivos fuente
E-Kermit 1.8	Portátil para todas las plataformas, con demostración de Unix.	Descargar	Descargar	Descargar
E-Kermit 1.7	Portátil para todas las plataformas, con demostración de Unix.	Descargar	Descargar	Descargar
EKSW 0,94	E-Kermit con verdaderas ventanas correderas, adaptado a Linux.	Descargar	Descargar	Descargar
EKVX 1.1	E-Kermit 1.1 adaptado a VxWorks.	Descargar	Descargar	Descargar
Java	E-Kermit 1.2 convertido a Java	Descargar	Descargar	Descargar
simírida	Probador de estrés del protocolo Kermit [ descripción ]	Descargar	Descargar	Descargar

* No comprimidos, no es necesario, son muy pequeños.