Resumen

  • RFC 1207 recogió el caso de dos Sun 3/60 enlazadas mediante SLIP por sus puertos ttya: ping y rlogin respondían, mientras que montar NFS producía server not responding: RPC Timed Out. La respuesta relacionó el fallo con la suma de comprobación UDP apagada en SunOS 3.5 y la falta de una comprobación propia en SLIP.
  • La misma sección advertía que SLIP en SCO TCP/IP para Xenix solo funcionaba con los controladores serie de SCO. Una tarjeta multipuerto inteligente con controladores propios quedaba fuera de esa combinación, por muchos puertos que ofreciera.

La red aprobó el examen equivocado

La historia empieza con dos respuestas que cualquier administrador querría recibir. Las Sun 3/60, conectadas por ttya y SLIP, contestaban a ping. rlogin abría una sesión remota. Después llegaba la tarea real: montar un sistema de archivos por NFS. El resultado era un mensaje de RPC que daba al servidor por no disponible. Había comunicación, pero no la clase de comunicación que completaba el trabajo.

La pregunta quedó impresa en RFC 1207, una recopilación de febrero de 1991 preparada por G. Malkin, A. Marine y J. Reynolds para usuarios experimentados. Sus editores habían seguido listas de correo importantes, extraído dudas que se repetían y ordenado las respuestas. Querían que el personal de redes recién conectadas dispusiera de referencias útiles, y que los suscriptores de las listas no volvieran a leer el mismo intercambio una y otra vez. El caso NFS mostraba por qué una respuesta archivada podía ahorrar más tiempo que otro consejo genérico de «revise la red».

La explicación del documento no apuntaba al nombre del servidor ni a la velocidad del cable. Según la respuesta, SunOS 3.5 desactivaba la suma de comprobación UDP. En Ethernet, una comprobación en la capa de enlace hacía que la configuración pudiera funcionar. SLIP no añadía una comprobación equivalente. Para ejecutar NFS sobre esa línea, la respuesta pedía activar la suma UDP. Incluía incluso una orden de adb para cambiar udpcksum en el núcleo, con una advertencia práctica: conservar el núcleo anterior.

La secuencia obliga a distinguir resultados. Un eco ICMP recibido prueba un trayecto para ese intercambio. Un acceso por rlogin prueba una sesión interactiva. Ninguno certifica el comportamiento de los datagramas de la operación NFS sobre un enlace que no comprueba su carga. Cuando el usuario pide archivos, el certificado de «conectado» emitido tras el primer ping tiene letra pequeña que nadie leyó.

La tarjeta sofisticada que el software no podía usar

La sección 8.3 del mismo RFC ofrecía un segundo problema, situado en otro punto de la cadena. Una persona quería ejecutar SLIP en Xenix con una tarjeta serie de varios puertos. SCO TCP/IP para Xenix incorporaba SLIP, decía la respuesta, pero esa implementación solo funcionaba con los controladores serie de SCO. Las tarjetas inteligentes que incluían sus propios controladores no servían. Para sumar muchos puertos, el texto sugería puertos sencillos o una tarjeta multipuerto igualmente sencilla.

Es una trampa de compra muy concreta. Una placa con más capacidad física podía reducir las opciones de despliegue porque su controlador no entraba en el camino que entendía SLIP. La etiqueta «admite SLIP» pertenecía al software; el número de puertos pertenecía al hardware; la compatibilidad vivía en el controlador que los unía. Aprobar dos fichas técnicas por separado no probaba esa unión.

El capítulo había comenzado corrigiendo otra confusión: SLIP no estaba diseñado para líneas serie síncronas, sino para asíncronas. PPP podía servir en ambos tipos. Un equipo que elegía circuito, placa, sistema operativo y servicio tenía cuatro decisiones entrelazadas, ninguna sustituible por un ping al final. La tarjeta Xenix y el NFS SunOS fallaban en capas distintas, y sus reparaciones no podían intercambiarse.

La receta impresa no cerró el caso

RFC 1207 imprimió la orden histórica para modificar el núcleo y aconsejó guardar el anterior. Eso identifica con precisión la palanca que los autores de la respuesta consideraban relevante. La publicación no incluye una captura de paquetes, el valor observado antes y después del cambio, ni un segundo montaje NFS exitoso. Un registro de esos pasos decidiría si el diagnóstico resolvió la instalación descrita. Lo que sí consta es la combinación inicial: dos pruebas satisfactorias y una operación de archivos fallida.

Los editores explicaron que algunas respuestas de las listas habían sido abreviadas, otras fueron añadidas por ellos cuando nadie contestó y el material adicional se señaló aparte. Retiraron los nombres de los corresponsales. Estamos leyendo un archivo de conocimiento operativo, no el informe completo de un incidente. Su utilidad nace de mostrar dónde detener una conclusión precipitada. La línea serie estaba viva. El usuario seguía sin poder montar sus archivos. La siguiente pregunta debía dirigirse a la condición que ese trabajo exigía, no al indicador que ya estaba verde.

Fuente